[Webkit-unassigned] [Bug 72650] The error event should be supported for frames

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Feb 22 18:49:31 PST 2012


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


Pablo Flouret <pablof at motorola.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |abarth at webkit.org,
                   |                            |pablof at motorola.com




--- Comment #2 from Pablo Flouret <pablof at motorola.com>  2012-02-22 18:49:28 PST ---
I've been looking into this.

The spec says:
[[
When content whose URL has the same origin as the iframe element's Document fails to load (e.g. due to a DNS error, network error, or if the server returned a 4xx or 5xx status code or equivalent), then the user agent must queue a task to fire a simple event named error at the element instead. (This event does not fire for parse errors, script errors, or any errors for cross-origin resources.)
]]

I was wondering how to do the same-origin check correctly. If i'm seeing things right, when the iframe element is inserted into the document, the url is set to about:blank and the security origin is inherited from the parent document, and then the iframe's src url is loaded. Now, if i were to compare the security origins when the url fails to load due to a dns or network error it would potentially give the wrong answer, since the security origin never changed, right?

What would be the right approach here, am i missing something that would help? Otherwise, should the src attribute or the url in some documentloader be used for the check if !frameHasLoaded() or something along those lines?

I presume the restriction is there to prevent from sniffing intranet urls and things like that, do you guys think it's a worthwhile restriction? Are there other follies trying to be prevented?

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



More information about the webkit-unassigned mailing list