Bug 151815
| Summary: | Asynchronously call onerror when a content blocker blocks a link element's load | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Andrey Meshkov <am> |
| Component: | WebKit Misc. | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW | ||
| Severity: | Normal | CC: | achristensen, krzysztof.modras, mjs, webkit-bug-importer |
| Priority: | P2 | Keywords: | InRadar |
| Version: | WebKit Nightly Build | ||
| Hardware: | All | ||
| OS: | All | ||
Andrey Meshkov
The same as for https://bugs.webkit.org/show_bug.cgi?id=151649 but about "link" element.
The difference is that in case of "link" element "onerror" is not called at all.
Example:
http://jsfiddle.net/82ez45js/11/
To see what's going on block webkit.org with a content blocker.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Andrey Meshkov
This issue is still present in the latest Safari version. This is strange that Safari behavior is inconsistent, "link" is processed differently from "script" which was fixed: https://bugs.webkit.org/show_bug.cgi?id=151649
Maciej Stachowiak
Does this cause website compatibility issues when content blockers block "link" loads?
Radar WebKit Bug Importer
<rdar://problem/59584713>
Andrey Meshkov
> Does this cause website compatibility issues when content blockers block "link" loads?
It may cause compatibility issues as triggering "onerror" is a common way to let web pages know that a resource is not available. The previous issue (151649, about "script" tag) was causing a few. This one is not as important, though.
Maciej Stachowiak
It would raise the priority if this caused real compatibility issues when using content blockers, rather than just being a question of technical correctness.