1265966 - [e10s] can't drag and drop from content to navigation bar text boxes

Status: RESOLVED FIXED

(Core :: DOM: Copy & Paste and Drag & Drop, defect, P1)

Description

[Terrell Kelley]

User Agent: Mozilla/5.0 (X11; Linux i686; rv:47.0) Gecko/20100101 Firefox/47.0
Build ID: 20160419004026

Steps to reproduce:

1. open any web page.
2. Select text
3. Drag to search box

Alternative:
1. open any web page
2. drag image or link to search bar


Actual results:

The drag and drop is canceled upon drop.


Expected results:

The selected text should be copied to the search bar. An image should copy its URL to the search box. A link should copy the target URL to the box.

ADDITIONAL INFORMATION
This is an e10s regression. It works fine if I open a non-e10s window. 

There is a "Search<provider> for <text>" right click option, but it only searches selected text (or the text of a link), and is limited to only the default search provider. Dragging and dropping allows you to then pick a different search provider.

This also breaks for dragging and dropping to the address bar.

Comment 1

[Alice0775 White]

Regression window:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=305f923c6f9c953518c9e8bcfb70bcae3c7f8af8&tochange=aa65acd9650aa99e5452dd7344ff06d387c6e3f9

Regressed by:
aa65acd9650a	Neil Deakin — Bug 1256952, send a dragexit at remote process when leaving the remote frame, r=smaug

Comment 2

[Andrew Overholt [:overholt]]

Should we back out the changes that landed in bug 1256952?

Comment 3

[Neil Deakin]

I spent quite a bit of time investigating this. For some reason, if you drag from the content process to the toolbar/urlbar somewhat slowly, we stop receiving any dragmotion events, or any drag notifications at all from gtk while over the toolbar/urlbar area. However, once you move the mouse outside the window or onto the titlebar and back again, everything starts working again.

Also, it often works if you move the mouse quickly enough from the content area to the toolbar.

Backing out the patch in bug 8735559 fixes this but I can't see why.

I can't see any difference in logs. Karl, any ideas here?

Comment 4

[Terrell Kelley]

(In reply to Neil Deakin from comment #3)
> I spent quite a bit of time investigating this. For some reason, if you drag
> from the content process to the toolbar/urlbar somewhat slowly, we stop
> receiving any dragmotion events, or any drag notifications at all from gtk
> while over the toolbar/urlbar area. However, once you move the mouse outside
> the window or onto the titlebar and back again, everything starts working
> again.
> 
> Also, it often works if you move the mouse quickly enough from the content
> area to the toolbar.

My experience differs. The second paragraph is accurate--but it requires the text to be really close to the search box to make it in time. But dragging out and back in does not do anything. The text still "flies" back to where it was.

Comment 5

[David Durst [:ddurst]]

(In reply to Neil Deakin from comment #3)
> Backing out the patch in bug 8735559 fixes this but I can't see why.

Wrong bug number?

Comment 6

[Neil Deakin]

I meant the regressing bug 1256952.

Comment 7

[David Durst [:ddurst]]

Alice, can you confirm that this is fixed?

Comment 8

[Alice0775 White]

I can confirm that the problem is no longer reproduced on Aurora[2] with e10s.

However, I can still reproduce the problem on Nightly[1] and Beta[3] with e10s.

Because, the offending patch is not backed out from Nightly49.0a1 and Beta47.0b2.

[1]
https://hg.mozilla.org/mozilla-central/rev/369a5ee3a2880a4a98df3a00bf3db8d8f36b181b
Mozilla/5.0 (X11; Linux i686; rv:49.0) Gecko/20100101 Firefox/49.0 ID:20160505030327

[2]
https://hg.mozilla.org/releases/mozilla-aurora/rev/b6738ca644382710da35245e0c2e01479befeb37
Mozilla/5.0 (X11; Linux i686; rv:48.0) Gecko/20100101 Firefox/48.0 ID:20160505004017

[3]
https://hg.mozilla.org/releases/mozilla-beta/rev/6f82d30fe05e1412e744cb76af86f0c9ffe509d4
Mozilla/5.0 (X11; Linux i686; rv:47.0) Gecko/20100101 Firefox/47.0 ID:20160502152141

Comment 9

[Jim Mathies [:jimm]]

will be fixed in 47 beta build 3.

Comment 10

[Liz Henry (:lizzard) (relman/hg->git project)]

Tracking for 49, also marking fixed for 47 and 48 rather than unaffected.

Comment 11

[Neil Deakin]

I know what it going on with this.

Comment 12

[Terrell Kelley]

I'm a big confused? If it still affects Firefox 49, how can it be closed as WORKSFORME? Was it fixed in some other bug?

Comment 13

[Neil Deakin]

This bug was fixed by backing out the regressing patch.

Comment 14

[Liz Henry (:lizzard) (relman/hg->git project)]

Let's call this a duplicate of bug 1256952 then, since the patch there should fix this bug too. The fix hasn't landed yet in 49. Sorry for the confusion.

Comment 15

[Neil Deakin]

No, that's not correct. This is a regression from bug 1256952 which has been backed out from all branches. This bug, 1265966, is thus no longer present in any branch. The backout was done with a followup patch due to some conflict rather than an actual backout.