Re: [webkit-dev] exposing the value of Accept-Language via window.navigation.acceptLanguage ?
On Wed, Jul 22, 2009 at 10:52 PM, Alexey Proskuryakov a...@webkit.org wrote: 22.07.2009, в 22:36, Darin Fisher написал(а): Firefox and Chrome send very similar A-L headers. Given FF's marketshare, I'm surprised you observed compat problems with doing the same. Was that a recent observation? Can you provide more details about the issues you observed? It's not recent, see http://lists.macosforge.org/pipermail/webkit-dev/2005-June/000217.html. There is also some discussion in https://bugs.webkit.org/show_bug.cgi?id=3510, not sure if any of it is still relevant. I do not have a reference handy, but IIRC, sending quality values was breaking some widely deployed intranet webmail system. FF has a lot more marketshare now than it did in 2005. Perhaps these issues are a thing of the past? It would be interesting to know if any of the sites mentioned still have problems in FF or Chrome. -Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] exposing the value of Accept-Language via window.navigation.acceptLanguage ?
On Jul 22, 2009, at 11:24 PM, Darin Fisher wrote: On Wed, Jul 22, 2009 at 10:52 PM, Alexey Proskuryakov a...@webkit.org wrote: 22.07.2009, в 22:36, Darin Fisher написал(а): Firefox and Chrome send very similar A-L headers. Given FF's marketshare, I'm surprised you observed compat problems with doing the same. Was that a recent observation? Can you provide more details about the issues you observed? It's not recent, see http://lists.macosforge.org/pipermail/webkit-dev/2005-June/000217.html . There is also some discussion in https://bugs.webkit.org/show_bug.cgi?id=3510 , not sure if any of it is still relevant. I do not have a reference handy, but IIRC, sending quality values was breaking some widely deployed intranet webmail system. FF has a lot more marketshare now than it did in 2005. Perhaps these issues are a thing of the past? It would be interesting to know if any of the sites mentioned still have problems in FF or Chrome. I think the main reason for us to minimize the Accept-Language header was compatibility. I think it would be reasonable to try an extended version now. The problem now is how to set things that way. Safari on Mac used to pick the Accept-Language header based on International preferences, but in the default setup, many languages are in the list and the order beyond the user's main language is fairly arbitrary. In any case, I think the privacy concern is minimal, and I don't think the proposed API makes it any worse. My only doubts about the proposal are whether web developers will actually want to use it. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] incompatibility between DOM spec (IDL) and c-based (gobject) language bindings
starting here:
https://bugs.webkit.org/show_bug.cgi?id=27435#c3
the issue is raised and noted that the W3C specification has several
functions with the exact same name and several parameters, and that c
simply is not equipped to cope with this.
the reason why i'm raising this on webkit-dev is because, contrary to
belief, the gobject bindings are _not_ limited to the GTK+: the GTK+
port is just at present the only port which has the necessary
linkage code. [reason: gobject has nothing to do with gtk.
#include gobject.h does not require #include gtk.h].
anyway - the summary conclusion that i came to in dealing with this issue is:
* to provide a good enough solution
* to provide that which does the job for the most people
* to provide the longest number of arguments and let callers work with that.
just so you know, mozilla _also_ suffers from this exact same problem,
and the solutions attempted, over several years of development, are...
a bit of a mess.
http://groups.google.com/group/mozilla.dev.platform/browse_thread/thread/ed216e6eb453649a/76829e33f396aade?lnk=gstq=lkcl#76829e33f396aade
here is where i have provided a good enough / does the job for most
people solution, this is in 2DCanvasContext's drawImage function:
https://bugzilla.mozilla.org/show_bug.cgi?id=502234
given that the existing XULrunner code _entirely_ cuts everything but
javascript off from drawImage, absolutely _anything_ is an
improvement. the 3-args version is therefore a good enough
compromise.
the gobject bindings do not implement 2D SVG Canvas [yet] - it was
simply far too much additional work. the XULrunner example is
therefore noted as advance warning about what kind of grungy
decisions lie ahead.
xan notes here: https://bugs.webkit.org/show_bug.cgi?id=27435#c4
a recommendation for doing hand-crafted fix-ups. yes, that's what
MSHTML does, effectively, because they too are using c (thanks to DCOM
which in turn relies on MSRPC which is in fact DCE/RPC the underlying
implementations are all c
*huge-intake-of-breath-at-overlong-sentence*)
the general policy in DCE/RPC is to simply stack a number on the end
of the function [and up-rate the IDL revision number, for backwards
compatibility - a feature not present in webkit].
so, sam, you finally have an explanation as to why adam did this:
https://bugs.webkit.org/show_bug.cgi?id=16401#c194
+sub Uniquify {
+my $name = shift;
+my $avoid = shift;
+if ($name eq $avoid) {
+$name = $name . 2;
+}
Please explain this.
it looks like it's the beginnings of trying to make auto-generated
gobject bindings that support the cases where functions in the IDL
have identical names. by postfixing a number on them.
now.
from experience with the gobject bindings thanks to pywebkitgtk as
intermediate bindings which pyjamas-desktop uses, i've found that the
cases where there are clashes like this are extremely rare, or that by
having defaults (and passing in 0, False, NULL or '') is perfectly
sufficient.
passing in 0, False, NULL is what XULrunner's [optional] IDL tag is
all about, and it's a route i'd strongly suggest avoiding. if
[optional] is added, then further analysis is made of the argument,
and, depending on its type, 0, False or NULL is passed in - but that's
only on _javascript_ bindings: the native c++ access (the xullrunner
equivalent of linking direct to WebCore) and the language bindings
are... well... pretty much left to their own devices i.e. stuffed in
most cases.
so, yes, the number of cases encountered are pretty rare.
* XMLHttpRequest open function takes 5 arguments, 3 of which are optional.
it's been discovered that passing in False, '','' as those three arguments
does the job.
* KeyboardEvent initKeyboardEvent function takes... oo... 14 arguments
in the W3C DOM specification and one extra one in Webkit (contrary to
the W3C standard), to provide notification when, and discrimination
of, the Alt-Gr key. a patch has been submitted which simply
eliminates on of these functions, for gobject bindings:
https://bugs.webkit.org/show_bug.cgi?id=27436
if you _don't_ do that, then the gobject bindings will simply fail to
compile, because you get two c functions with exactly the same name
[sam: note. answering / explaining
https://bugs.webkit.org/show_bug.cgi?id=16401#c194 ]
there are a couple of others, but it's no big deal.
overall, then, as noted above, i think you can see that this is a
hairy / grungy area but that the number of exceptions which need to be
dealt with are pretty limited, and the evidence and insights in here
support xan's statement:
https://bugs.webkit.org/show_bug.cgi?id=27435#c5
and the answer to mark's comment -
https://bugs.webkit.org/show_bug.cgi?id=27435#c5 is: in the
auto-generator, _and_ if it's demonstrated and proven that you _need_
it: if you have a clash, you simply tack on a number. increment until
done.
where it is quite often the case that by simply having default values
and
Re: [webkit-dev] incompatibility between DOM spec (IDL) and c-based (gobject) language bindings
Responding to review comments should be done in the relevant bugzilla
bug, not on the mailing list. It's ok to post here if you think an
issue needs wider input from the community, but that doesn't seem to
be the case with this issue.
Regards,
Maciej
On Jul 23, 2009, at 5:18 AM, Luke Kenneth Casson Leighton wrote:
starting here:
https://bugs.webkit.org/show_bug.cgi?id=27435#c3
the issue is raised and noted that the W3C specification has several
functions with the exact same name and several parameters, and that c
simply is not equipped to cope with this.
the reason why i'm raising this on webkit-dev is because, contrary to
belief, the gobject bindings are _not_ limited to the GTK+: the GTK+
port is just at present the only port which has the necessary
linkage code. [reason: gobject has nothing to do with gtk.
#include gobject.h does not require #include gtk.h].
anyway - the summary conclusion that i came to in dealing with this
issue is:
* to provide a good enough solution
* to provide that which does the job for the most people
* to provide the longest number of arguments and let callers work
with that.
just so you know, mozilla _also_ suffers from this exact same problem,
and the solutions attempted, over several years of development, are...
a bit of a mess.
http://groups.google.com/group/mozilla.dev.platform/browse_thread/thread/ed216e6eb453649a/76829e33f396aade?lnk=gstq=lkcl#76829e33f396aade
here is where i have provided a good enough / does the job for most
people solution, this is in 2DCanvasContext's drawImage function:
https://bugzilla.mozilla.org/show_bug.cgi?id=502234
given that the existing XULrunner code _entirely_ cuts everything but
javascript off from drawImage, absolutely _anything_ is an
improvement. the 3-args version is therefore a good enough
compromise.
the gobject bindings do not implement 2D SVG Canvas [yet] - it was
simply far too much additional work. the XULrunner example is
therefore noted as advance warning about what kind of grungy
decisions lie ahead.
xan notes here: https://bugs.webkit.org/show_bug.cgi?id=27435#c4
a recommendation for doing hand-crafted fix-ups. yes, that's what
MSHTML does, effectively, because they too are using c (thanks to DCOM
which in turn relies on MSRPC which is in fact DCE/RPC the underlying
implementations are all c
*huge-intake-of-breath-at-overlong-sentence*)
the general policy in DCE/RPC is to simply stack a number on the end
of the function [and up-rate the IDL revision number, for backwards
compatibility - a feature not present in webkit].
so, sam, you finally have an explanation as to why adam did this:
https://bugs.webkit.org/show_bug.cgi?id=16401#c194
+sub Uniquify {
+my $name = shift;
+my $avoid = shift;
+if ($name eq $avoid) {
+$name = $name . 2;
+}
Please explain this.
it looks like it's the beginnings of trying to make auto-generated
gobject bindings that support the cases where functions in the IDL
have identical names. by postfixing a number on them.
now.
from experience with the gobject bindings thanks to pywebkitgtk as
intermediate bindings which pyjamas-desktop uses, i've found that the
cases where there are clashes like this are extremely rare, or that by
having defaults (and passing in 0, False, NULL or '') is perfectly
sufficient.
passing in 0, False, NULL is what XULrunner's [optional] IDL tag is
all about, and it's a route i'd strongly suggest avoiding. if
[optional] is added, then further analysis is made of the argument,
and, depending on its type, 0, False or NULL is passed in - but that's
only on _javascript_ bindings: the native c++ access (the xullrunner
equivalent of linking direct to WebCore) and the language bindings
are... well... pretty much left to their own devices i.e. stuffed in
most cases.
so, yes, the number of cases encountered are pretty rare.
* XMLHttpRequest open function takes 5 arguments, 3 of which are
optional.
it's been discovered that passing in False, '','' as those three
arguments
does the job.
* KeyboardEvent initKeyboardEvent function takes... oo... 14 arguments
in the W3C DOM specification and one extra one in Webkit (contrary to
the W3C standard), to provide notification when, and discrimination
of, the Alt-Gr key. a patch has been submitted which simply
eliminates on of these functions, for gobject bindings:
https://bugs.webkit.org/show_bug.cgi?id=27436
if you _don't_ do that, then the gobject bindings will simply fail to
compile, because you get two c functions with exactly the same name
[sam: note. answering / explaining
https://bugs.webkit.org/show_bug.cgi?id=16401#c194 ]
there are a couple of others, but it's no big deal.
overall, then, as noted above, i think you can see that this is a
hairy / grungy area but that the number of exceptions which need to be
dealt with are pretty limited, and the evidence and insights in here
support xan's statement:
https://bugs.webkit.org/show_bug.cgi?id=27435#c5
[webkit-dev] Changing two unit tests: 'alt' as accessible name instead of description
Hi, As the result of working in bug 25524 (see [1] for more details), we have reached the conclusion (and not only to fix that bug) that perhaps it would be good to change how the 'alt' attribute is exposed to ATs, switching from being the accessible description to be the accessible name. This would allow to always use (for every HTML element) the HTML core attribute 'title' for the accessible description, which is what the already proposed patch implements so far. In other works, current patch proposal is as follows: * Always expose 'alt' in images as the accesible name. * Always expose 'title', for every HTML item, as the accessible description. Problem is that this change, which affects to all the platforms (and not only to GTK, despite of the bug name), would also mean to change two unit tests which are failing right now: - accessibility/img-aria-button-alt-tag.html - accessibility/input-image-alt.html Those tests are failing because they *always* expect the 'alt' attribute for images to be exposed as the accessible description instead of the name, and that would need to be changed if this patch got accepted. Thus, as this change would affect to all the platforms and would mean to change two regression tests, we'd love to hear more opinions from someone else on this topic before making a final decision. So... any thoughts? Thanks, Mario [1] https://bugs.webkit.org/show_bug.cgi?id=25524 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] incompatibility between DOM spec (IDL) and c-based (gobject) language bindings
On 7/23/09, Maciej Stachowiak m...@apple.com wrote: Responding to review comments should be done in the relevant bugzilla bug, not on the mailing list. It's ok to post here if you think an issue needs wider input from the community, but that doesn't seem to be the case with this issue. maciej, thank you for making that point. i'm going to do a rusty 7fs russell and rewrite what you've said so that i can respond to it. We generally have a policy of keeping responses to review comments in the relevant bugzilla bug, not on the mailing list, as you can see from the guidelines [insert URL here]. It's ok to post here if you think an issue needs wider input from the community. i was curious as to why you felt the need to make this post to the mailing list, because doesn't seem to be the case with this issue. ok - now we have something that can be responded to. On 7/23/09, after reconsidering matters carefully and rewriting them, Maciej Stachowiak m...@apple.com wrote: We generally have a policy of keeping responses to review comments in the relevant bugzilla bug, not on the mailing list, as you can see from the guidelines [insert URL here]. ah, sorry. the issue raised by mark had only a passing reference to the bug report, and was a more generic and wider matter that did not fit in with the bugreport, and had nothing to do with the subject line of the bug so, yes, i thought it best to raise it here. It's ok to post here if you think an issue needs wider input from the community. i was curious as to why you felt the need to make this post to the mailing list, because doesn't seem to be the case with this issue. there are absolutely loads of reasons. 1) so that people could find it, and discuss it. 2) in keeping the matter locked up in the bugreport, it risked becoming a discussion which nobody could find, not for love nor money, even if they wanted to contribute to it, or if they knew that it might affect their project adversely. so, out of a sense of responsibility and duty to the free software community that i serve i thought it best to raise this with a wider audience. 3) i appreciate that technical matters _should_ be discussed in bugreports - if relevant - however on strategic design decisions i felt that it would be more appropriate to discuss it here. 4) the sheer number of related and affected bugreports makes it awkward to contain the discussion to a single bugreport. the list of related bugs is #16401, #27410, #27423 through to #27437 (excluding #27434) 5) the discussions run to close to 300 comments, now, in #16401, with absolutely no search capabilities or useful archiving. to continue to use that as the parent bugreport would simply result in the discussion being utterly lost. i trust that this comprehensive answer illustrates to you that it was, although extremely quick, not without sound reasons that i chose to raise this matter on the lists, and i trust that you will in future do myself and others on this list the courtesy of not make it necessary for me to spend considerable time explaining and justifying my actions and decisions. thank you. l. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] exposing the value of Accept-Language via window.navigation.acceptLanguage ?
Thank you all for the comments. I'll write to whatwg and public-html about adding it to window.navigator (yes, I meant navigator :-)) ). 2009/7/22 Alexey Proskuryakov a...@webkit.org: 22.07.2009, в 22:36, Darin Fisher написал(а): Firefox and Chrome send very similar A-L headers. Given FF's marketshare, I'm surprised you observed compat problems with doing the same. Was that a recent observation? Can you provide more details about the issues you observed? Thank you for the reference. It's not recent, see http://lists.macosforge.org/pipermail/webkit-dev/2005-June/000217.html. Most of pages (Netscape directory server?) referred to there are not available any more. http://gun.teipir.gr/ds/csearch is still up and fails in Chrome, Firefox 3, and IE 8 because they all send Accept-Language with q-values. The page I got back from the server in Firefox and Chrome is 'funny': 0 0. ko 1 0.7998 en_us 2 0.4997 zh 3 0.2996 en 0 0. ko 1 0.7998 en_us 2 0.4997 zh 3 0.2996 en A-L sent was ko,en-us;q=0.8,zh;q=0.5,en;q=0.3 (IE8 'fails' to load the page, too, but it just shows an HTTP error message). There is also some discussion in https://bugs.webkit.org/show_bug.cgi?id=3510, not sure if any of it is still relevant. I do not have a reference handy, but IIRC, sending quality values was breaking some widely deployed intranet webmail system. https://bugs.webkit.org/show_bug.cgi?id=3510#c2 has a reference to Outlook Webaccess, but that's about 'ru-ru' vs 'ru'. There's a bug report against Chrome about an 'opposite' case. We used to send languages without a q-value (which means everything gets q=1.0). See http://crbug.com/3970 Safari should just work for this case, though because the page in question works when only a single language is sent with no q-value. It should be noted that normally people only have one value (or one family of values: en and en-US for example) on the A-L list, and that they have to configure their browser to advertise other languages. I think that addresses the privacy concerns, assuming suitable wording in the configuration panel. Yes, I agree. Safari takes the languages from system configuration. Aha.. right. I forgot that when I wrote the first email in the thread. Jungshik ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Changing two unit tests: 'alt' as accessible name instead of description
I don't think you want to return the altTag in stringValue(). That should only be for things that have actual strings (textfields, text rendered onto the screen) Right now titleAttr is exposed for all elements in the ::title() method. Perhaps that is incorrect, but its hard to get this right, since so many developers use title and alt incorrectly. On the Mac side, AT software is able to get the titleAttr through an AXTitle attribute and the altAttr through AXDescription AXDescription is supposed to be the description of the object that when that description is not displayed on the screen. This is basically what accessibilityDescription() does (which also explains why altAttr is being returned in accessibilityDescription()) So in my naivety, it seems Gtk should exposed the ::title() method through some attribute, so that the AT program can take the title and the description and decide what to do with it. On the mac side, there is also an attribute called AXHelp, which is more inline with what W3 says on how title should be used (as a tooltip). AXHelp thus does return the titleAttr in webkit. Unfortunately, due to the general uselessness of AXHelp and tooltips, it is not something that is often heard by mac AT users. Combine that with the misusage of the title attribute to label an element, creates a situation where the AT user would not hear the information the developer adorned their elements with, in most cases. Thus, titleAttr is returned as the AXTitle on the mac. Hi, As the result of working in bug 25524 (see [1] for more details), we have reached the conclusion (and not only to fix that bug) that perhaps it would be good to change how the 'alt' attribute is exposed to ATs, switching from being the accessible description to be the accessible name. This would allow to always use (for every HTML element) the HTML core attribute 'title' for the accessible description, which is what the already proposed patch implements so far. In other works, current patch proposal is as follows: * Always expose 'alt' in images as the accesible name. * Always expose 'title', for every HTML item, as the accessible description. Problem is that this change, which affects to all the platforms (and not only to GTK, despite of the bug name), would also mean to change two unit tests which are failing right now: - accessibility/img-aria-button-alt-tag.html - accessibility/input-image-alt.html Those tests are failing because they *always* expect the 'alt' attribute for images to be exposed as the accessible description instead of the name, and that would need to be changed if this patch got accepted. Thus, as this change would affect to all the platforms and would mean to change two regression tests, we'd love to hear more opinions from someone else on this topic before making a final decision. So... any thoughts? Thanks, Mario [1] https://bugs.webkit.org/show_bug.cgi?id=25524 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] exposing the value of Accept-Language via window.navigation.acceptLanguage ?
On Jul 22, 2009, at 10:36 PM, Darin Fisher wrote: Firefox and Chrome send very similar A-L headers. Given FF's marketshare, I'm surprised you observed compat problems with doing the same. Was that a recent observation? Can you provide more details about the issues you observed? I’m not familiar with how Chrome approaches this, but Firefox handles this by offering a browser setting to explicitly configure a list of languages for web browsing. Roughly speaking, it’s a direct control of the Accept-Languages header field. Very few web servers look at this header field at all. It should be noted that normally people only have one value (or one family of values: en and en-US for example) on the A-L list Exactly; this is true across browsers. Thus a single value is the configuration that’s most tested. Thus the issue is not Firefox market share number that matters, but rather the vastly smaller number of people using any browser who have gone to the trouble to put multiple languages in the language list. What we discovered in 2003 and 2004 was that making a multiple- language list the norm for people who don’t opt in to it resulted in many broken websites. Further, almost no websites worked better with a more complete Accept-Language header field. We discovered sites that had difficulty with long Accept-Language header fields containing a large numbers of characters. Here are a few examples: - The official Irish Tourist Board site www.ireland.travel.ie did not load because of the long Accept-Language header. - A site called termpro.com gave us a “Firewall Security Alert” because the header was too long. Presumably that’s not the only site that was affected by this firewall. - Servers using the Netscape Directory Gateway failed because of the long header. At the time this included sites such as these: calendar.gwu.edu co.stanford.edu directory.princeton.edu gun.teipir.gr ldap.chapman.edu www.inami.fgov.be Symptoms were variable and it took us a long time to figure out the issue was because of long header. - Another site that had problems with the long list was dirtypictureshow.com . Later, we discovered a few other problems. For example, for a while eBay treated users as if they were browsing from Germany if the German language appeared anywhere in the list, blocking certain auctions. Using the languages list from Mac OS X as our default meant that German would be included for most users. Once we changed the Safari Accept-Language to be shorter we didn’t get any more data about the problem, naturally. But I don’t think it is right to assume that these problematic sites disappeared. It’s not as if there are a large number of users with any browser that are testing behavior with a long Accept-Language header field. I think this boils down to a question of the value of having an explicit browser preference setting solely to configure the value of the Accept-Language header field. It seems this is one of those settings that experts love to tweak, but has little relevance to the real web. Do we really expect users to go out of their way to configure such things so they can browse the web? Can’t we just make the web work for them? -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Name Getters
Is it possible to move a name getter onto a different JavaScript object?
Example:
JSValue JSHTMLFormElement::nameGetter(ExecState* exec, const
Identifier propertyName, const PropertySlot slot)
{
JSHTMLElement* jsForm =
static_castJSHTMLFormElement*(asObject(slot.slotBase()));
HTMLFormElement* form = static_castHTMLFormElement*(jsForm-impl());
VectorRefPtrNode namedItems;
form-getNamedElements(propertyName, namedItems);
if (namedItems.size() == 1)
return toJS(exec, jsForm-globalObject(), namedItems[0].get());
if (namedItems.size() 1)
return new (exec) JSNamedNodesCollection(exec,
jsForm-globalObject(), namedItems);
return jsUndefined();
}
Why does this function use slot.slotBase() for this instead of just
using this?
Arv mentioned that there is lookupGetter()... maybe that's why this
uses slot.slotBase()?
-eric
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Name Getters
Ah! Nevermind. nameGetter is static.
static JSC::JSValue nameGetter(JSC::ExecState*, const
JSC::Identifier, const JSC::PropertySlot);
-eric
On Thu, Jul 23, 2009 at 3:04 PM, Eric Seidele...@webkit.org wrote:
Is it possible to move a name getter onto a different JavaScript object?
Example:
JSValue JSHTMLFormElement::nameGetter(ExecState* exec, const
Identifier propertyName, const PropertySlot slot)
{
JSHTMLElement* jsForm =
static_castJSHTMLFormElement*(asObject(slot.slotBase()));
HTMLFormElement* form = static_castHTMLFormElement*(jsForm-impl());
VectorRefPtrNode namedItems;
form-getNamedElements(propertyName, namedItems);
if (namedItems.size() == 1)
return toJS(exec, jsForm-globalObject(), namedItems[0].get());
if (namedItems.size() 1)
return new (exec) JSNamedNodesCollection(exec,
jsForm-globalObject(), namedItems);
return jsUndefined();
}
Why does this function use slot.slotBase() for this instead of just
using this?
Arv mentioned that there is lookupGetter()... maybe that's why this
uses slot.slotBase()?
-eric
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] document()-frame()-script()-globalObject()
It seems all lookups of the current globalObject go through the frame.
document()-frame()-script()-globalObject() is one example.
Another:
JSValue toJS(ExecState*, DOMWindow* domWindow)
{
if (!domWindow)
return jsNull();
Frame* frame = domWindow-frame();
if (!frame)
return jsNull();
return frame-script()-windowShell();
}
Why? Shouldn't the Document know what its JSDOMGlobalObject is,
regardless of whether its currently in a Frame or not?
-eric
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] document()-frame()-script()-globalObject()
Yes, sorry to be confusing. I was attempting to provide examples of
how we currently go through the frame() every time we need the
JSDOMGlobalObject.
It sounds like you agree with me, that the Document should have a way
to get to the JSDOMGlobalObject w/o having to go through the Frame.
Am I understanding correctly?
Currently Document owns the DOMWindow. However there is no way to get
from DOMWindow* to JSDOMWindow* w/o going through the Frame.
-eric
On Thu, Jul 23, 2009 at 5:50 PM, Maciej Stachowiakm...@apple.com wrote:
On Jul 23, 2009, at 5:38 PM, Eric Seidel wrote:
I'm trying to get a JSDOMGlobalObject from a Node*. A Node* should
always have one, but our current path through Frame* can sometimes
fail.
Right - what confuses me is that you posted the toJS() function for
DOMWindow, where there's no document or node involved. It does go through
the frame, but that's to convert properly to the outer window, which is what
you should get when you expose a window object to JS. I think it's
reasonable for a document to know about its innner window, in our current
design.
- Maciej
-eric
On Thu, Jul 23, 2009 at 5:33 PM, Maciej Stachowiakm...@apple.com wrote:
On Jul 23, 2009, at 5:23 PM, Eric Seidel wrote:
It seems all lookups of the current globalObject go through the frame.
document()-frame()-script()-globalObject() is one example.
Another:
JSValue toJS(ExecState*, DOMWindow* domWindow)
{
if (!domWindow)
return jsNull();
Frame* frame = domWindow-frame();
if (!frame)
return jsNull();
return frame-script()-windowShell();
}
Why? Shouldn't the Document know what its JSDOMGlobalObject is,
regardless of whether its currently in a Frame or not?
The document should probably know its own inner window object, while the
frame should hold on to the outer window. I'm not entirely clear on how
the
document relates to the code you quoted though.
- Maciej
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] document()-frame()-script()-globalObject()
On Jul 23, 2009, at 5:23 PM, Eric Seidel wrote:
It seems all lookups of the current globalObject go through the frame.
document()-frame()-script()-globalObject() is one example.
Another:
JSValue toJS(ExecState*, DOMWindow* domWindow)
{
if (!domWindow)
return jsNull();
Frame* frame = domWindow-frame();
if (!frame)
return jsNull();
return frame-script()-windowShell();
}
Why? Shouldn't the Document know what its JSDOMGlobalObject is,
regardless of whether its currently in a Frame or not?
The document should probably know its own inner window object, while
the frame should hold on to the outer window. I'm not entirely clear
on how the document relates to the code you quoted though.
- Maciej
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] document()-frame()-script()-globalObject()
I'm trying to get a JSDOMGlobalObject from a Node*. A Node* should
always have one, but our current path through Frame* can sometimes
fail.
-eric
On Thu, Jul 23, 2009 at 5:33 PM, Maciej Stachowiakm...@apple.com wrote:
On Jul 23, 2009, at 5:23 PM, Eric Seidel wrote:
It seems all lookups of the current globalObject go through the frame.
document()-frame()-script()-globalObject() is one example.
Another:
JSValue toJS(ExecState*, DOMWindow* domWindow)
{
if (!domWindow)
return jsNull();
Frame* frame = domWindow-frame();
if (!frame)
return jsNull();
return frame-script()-windowShell();
}
Why? Shouldn't the Document know what its JSDOMGlobalObject is,
regardless of whether its currently in a Frame or not?
The document should probably know its own inner window object, while the
frame should hold on to the outer window. I'm not entirely clear on how the
document relates to the code you quoted though.
- Maciej
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] waf build patches
Hi all, Well, I've finally submitted the patches for building wxWebKit using waf. They're available from here: https://bugs.webkit.org/show_bug.cgi?id=27619 I've tried to keep the patches how you guys like them - under 5KB each. ;-) There's only 6, with one being about 20KB but that can be broken up too if requested. (Though they're basically helper scripts so I suspect they just need a look over.) If I could get some quick reviews on these, it'd be really appreciated as trunk simply doesn't build for wx right now, and although I have a git branch that still builds, it's against sources that are becoming increasingly dated and so I'd like to be able to update it and get everything back on track. Also, as a heads up, I'm heading out on vacation Saturday, so if these get reviewed after that I probably won't be able to apply them until week after next. So if I don't apply them right away it's not because I don't want to. ;-) Also #2, just for anyone curious, I was able to get it working so that the list of sources to compile is generated automatically using an excludes mechanism. I'd certainly be happy to help anyone who is interested in making the exclude patterns configurable based on port. As you can see from the patches, I only had to explicitly add (or remove) a dozen or so sources. Everything else is generated simply by telling it to build all non-port-specific sources in common dirs plus sources in wx and CURL directories, so I feel pretty confident that this could be adapted to build other ports fairly quickly. Thanks, Kevin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] incompatibility between DOM spec (IDL) and c-based (gobject) language bindings
On Thursday 23 July 2009 18:31:32 Luke Kenneth Casson Leighton wrote: i trust that this comprehensive answer illustrates to you that it was, although extremely quick, not without sound reasons that i chose to raise this matter on the lists, and i trust that you will in future do myself and others on this list the courtesy of not make it necessary for me to spend considerable time explaining and justifying my actions and decisions. Okay, it is the n-th time you will receive a mail like this, from n different people. This might indicate that it has to do something with you and not the n people sending you such kind of mail. webkit.org is no poetry club, keep your mails short. You could have answered the mail in two sentences instead you are watering your message with useless information to a point nobody even cares to read it. love z. Example below: maciej's: Point was: Normally we respond to comments in a bug in the bug itself. you could have said: Well, in this case I believe it is important to have a broader audience... ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] incompatibility between DOM spec (IDL) and c-based (gobject) language bindings
Zecke, you are great you made my day with your note k, thx, bai. -eric On Thu, Jul 23, 2009 at 7:27 PM, Holger Freytherze...@selfish.org wrote: On Thursday 23 July 2009 18:31:32 Luke Kenneth Casson Leighton wrote: i trust that this comprehensive answer illustrates to you that it was, although extremely quick, not without sound reasons that i chose to raise this matter on the lists, and i trust that you will in future do myself and others on this list the courtesy of not make it necessary for me to spend considerable time explaining and justifying my actions and decisions. Okay, it is the n-th time you will receive a mail like this, from n different people. This might indicate that it has to do something with you and not the n people sending you such kind of mail. webkit.org is no poetry club, keep your mails short. You could have answered the mail in two sentences instead you are watering your message with useless information to a point nobody even cares to read it. love z. Example below: maciej's: Point was: Normally we respond to comments in a bug in the bug itself. you could have said: Well, in this case I believe it is important to have a broader audience... ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
