156001 2016-03-29 19:05:06 -0700 Web Inspector: Console is unusable on sites with frequent Blocked Messages (theverge.com) 2026-01-12 09:01:54 -0800 1 1 1 Unclassified WebKit Web Inspector WebKit Nightly Build All All NEW InRadar P2 Normal --- 152220 1 joepeck webkit-unassigned graouts inspector-bugzilla-changes joepeck mbish2013 nvasilyev webkit-bug-importer oldest_to_newest 1178914 0 joepeck 2016-03-29 19:05:06 -0700 * 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? 1178915 1 webkit-bug-importer 2016-03-29 19:05:33 -0700 <rdar://problem/25431270> 1194589 2 timothy 2016-05-18 20:04:09 -0700 Is this better after the recent console changes? 1196090 3 timothy 2016-05-24 17:26:53 -0700 <rdar://problem/25301506> 1245021 4 bburg 2016-10-26 21:52:25 -0700 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. 1260272 5 nvasilyev 2016-12-15 14:45:54 -0800 Making console only render messages that are in the viewport would solve this as well. 1260501 6 joepeck 2016-12-15 19:39:08 -0800 (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. 1276237 7 mbish2013 2017-02-13 10:38:59 -0800 (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. 1276240 8 mbish2013 2017-02-13 10:40:18 -0800 (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/ 1283965 9 joepeck 2017-03-06 14:32:16 -0800 This is happening on reddit.com now as well. It happens about 10+ times a second.