Dragging images from websites with access control to Explorer resulted in 403 page being created instead
Categories
(Core :: Privacy: Anti-Tracking, defect, P1)
Tracking
()
People
(Reporter: yaema.vandermerwe, Assigned: timhuang)
References
(Regression)
Details
(Keywords: regression, reproducible)
Attachments
(1 file)
48 bytes,
text/x-phabricator-request
|
pascalc
:
approval-mozilla-beta+
|
Details | Review |
User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:85.0) Gecko/20100101 Firefox/85.0
Steps to reproduce:
- Log in to a website with access control (e.g. Pixiv)
- Open an access-controlled image in a new tab.
- Drag that image and drop into Explorer.
Actual results:
The file size that Firefox exposed to Explorer is noted to be a constant size instead of the size it's supposed to be. This affects any files from the website.
Examining the image file with a text editor reveals that it is in fact the website's 403 page.
Expected results:
Actual image gets created.
The browser should copy the image data from the tab, and not despatch a separate, non-access-controlled call to the website to create the resource which results in 403 pages.
This is the case (therefore, this bug didn't exist) in previous version of Firefox.
![]() |
||
Comment 1•5 years ago
|
||
Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=a55d8ca4738f9b51515959de087df55e5d5999d8&tochange=7e53b5398797485e8f326bde1fcb5820afcbc8a2
![]() |
||
Comment 2•5 years ago
|
||
BTW, Bug 1641270 does not fix this case if privacy.partition.network_state = true.
![]() |
||
Updated•5 years ago
|
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 3•5 years ago
|
||
Hi Alice,
Thanks for providing the regression window. I cannot reproduce this on my MAC though.
Would you be able to provide a link and detailed STR? And is this issue Windows exclusive? Thanks.
Assignee | ||
Comment 4•5 years ago
|
||
I've found a way to reproduce this on Windows. Thanks.
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 5•5 years ago
|
||
The channel used in Windows for Drag&Drop doesn't have the correct
cookieJarSettings. The patch fixes this issue that it will pass the
correct cookieJarSettings to the channel.
Updated•5 years ago
|
![]() |
||
Comment 8•5 years ago
|
||
bugherder |
Assignee | ||
Updated•5 years ago
|
Updated•5 years ago
|
Comment 9•5 years ago
|
||
The patch landed in nightly and beta is affected.
:timhuang, is this bug important enough to require an uplift?
If not please set status_beta
to wontfix
.
For more information, please visit auto_nag documentation.
Assignee | ||
Comment 10•5 years ago
|
||
Comment on attachment 9200445 [details]
Bug 1689600 - Making the Drag&Drop downloading be aware of cookieJarSettings on Windows platform. r?smaug
Beta/Release Uplift Approval Request
- User impact if declined: The drag&drop downloading of access-controlled images will break in Windows
- Is this code covered by automated tests?: No
- Has the fix been verified in Nightly?: Yes
- Needs manual test from QE?: Yes
- If yes, steps to reproduce: 1. Log in to a website with access control (e.g. Pixiv)
- Open an access-controlled image in a new tab.
- Drag that image and drop it into Explorer.
- Verify if the image is downloaded correctly.
- List of other uplifts needed: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): This is a simple fix and only affects Windows.
- String changes made/needed: None
Assignee | ||
Updated•5 years ago
|
Updated•5 years ago
|
Comment 11•5 years ago
|
||
Comment on attachment 9200445 [details]
Bug 1689600 - Making the Drag&Drop downloading be aware of cookieJarSettings on Windows platform. r?smaug
Low risk fix according to the author, was on nightly for a few days and this is a recent 85 regression, approved for 86 beta 8, thanks.
Comment 12•5 years ago
|
||
bugherder uplift |
Comment 13•5 years ago
|
||
Reproduced with Fx 85.0 on Windows 10.
Verified fixed with Fx 86.0b8 and Fx 87.0a1 (2021-02-09) on Windows 10.
Description
•