1487263 - [macOS] Drag and drop images saves 0kb file

Status: VERIFIED FIXED

(Core :: Widget: Cocoa, defect)

Description

[vurtomatic]

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

Comment 1

[vurtomatic]

Attachment: about:support raw

Comment 2

[Tooru Fujisawa [:arai]]

regression range
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=8a7fd632104453b557ca73a335626d4f24427b50&tochange=ddb29b481834c16a608ff6e4dd8382155239a94f

apparently aTriggeringPrincipal is null there?

Comment 3

[:Gijs (he/him)]

(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...

Comment 4

[:Gijs (he/him)]

(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.

Comment 5

[:Gijs (he/him)]

I think I figured it out.

Comment 6

[:Gijs (he/him)]

Attachment: Bug 1487263 - set requesting principal for macOS drags, r?mstange

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).

Comment 7

[:Gijs (he/him)]

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 8

[Markus Stange [:mstange]]

Comment on attachment 9005198 [details]
Bug 1487263 - set requesting principal for macOS drags, r?mstange

Markus Stange [:mstange] has approved the revision.

Comment 9

[:Gijs (he/him)]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=a07c5e339784beb785095c84e44deed6d56d6a2b

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/57204974417c
set requesting principal for macOS drags, r=mstange

Comment 12

[Raul Gurzau (:RaulG)]

https://hg.mozilla.org/mozilla-central/rev/57204974417c

Comment 14

[ovidiu boca[:Ovidiu]]

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.

Comment 16

[Georg Koppen]

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?

Comment 17

[Georg Koppen]

I guess we just do a

nsCOMPtr<nsINode> node = do_QueryInterface(mSourceNode);

and go with that.