[Webkit-unassigned] [Bug 25634] Need a way to get the Frame for the code at the top of the JS stack

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri May 8 14:16:36 PDT 2009


https://bugs.webkit.org/show_bug.cgi?id=25634





------- Comment #6 from abarth at webkit.org  2009-05-08 14:16 PDT -------
(In reply to comment #4)
> You can check out the related Chromium change. When an Extension API is called,
> we want to know which frame invoked it so that we can be more intelligent with
> the behavior of APIs based on what RenderView they came from.

I don't understand why the extension case differs from the general web case.

> An easy example of this is the inspector. You can call
> chromium.windows.create() from the inspector. We want the new window to be
> positioned relative to the window you're inspecting, not the inspector window.

The context for evaluating scripts in the web inspect is all screwed up.  I
don't think we should bend the web platform to fix the needs of the inspector.

The thing is, a bunch of these changes violate the HTML 5 spec.  For example,
the change to postMessage means that the source would be determined via dynamic
scope instead of via lexical scope, as required by the spec.

Similarly, in DOMWindowOpen and WindowSetLocation, you're now applying the
frame navigation policy (shouldAllowNavigation) based on dynamic scope instead
of lexical scope, in violation of the spec and the behavior of other browsers.

The changes to HTMLDocumentWrite and HTMLDocumentWriteln change our behavior
when using these APIs.  Have you tested this to see whether this makes us more
or less compatible with other browsers?  I suspect it makes use less
compatible.

Basically, I don't think its a good idea to subtly change a bunch of behavior
for "consistency" without considering the compatibility and compliance issues.


-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.



More information about the webkit-unassigned mailing list