1683646 - webRequest listener can't detect view-source request separately from regular navigation requests

Status: REOPENED

(WebExtensions :: Request Handling, enhancement, P3)

Description

[Tom S. (please needinfo tschuster)]

Our extension livemarks redirects URLs for RSS feeds to an internal RSS previewer using a moz-extension URL (source). This preview also contains a view-source link for convenience, which we don't want to redirect back to the preview page of course.

Right now it seems to be impossible to detect requests to view-source URLs. The url property just strips the view-source: scheme.

Comment 1

[kernp25]

Maybe add details.isViewSource or details.originUrl should be view-source:https://bugzilla.mozilla.org/show_bug.cgi?id=1683646?

Comment 2

[Shane Caraveo (:mixedpuppy)]

Rather than something specific, lets add a sub_type property that can be an array of strings. This could be useful for future properties if necessary, but we could also use this for fetch which is currently reported as XHR in the type property.

Comment 3

[Rob Wu [:robwu]]

Since main_frame and sub_frame filters are commonly used by extensions with the intent to change the content, either by content scripts or stream filters, I would prefer a new ResourceType over a new sub_type property. I see little value in a sub_type to distinguish fetch from XHR, for the lack of use cases where it would make a difference (and in the end, everything can be a fetch, especially with Service Workers that supposedly fetches on behalf of web pages).

Comment 4

[Timo Tijhof]

This affected the web extension we use for development and deployment of Wikipedia.org (https://gerrit.wikimedia.org/g/performance/WikimediaDebug/). It has always worked in Chromium (at least since Chromium 61), but did not work in Firefox 67 when we first tested it.

Testing on Firefox 98 today, however, it seems this has been fixed since. We use webRequest.onBeforeSendHeaders.addListener for this purpose.
https://gerrit.wikimedia.org/g/performance/WikimediaDebug/+/refs/tags/2.4.5/background.js#227

Comment 5

[Rob Wu [:robwu]]

This was implemented in bug 1657916 (https://hg.mozilla.org/mozilla-central/rev/8fd81380d432).

Comment 6

[kernp25]

No, i think this bug was about detecting view-source urls and then not handling these urls?

Comment 7

[Rob Wu [:robwu]]

(In reply to kernp25 from comment #6)

No, i think this bug was about detecting view-source urls and then not handling these urls?

You're right, I'll re-open.

Comment 4 interpreted the original title differently, so I've renamed the title to clarify it.

Comment 8

[Tom S. (please needinfo tschuster)]

This is still a problem. What solution would be acceptable?

Comment 9

[Rob Wu [:robwu]]

Would classifying view-source as "other" be an acceptable outcome to you?

I asked for the appetite for a distinct resourceType for view-source requests, and Oliver (Chrome representative) wondered whether "other" would work for the use case.

Meeting notes are at https://github.com/w3c/webextensions/pull/1061 , where I also referenced this bug.