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•4 years ago
|
||
Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=a55d8ca4738f9b51515959de087df55e5d5999d8&tochange=7e53b5398797485e8f326bde1fcb5820afcbc8a2
Comment 2•4 years ago
|
||
BTW, Bug 1641270 does not fix this case if privacy.partition.network_state = true.
Updated•4 years ago
|
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 3•4 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•4 years ago
|
||
I've found a way to reproduce this on Windows. Thanks.
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 5•4 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•4 years ago
|
Comment 8•4 years ago
|
||
bugherder |
Assignee | ||
Updated•4 years ago
|
Updated•4 years ago
|
Comment 9•4 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•4 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•4 years ago
|
Updated•4 years ago
|
Comment 11•4 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•4 years ago
|
||
bugherder uplift |
Comment 13•4 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
•