1684957 - webRequest.onBeforeSendHeaders does not fire for image request triggered by drag-and-drop to Windows File Explorer

Status: NEW

(WebExtensions :: Request Handling, defect, P3)

Description

[jscher2000]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:84.0) Gecko/20100101 Firefox/84.0

Steps to reproduce:

Install https://addons.mozilla.org/firefox/addon/dont-accept-webp/ which strips image/webp from all Accept headers sent by the browser.

Open an image from a server that opportunistically applies WebP compression to JPEG files, for example, https://cdn.shopify.com/s/files/1/1075/6524/products/DF95_Complete_with_A_Rig.jpg?v=1458355119

Drag the image to the desktop or Windows File Explorer window to download it.

Actual results:

Firefox re-requests the image in the background, but the Accept header is not modified by the extension. Accordingly, although the file name ends with .jpg it actually is .webp internally.

Expected results:

Firefox's re-request should fire the extension listener so that the Accept header can be modified. This would make drag-and-drop consistent with other requests triggered by saving an image.

https://github.com/jscher2000/dont-accept-webp/issues/1#issuecomment-754180880

Comment 1

[Alex Cornestean]

Hello,

I’ve attempted to reproduce the issue on the latest Nightly (86.0a1/20210105215658), Beta (85.0b5/20210105185604) and Release (84.0.1/20201221152838) under Windows 10 x64 and I’m not entirely sure of the results I have obtained to properly confirm the report and set the appropriate flags.

This is what I’ve obtained so far:

“Drag&Drop” to download the image (see the “drag and drop” screenshot with the extension turned off and then on)

1. With the extension turned off

• in the web console, under the Network tab, for the GET request, the Type is listed as webp
• dragging and dropping the image to Desktop will generate a GET request which has this Accept Header: image/webp,/
• the downloaded image is listed as .webp

2. With the extension turned on

• in the web console, under the Network tab, for the GET request, the Type is listed as jpeg
• dragging and dropping the image to Desktop will generate a GET request which has this Accept Header: image/webp,/ ~ same as with the extension turned off
• the downloaded image is listed as .jpg

“Save Image As...” to download the image (see the “save image as” screenshot with the extension turned on and then off – did it in reverse)

1. With the extension turned off

• in the web console, under the Network tab, for the GET request, the Type is listed as webp
• downloading the image to Desktop will generate a GET request which has this Accept Header: image/webp,/
• the downloaded image is listed as .webp

2. With the extension turned on

• in the web console, under the Network tab, for the GET request, the Type is listed as jpeg
• downloading the image to Desktop will generate a GET request which has this Accept Header: ,/
• the downloaded image is listed as .jpg

It would be much appreciated if you could confirm that these are indeed the correct results so I may set the proper status and flags for the issue. Thank you !

Comment 2

[Alex Cornestean]

Attachment: drag and drop.png

Comment 3

[Alex Cornestean]

Attachment: save image as.png

Comment 4

[jscher2000]

Thanks, Alex.

(In reply to Alex Cornestean from comment #1)

Hello,

I’ve attempted to reproduce the issue on the latest Nightly (86.0a1/20210105215658), Beta (85.0b5/20210105185604) and Release (84.0.1/20201221152838) under Windows 10 x64 and I’m not entirely sure of the results I have obtained to properly confirm the report and set the appropriate flags.

This is what I’ve obtained so far:

“Drag&Drop” to download the image (see the “drag and drop” screenshot with the extension turned off and then on)

1. With the extension turned off

• in the web console, under the Network tab, for the GET request, the Type is listed as webp
• dragging and dropping the image to Desktop will generate a GET request which has this Accept Header: image/webp,/
• the downloaded image is listed as .webp

This, this is the expected result.

2. With the extension turned on

• in the web console, under the Network tab, for the GET request, the Type is listed as jpeg
• dragging and dropping the image to Desktop will generate a GET request which has this Accept Header: image/webp,/ ~ same as with the extension turned off
• the downloaded image is listed as .jpg

Unfortunately, Firefox is assigning the extension associated with the content-type of the image prior to the final retrieval. The file actually is a WebP file that is identical to the earlier download. And you can tell from the Accept header that the extension listener did not fire.

“Save Image As...” to download the image (see the “save image as” screenshot with the extension turned on and then off – did it in reverse)

1. With the extension turned off

• in the web console, under the Network tab, for the GET request, the Type is listed as webp
• downloading the image to Desktop will generate a GET request which has this Accept Header: image/webp,/
• the downloaded image is listed as .webp

2. With the extension turned on

• in the web console, under the Network tab, for the GET request, the Type is listed as jpeg
• downloading the image to Desktop will generate a GET request which has this Accept Header: ,/
• the downloaded image is listed as .jpg

Yes, in this case, the .jpg file really is a JPEG file (much larger than the .webp file).

(At some point I'm going to upload a new version to fix that leading comma left over from my removal of "image/webp" from the Accept header. But for now it's a clear signature of the extension listener having fired for a request.)

Comment 5

[Alex Cornestean]

Thank you for the confirmation !

I will now set the status and flags accordingly.

Comment 6

[Tomislav Jovanovic :zombie]

This is similar to bug 1453452, though slightly different since there's no UI element we could turn into a content iframe, so the solution might need to involve setting the appropriate triggering principal.