Summary: | Web Inspector: Console is unusable on sites with frequent Blocked Messages (theverge.com) | ||
---|---|---|---|
Product: | WebKit | Reporter: | Joseph Pecoraro <joepeck> |
Component: | Web Inspector | Assignee: | Nobody <webkit-unassigned> |
Status: | NEW --- | ||
Severity: | Normal | CC: | graouts, inspector-bugzilla-changes, joepeck, mbish2013, nvasilyev, webkit-bug-importer |
Priority: | P2 | Keywords: | InRadar |
Version: | WebKit Nightly Build | ||
Hardware: | All | ||
OS: | All | ||
Bug Depends on: | |||
Bug Blocks: | 152220 |
Description
Joseph Pecoraro
2016-03-29 19:05:06 PDT
Is this better after the recent console changes? 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. |