Bug 156001 – Web Inspector: Console is unusable on sites with frequent Blocked Messages (theverge.com)

• Status: NEW
• Component: Web Inspector

[Joseph Pecoraro]

* SUMMARY
Console is unusable on sites with frequent Blocked Messages (theverge.com).

Non-stop console error messages:
CONSOLE ERROR Blocked a frame with origin "http://tpc.googlesyndication.com" from accessing a frame with origin "http://www.theverge.com". Protocols, domains, and ports must match.
CONSOLE ERROR Blocked a frame with origin "http://tpc.googlesyndication.com" from accessing a frame with origin "http://www.theverge.com". Protocols, domains, and ports must match.

* STEPS TO REPRODUCE
1. Inspect <http://www.theverge.com>
  => Non-stop blocked messages to console

* NOTES
Other browsers do not have this error message spammed to their console. Is WebKit doing something wrong? Can we reduce this spam somehow?

[Radar WebKit Bug Importer]

<rdar://problem/25431270>

[Timothy Hatcher]

Is this better after the recent console changes?

[Timothy Hatcher]

<rdar://problem/25301506>

[Blaze Burg]

Still happens a lot. We could reduce it by doing a better job of counting duplicates. In some cases we don't count it with previous warnings. I think it would be best to just show this inline and on a security audits page, not in the console.

[Nikita Vasilyev]

Making console only render messages that are in the viewport would solve this as well.

[Joseph Pecoraro]

(In reply to comment #5)
> Making console only render messages that are in the viewport would solve
> this as well.

I don't think that would help here. The issue here is the deluge of "blocked" messages makes the console unusable. Having the console be fast but still filled with messages would still be unusable in this respect.

[Michael Bishop]

(In reply to comment #6)
> (In reply to comment #5)
> > Making console only render messages that are in the viewport would solve
> > this as well.
> 
> I don't think that would help here. The issue here is the deluge of
> "blocked" messages makes the console unusable. Having the console be fast
> but still filled with messages would still be unusable in this respect.

Related Chromium thread that resolves exactly this issue in the Chrome fork of webkit: https://bugs.chromium.org/p/chromium/issues/detail?id=17325

The issue stems from cross-domain iframe access attempts that violate the same-origin policy; even when wrapped in a try/catch block, this message is still output. See the following jsfiddle for a simple example showing that the try/catch logic evaluates correctly, but the access attempt is still logged despite the catch. 

There's a lot of interest from the adtech industry in resolving this issue, since it makes debugging in Safari browsers difficult to impossible.

[Michael Bishop]

(In reply to comment #7)
> (In reply to comment #6)
> > (In reply to comment #5)
> > > Making console only render messages that are in the viewport would solve
> > > this as well.
> > 
> > I don't think that would help here. The issue here is the deluge of
> > "blocked" messages makes the console unusable. Having the console be fast
> > but still filled with messages would still be unusable in this respect.
> 
> Related Chromium thread that resolves exactly this issue in the Chrome fork
> of webkit: https://bugs.chromium.org/p/chromium/issues/detail?id=17325
> 
> The issue stems from cross-domain iframe access attempts that violate the
> same-origin policy; even when wrapped in a try/catch block, this message is
> still output. See the following jsfiddle for a simple example showing that
> the try/catch logic evaluates correctly, but the access attempt is still
> logged despite the catch. 
> 
> There's a lot of interest from the adtech industry in resolving this issue,
> since it makes debugging in Safari browsers difficult to impossible.

Edit: Actually including the JSFidddle. :) 

http://jsfiddle.net/90bnkztj/

[Joseph Pecoraro]

This is happening on reddit.com now as well. It happens about 10+ times a second.