[DNR] Support matching view-source: requests
Categories
(WebExtensions :: Request Handling, enhancement, P2)
Tracking
(Not tracked)
People
(Reporter: robwu, Unassigned)
References
(Blocks 1 open bug)
Details
(Whiteboard: [addons-jira])
Currently, our DNR implementation cannot match view-source:
-URLs, as these internally are view-source:
-URIs.
We should support matching of view-source: requests in DNR.
And it would probably make sense to introduce a new resourceType (and make that available to webRequest as well, which would fix bug 1683646).
An interesting aspect to consider: an empty rule condition matches all resourceTypes except main_frame. The rationale behind this is that content blockers typically want to block all subresources, but permit direct navigation to a resource. Following this reasoning, it would make sense to treat view-source: requests similarly as main_frame requests.
For comparison: When we introduced view-source:-support in webRequest, we did so by normalizing the URL to the part without the view-source:
-prefix: https://searchfox.org/mozilla-central/diff/785c75dc53cbef7ff24d5b73f8c64912ec161617/toolkit/components/extensions/webrequest/ChannelWrapper.cpp#536 . The resourceType is still main_frame
, so extensions are unable to differentiate between view-source:-requests and navigations (bug 1683646).
Updated•2 years ago
|
Reporter | ||
Updated•2 years ago
|
Reporter | ||
Comment 1•2 years ago
|
||
FYI: Safari doesn't support view-source:
-URLs, so from the perspective of cross-browser compatibility, it's mainly Firefox vs Chromium here.
Since DNR is designed around standard URLs and not really with nested URLs in mind, and view-source:
cannot be redirected to anything else, I'm inclined to support view-source:
-URL matching by its regular URL, and introducing a new resourceType
for it.
Description
•