Closed Bug 1265966 Opened 5 years ago Closed 5 years ago

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

Categories

(Core :: DOM: Drag & Drop, defect, P1)

47 Branch
Unspecified
Linux
defect

Tracking

()

RESOLVED FIXED
Tracking Status
e10s + ---
firefox47 --- fixed
firefox48 --- fixed
firefox49 + fixed

People

(Reporter: terrell.kelley, Assigned: enndeakin)

References

(Blocks 1 open bug)

Details

(Keywords: regression, Whiteboard: btpp-active)

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.
Component: Untriaged → Drag and Drop
Product: Firefox → Core
Status: UNCONFIRMED → NEW
tracking-e10s: --- → ?
Ever confirmed: true
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
Blocks: 1256952
OS: Unspecified → Linux
Should we back out the changes that landed in bug 1256952?
Flags: needinfo?(enndeakin)
Whiteboard: btpp-followup-2016-04-27
Assignee: nobody → enndeakin
Status: NEW → ASSIGNED
Flags: needinfo?(enndeakin)
Whiteboard: btpp-followup-2016-04-27 → btpp-active
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?
Flags: needinfo?(karlt)
(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.
(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?
Flags: needinfo?(enndeakin)
I meant the regressing bug 1256952.
Flags: needinfo?(enndeakin)
Alice, can you confirm that this is fixed?
Flags: needinfo?(alice0775)
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
Flags: needinfo?(alice0775)
will be fixed in 47 beta build 3.
Tracking for 49, also marking fixed for 47 and 48 rather than unaffected.
I know what it going on with this.
Flags: needinfo?(karlt)
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → WORKSFORME
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?
This bug was fixed by backing out the regressing patch.
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.
Resolution: WORKSFORME → DUPLICATE
Duplicate of bug: 1256952
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.
Resolution: DUPLICATE → FIXED
You need to log in before you can comment on or make changes to this bug.