Closed Bug 1487263 Opened Last year Closed Last year

[macOS] Drag and drop images saves 0kb file

Categories

(Core :: Widget: Cocoa, defect)

63 Branch
Unspecified
macOS
defect
Not set

Tracking

()

VERIFIED FIXED
mozilla63
Tracking Status
firefox-esr52 --- unaffected
firefox-esr60 --- unaffected
firefox61 --- unaffected
firefox62 --- unaffected
firefox63 + verified
firefox64 --- verified

People

(Reporter: vurtomatic, Assigned: Gijs)

References

Details

(Keywords: regression)

Attachments

(2 files)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:63.0) Gecko/20100101 Firefox/63.0
Build ID: 20180829100131

Steps to reproduce:

1) Open latest Nightly 63.0a1 (2018-08-29) (64-bit)
2) Drag image on webpage to folder or desktop



Actual results:

1) Image is saved into folder or desktop
2) Image isn't viewable because it's 0kb
3) Bug reproduced with clean profile



Expected results:

1) Image is saved into folder or desktop
2) Image is viewable
Attached file about:support raw
regression range
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=8a7fd632104453b557ca73a335626d4f24427b50&tochange=ddb29b481834c16a608ff6e4dd8382155239a94f

apparently aTriggeringPrincipal is null there?
Blocks: 1473507
Status: UNCONFIRMED → NEW
Component: Drag and Drop → DOM: Security
Ever confirmed: true
Flags: needinfo?(gijskruitbosch+bugs)
Keywords: regression
(In reply to Tooru Fujisawa [:arai] from comment #2)
> regression range
> https://hg.mozilla.org/integration/autoland/
> pushloghtml?fromchange=8a7fd632104453b557ca73a335626d4f24427b50&tochange=ddb2
> 9b481834c16a608ff6e4dd8382155239a94f
> 
> apparently aTriggeringPrincipal is null there?

Can you elaborate on the STR? I can't reproduce as-is (tested on Windows 10, by going to google.com, right clicking image, 'view background image', then dragging resulting image to the desktop, on a local m-c build from the last few hours). Given the patch, seems unlikely this is macOS-only, so I assume I'm missing something else about the STR here...
Flags: needinfo?(gijskruitbosch+bugs) → needinfo?(arai.unmht)
(In reply to :Gijs (he/him) from comment #3)
> (In reply to Tooru Fujisawa [:arai] from comment #2)
> > regression range
> > https://hg.mozilla.org/integration/autoland/
> > pushloghtml?fromchange=8a7fd632104453b557ca73a335626d4f24427b50&tochange=ddb2
> > 9b481834c16a608ff6e4dd8382155239a94f
> > 
> > apparently aTriggeringPrincipal is null there?
> 
> Can you elaborate on the STR? I can't reproduce as-is (tested on Windows 10,
> by going to google.com, right clicking image, 'view background image', then
> dragging resulting image to the desktop, on a local m-c build from the last
> few hours). Given the patch, seems unlikely this is macOS-only, so I assume
> I'm missing something else about the STR here...

OK, I *can* actually reproduce on mac, and checked the exact same steps do work on Windows.

It seems there is indeed no triggering principal. That's because the code here: https://searchfox.org/mozilla-central/rev/2fe43133dbc774dda668d4597174d73e3969181a/dom/base/nsContentAreaDragDrop.cpp#347-349 gets a nullptr as the requesting principal. :arai, do you know why that'd be? I'm not that familiar with the dnd code, and I don't know how that principal is supposed to be set, or why it's broken on mac but not on Windows.
OS: Unspecified → Mac OS X
Summary: Drag and drop images saves 0kb file → [macOS] Drag and drop images saves 0kb file
I think I figured it out.
Assignee: nobody → gijskruitbosch+bugs
Status: NEW → ASSIGNED
Flags: needinfo?(arai.unmht)
The requesting principal is now required for saving content through
nsIWebBrowserPersist, and so drag sessions on macOS need to provide one, just
like drag sessions on Windows already do (see bug 664717).
Component: DOM: Security → Widget: Cocoa
We might want to clone this bug for Linux if the same issue manifests there, and then end up fixing the GTK drag session implementation too, if we can...
Comment on attachment 9005198 [details]
Bug 1487263 - set requesting principal for macOS drags, r?mstange

Markus Stange [:mstange] has approved the revision.
Attachment #9005198 - Flags: review+
Pushed by gijskruitbosch@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/57204974417c
set requesting principal for macOS drags, r=mstange
Duplicate of this bug: 1487038
https://hg.mozilla.org/mozilla-central/rev/57204974417c
Status: ASSIGNED → RESOLVED
Closed: Last year
Resolution: --- → FIXED
Target Milestone: --- → mozilla63
Duplicate of this bug: 1487370
I verified this issue on Mac OS X 10.12 and 10.13 with FF Beta 63.0b3 and FF Nightly 64.0a1(2018-09-05) and I can confirm the fix, the issue is no longer reproducible.
Status: RESOLVED → VERIFIED
Flags: qe-verify+
Duplicate of this bug: 1489343

Gijs: I am trying to use this for Tor Browser as part of the backport of 1469916 but the change in this bug does not compile for ESR 60 for macOS:

18:01.64 /var/tmp/build/firefox-394ffba812d6/widget/cocoa/nsDragService.mm:330:64: error: no member named
'NodePrincipal' in 'nsIDOMNode'
18:01.64 currentTransferable->SetRequestingPrincipal(mSourceNode->NodePrincipal());
~~~~~~~~~~~ ^

Any hint on what we ideally should replace that with?

Flags: needinfo?(gijskruitbosch+bugs)

I guess we just do a

nsCOMPtr<nsINode> node = do_QueryInterface(mSourceNode);

and go with that.

Flags: needinfo?(gijskruitbosch+bugs)
You need to log in before you can comment on or make changes to this bug.