Bug 112042 – Unsafe JavaScript attempt errors are ludicrously verbose and annoying

• Status: RESOLVED
• Resolution: FIXED
• Component: DOM

[Timothy Hatcher]

Unsafe JavaScript attempt to access frame with URL http://www.theverge.com/ from frame with URL http://ad.doubleclick.net/adi/N6249.529834.VOXMEDIAINC/B7379039.33;sz=728x90;click1=http://ox-d.sbnation.com/w/1.0/rc?ts=1fHNpZD05MjMxfHJhaWQ9OGU2OTllZDktMjE4Ny00YjM2LTg3ZjgtMzUyNTVjMjRkYzJifGF1aWQ9MzIxMDkxfGFpZD05MjY0MzF8cHViPTg5NDF8bGlkPTU1MzEyMnx0PTV8cmlkPWY2ZDFlODFjLTY3MDktNGQyMy1iZjQ2LTU3NDY5ZDc5MTRhN3xvaWQ9MTYwMTgyfGJtPUJVWUlORy5HVUFSQU5URUVERVhDTFVTSVZFfHBjPVVTRHxwPTEwMDAwMHxhYz1VU0R8cG09UFJJQ0lORy5DUE18cnQ9MTM2MzAyMzc0OXxwcj0xMDAwMDB8YWR2PTY3NjA4&r=;ord=FJAJyrczhF?. Domains, protocols and ports must match.

We should simplify these errors by not including the whole URL and on only show the "domains, protocols and ports" since that is all that matters.

The offending frame URL (and better yet, specific script and line) should be included as meta data so the Inspector can show it and prettify the URL like other messages. Including the URLs in the messages is just meh and asking for a bad user experience. Especially since doubleclick.net keeps trying to be "evil" in 2013…

[Mike West]

Thanks for CCing me, Alexey!

Yes, these messages are a bit verbose. We're currently dealing with it by ellipsizing the middle of the URL to get the whole thing down to ~150 characters, but I agree that we can do better.

Honestly, in most cases the error is useless. Bug 43504 and its children will fix half the problem (we're not throwing a catchable exception), the other half is proving problematic (I've yet to find a solution to bug 98050 that doesn't introduce significant performance regressions). Regardless, I think those bugs cover the long-term solution.

For the short-term, I'm fairly certain that we're already linking correctly to the line of script that tried to access location information by auto-generating a stack trace. I'll see what I can do about adjusting the console message to include a more minimal message. The suggestion to include only the bits that don't match up sounds quite reasonable.

[Timothy Hatcher]

No, these messages have never had a source location or stack trace. (I just tested Canary and the TOT Safari.) They are just an ugly stepchild.

[Mike West]

I'll throw a patch up in a moment that rewords the error to include origins rather than URLs for the default case. There are a variety of subsets of this error (sandbox errors, document.domain errors) that I'll address in subsequent patches in the interests of reducing HUEGNESS. :)

