Closed Bug 1265966 Opened 6 years ago Closed 6 years ago
[e10s] can't drag and drop from content to navigation bar text boxes
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.
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
Should we back out the changes that landed in bug 1256952?
Assignee: nobody → enndeakin
Status: NEW → ASSIGNED
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?
(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?
I meant the regressing bug 1256952.
Alice, can you confirm that this is fixed?
I can confirm that the problem is no longer reproduced on Aurora with e10s. However, I can still reproduce the problem on Nightly and Beta with e10s. Because, the offending patch is not backed out from Nightly49.0a1 and Beta47.0b2.  https://hg.mozilla.org/mozilla-central/rev/369a5ee3a2880a4a98df3a00bf3db8d8f36b181b Mozilla/5.0 (X11; Linux i686; rv:49.0) Gecko/20100101 Firefox/49.0 ID:20160505030327  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  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
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.
Status: ASSIGNED → RESOLVED
Closed: 6 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.
You need to log in before you can comment on or make changes to this bug.