* 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?
<rdar://problem/25431270>
Is this better after the recent console changes?
<rdar://problem/25301506>
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.
Making console only render messages that are in the viewport would solve this as well.
(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.
(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.
(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/
This is happening on reddit.com now as well. It happens about 10+ times a second.