(In reply to comment #2)
> No, these messages have never had a source location or stack trace. (I just tested Canary and the TOT Safari.) They are just an ugly stepchild.

TalkingPointsMemo.com is my go-to example for these errors. I see both stack traces and line numbers there for all of them (on Chrome OS 25.0.whatever). Where aren't you seeing stack traces? I'd like to track those down.

[Timothy Hatcher]

I see, so they sometimes do.

On theverge.com and cnn.com I've never seen traces. Even a few on talkingpointsmemo.com don't have traces.

[Timothy Hatcher]

Unsafe JavaScript attempt to access frame with URL http://talkingpointsmemo.com/ from frame with URL http://ad.doubleclick.net/adi/N2998.Centro/B7347028.23;sz=728x90;click=http…tyjeS39L2GR//;pc=[TPAS_ID];click=;ord=7ac97347-de7b-4a49-9837-6b0302f889be?. Domains, protocols and ports must match.

That one had no trace.

Some of the other times I didn't see traces might have been due to opening the Inspector after loading the page. The case above I reloaded the page in Chrome with the tools open.

[Mike West]

(In reply to comment #5)
> Unsafe JavaScript attempt to access frame with URL http://talkingpointsmemo.com/ from frame with URL http://ad.doubleclick.net/adi/N2998.Centro/B7347028.23;sz=728x90;click=http…tyjeS39L2GR//;pc=[TPAS_ID];click=;ord=7ac97347-de7b-4a49-9837-6b0302f889be?. Domains, protocols and ports must match.
> 
> That one had no trace.

Traces should be generated whenever a message is written to the console (ConsoleMessage::autogenerateMetadata), if some are missing, I'd love to be able to fix them. Would you mind copy/pasting this out to a separate bug?

> Some of the other times I didn't see traces might have been due to opening the Inspector after loading the page.

Right, we don't currently generate traces when the inspector isn't open; there were performance concerns. I'd love to get traces in this case as well if we can do it without impacting load times.

[Mike West]

Created attachment 192730 [details]
Patch

[Mike West]

(In reply to comment #7)
> Created an attachment (id=192730) [details]
> Patch

Throwing this to the bots: I'm sure I've missed rebaselining some tests, but before I spend too much time on it, I'd like you to take a look at the new message. Does "Blocked a frame with origin 'http://127.0.0.1:8000' from accessing a frame with origin 'http://localhost:8000'. Protocols, domains, and ports must match." sound reasonable to you?

[Timothy Hatcher]

Comment on attachment 192730 [details]
Patch

The only annoying part now is the tools will linkify the origins when they really should not. I would also use double quotes instead of single quotes.

[Mike West]

(In reply to comment #9)
> (From update of attachment 192730 [details])
> The only annoying part now is the tools will linkify the origins when they really should not.

True. I considered breaking them out into some sort of triplet, but that seemed strange. I don't have a good suggestion that would avoid linkification without being strange. :/

> I would also use double quotes instead of single quotes.

We're using single quotes in most other places (but since I added most of them, I'm happy to change to double-quotes is that's what you'd prefer. :) ).

[WebKit Review Bot]

Comment on attachment 192730 [details]
Patch

Attachment 192730 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://webkit-commit-queue.appspot.com/results/17138110

New failing tests:
http/tests/security/javascriptURL/javascriptURL-execution-context-iframe-src-setAttributeNS.html
http/tests/security/javascriptURL/javascriptURL-execution-context-frame-src-setAttribute.html
http/tests/security/javascriptURL/javascriptURL-execution-context-iframe-src-setAttributeNode.html
http/tests/security/mixedContent/redirect-https-to-http-iframe-in-main-frame.html
http/tests/security/javascriptURL/javascriptURL-execution-context-iframe-src-setAttribute.html
http/tests/security/javascriptURL/javascriptURL-execution-context-frame-location-htmldom.html
http/tests/security/isolatedWorld/bypass-main-world-csp.html
http/tests/security/javascriptURL/javascriptURL-execution-context-iframe-src-getAttribute-value.html
http/tests/security/javascriptURL/javascriptURL-execution-context-frame-src-setAttributeNodeNS.html
http/tests/security/isolatedWorld/bypass-main-world-csp-for-xhr.html
http/tests/security/javascriptURL/javascriptURL-execution-context-iframe-src-setAttributeNodeNS.html
http/tests/security/javascriptURL/javascriptURL-execution-context-frame-src-setAttributeNS.html
http/tests/security/javascriptURL/javascriptURL-execution-context-frame-src-getAttribute-value.html
http/tests/security/javascriptURL/javascriptURL-execution-context-frame-src-setAttributeNode.html
http/tests/security/javascriptURL/javascriptURL-execution-context-iframe-src-htmldom.html
http/tests/security/javascriptURL/javascriptURL-execution-context-frame-src-htmldom.html
fast/xmlhttprequest/xmlhttprequest-no-file-access.html

[Mike West]

Created attachment 192770 [details]
Patch

[Mike West]

(In reply to comment #12)
> Created an attachment (id=192770) [details]
> Patch

Double-quotes.

[WebKit Review Bot]

Comment on attachment 192770 [details]
Patch

Attachment 192770 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://webkit-commit-queue.appspot.com/results/17196076

New failing tests:
http/tests/security/javascriptURL/javascriptURL-execution-context-iframe-src-setAttributeNS.html
http/tests/security/javascriptURL/javascriptURL-execution-context-frame-src-setAttribute.html
http/tests/security/javascriptURL/javascriptURL-execution-context-iframe-src-setAttributeNode.html
http/tests/security/javascriptURL/javascriptURL-execution-context-frame-src-setAttributeNode.html
http/tests/security/javascriptURL/javascriptURL-execution-context-iframe-src-setAttribute.html
http/tests/security/javascriptURL/javascriptURL-execution-context-frame-location-htmldom.html
http/tests/security/javascriptURL/javascriptURL-execution-context-iframe-src-getAttribute-value.html
http/tests/security/javascriptURL/javascriptURL-execution-context-frame-src-setAttributeNodeNS.html
http/tests/security/javascriptURL/javascriptURL-execution-context-iframe-src-setAttributeNodeNS.html
http/tests/security/javascriptURL/javascriptURL-execution-context-frame-src-setAttributeNS.html
http/tests/security/javascriptURL/javascriptURL-execution-context-frame-src-getAttribute-value.html
http/tests/security/javascriptURL/javascriptURL-execution-context-iframe-src-htmldom.html
http/tests/security/javascriptURL/javascriptURL-execution-context-frame-src-htmldom.html
fast/xmlhttprequest/xmlhttprequest-no-file-access.html

[Mike West]

(In reply to comment #14)
> (From update of attachment 192770 [details])
> Attachment 192770 [details] did not pass chromium-ews (chromium-xvfb):
> Output: http://webkit-commit-queue.appspot.com/results/17196076
> 
> New failing tests:
> http/tests/security/javascriptURL/javascriptURL-execution-context-iframe-src-setAttributeNS.html
> http/tests/security/javascriptURL/javascriptURL-execution-context-frame-src-setAttribute.html
> http/tests/security/javascriptURL/javascriptURL-execution-context-iframe-src-setAttributeNode.html
> http/tests/security/javascriptURL/javascriptURL-execution-context-frame-src-setAttributeNode.html
> http/tests/security/javascriptURL/javascriptURL-execution-context-iframe-src-setAttribute.html
> http/tests/security/javascriptURL/javascriptURL-execution-context-frame-location-htmldom.html
> http/tests/security/javascriptURL/javascriptURL-execution-context-iframe-src-getAttribute-value.html
> http/tests/security/javascriptURL/javascriptURL-execution-context-frame-src-setAttributeNodeNS.html
> http/tests/security/javascriptURL/javascriptURL-execution-context-iframe-src-setAttributeNodeNS.html
> http/tests/security/javascriptURL/javascriptURL-execution-context-frame-src-setAttributeNS.html
> http/tests/security/javascriptURL/javascriptURL-execution-context-frame-src-getAttribute-value.html
> http/tests/security/javascriptURL/javascriptURL-execution-context-iframe-src-htmldom.html
> http/tests/security/javascriptURL/javascriptURL-execution-context-frame-src-htmldom.html
> fast/xmlhttprequest/xmlhttprequest-no-file-access.html

*sigh* We apparently have baselines for these tests for chromium, chromium-linux, and chromium-win. I hate platforms.

I'll rebaseline these again shortly. :)

[Mike West]

Created attachment 192816 [details]
Patch

[WebKit Review Bot]

Comment on attachment 192816 [details]
Patch

Clearing flags on attachment: 192816

Committed r145692: <http://trac.webkit.org/changeset/145692>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.