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).

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.