This appears to be similar to Mac OSX bug 1204944. I cannot duplicate it on Firefox 41, it also resumes working normally if I open a non-e10s window. To reproduce: - Run Nightly with 2 or more tabs - Attempt to drag a tab either out of the window or in a different order with mouse. Right clicking a tab to move to a new window works perfectly, this seems to only affect the actual operation of dragging a tab. Configuration: Arch Linux x86_64 on Gnome 3.18 with gtk 3.18.2 Nvidia proprietary 355.11 drivers.

I think we are running into the same issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1214358

One thing to note is I use a dark theme, which Firefox 44 respsects, but Firefox 41 doesn't, so I'm not sure Firefox is using gtk3 yet.

Yours is specific to GTK3 though, it might be related but my workaround is to disable electrolysis, so I've filed as an e10s bug.

Karl, what do you want to do with this?

(In reply to Vash63 from comment #3) > Yours is specific to GTK3 though, it might be related but my workaround is > to disable electrolysis, so I've filed as an e10s bug. Could this be specific to GTK3 and e10s? Have you observed the bug with GTK2 and e10s? Did older nightlies demonstrate this bug? (Release and Nightly trains differ in both GTK libs and e10s defaults.) Do you have high dpi monitor settings? (In reply to Brad Lassey [:blassey] (use needinfo?) from comment #5) > Karl, what do you want to do with this? We don't have enough information to know where this belongs. FWIW I suspect this may be the same issue as bug 1214358, but that is not clear at this stage.

I do not remember this happening on older nightlies. Also, it might be specific to gtk3.18 because that update was also recent. I don't have any e10s builds using gtk2 to test with installed unfortunately.

(In reply to Karl Tomlinson (ni?:karlt) from comment #6) > Do you have high dpi monitor settings? These may not need to be explicitly as some desktop environments will pick scale factors on high dpi monitors. Is there a high dpi monitor involved? The easiest way to test may be to quit and run with GDK_SCALE=1 in the environment to see whether things look different.

I do have a high DPI monitor (115ish) but am not using scaling. Confirmed with GDK_SCALE=1 in my environment. No difference in this issue.

Thanks. I can only reproduce a problem with incorrect coordinates when GDK_SCALE is not unit, and that's independent of e10s. That's different from this bug. One thing that could help find the cause of this would be a log of a quick run and one attempted drag with NSPR_LOG_MODULES=nsDragService:5 in the environment. Another is finding a regression range. Many use http://mozilla.github.io/mozregression/ for this.

Using moz-regression tool, I found that it is an old regression. Last working nightly : August 11, 2015 => https://hg.mozilla.org/mozilla-central/rev/8cba870a352c First broken nightly : August 12, 2015 => https://hg.mozilla.org/mozilla-central/rev/d4f3a8a75577e4af2914a4e899ca2e724f9715c4 Will look into inbound builds to shrink regression window.

Using inbound builds, I found when the regression was introduced : https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=7042219cf7f332ce97605958506557a9ae7e9402&tochange=884385e6f556fc07d33ddd790474d459a7e55aab It is bug 863512.