Dragging tab to new window, and then back again leaves drop indicator after drop




4 years ago
a year ago


(Reporter: Nika, Unassigned)



Mac OS X

Firefox Tracking Flags

(firefox38 wontfix, firefox39 wontfix, firefox40- wontfix, firefox41+ wontfix, firefox42- affected)



(1 attachment)



4 years ago
Created attachment 8601752 [details]
Screenshot of persistent indicator

To reproduce:
Open 2 windows, each with 1 tab. Drag the tab from the first window into the first tab slot in the second window. The drop indicator will persist after the drop is completed.

(Only tested on OS X 10.10.3)

Comment 1

4 years ago
Tested on OSX 10.10.3
Firefox 37.0.2

After consecutive trials of your steps, I was able to reproduce your glitch inconsistently and with no apparent pattern.

Were you able to reproduce this every time? If not, do you notice any other pattern for causing the glitch?

Comment 2

4 years ago
I'm able to reproduce it fairly consistently, after a few tries, but it definitely doesn't happen every time.

I'm running nightly (40.0a1 (2015-05-04)).

Comment 3

4 years ago
(In reply to Michael Layzell [:mystor] from comment #2)
> I'm able to reproduce it fairly consistently, after a few tries, but it
> definitely doesn't happen every time.
> I'm running nightly (40.0a1 (2015-05-04)).

(I should clarify that I have not identified any real pattern for causing the glitch)
[Tracking Requested - why for this release]: I've been seeing this too.  It's pretty broken-looking...
tracking-firefox40: --- → ?
tracking-firefox41: --- → ?
Keywords: regression
One note that might or might not be relevant: I'm seeing this in non-e10s mode.  I haven't really tried dragging around enough in e10s mode to tell whether it happens there too.
Flags: needinfo?(gijskruitbosch+bugs)

Comment 6

4 years ago
302 mconley here too, unfortunately, I am completely swamped with 38.0.5 things. If there's no traction by next week do please needinfo me again.
Flags: needinfo?(gijskruitbosch+bugs) → needinfo?(mconley)
Keywords: regressionwindow-wanted
Ok, I just reproduced in an e10s window as well.  So the e10s bit is not relevant.
Tracking for 40+.  It sounds like this may affect versions as far back as 37 and we're not sure what caused the regression.
status-firefox38: --- → ?
status-firefox39: --- → ?
status-firefox40: --- → affected
tracking-firefox40: ? → +
tracking-firefox41: ? → +
Is there anything in the Browser Console when this occurs? Also, if you're able to reproduce this reliably, show me in person and we can investigate. My desk is < 1 meter from yours. :)
Flags: needinfo?(mconley) → needinfo?(michael)
> Is there anything in the Browser Console when this occurs? 

Not that I saw.
I just saw mystor reproduce this on his machine, and I didn't see anything useful in the console. I'm going to give mystor an instrumented build to see if we can figure out what's happening here.
Flags: needinfo?(michael)
Flags: needinfo?(mconley)


4 years ago
Duplicate of this bug: 1164420
I gave mystor an instrumented build to see if I could get a log of what was going wrong, but I think the logging in the build threw off the race (since I believe we must be hitting some kind of race here) so that he could never reproduce it. :/
Flags: needinfo?(mconley)
As we are going to build 40 rc1, I don't think we will have a fix ready in time. We will take a fix for 41.
status-firefox38: ? → wontfix
status-firefox39: ? → wontfix
status-firefox40: affected → wontfix
status-firefox41: --- → affected
tracking-firefox40: + → -
I'm able to reproduce this fairly consistently dragging several tabs into a second window. If I'm not mistaken this is the error thrown in the console:

13:29:06.152 Handler function threw an exception: [Exception... "Component returned failure code: 0x80004002 (NS_NOINTERFACE) [nsIWebProgress.DOMWindow]"  nsresult: "0x80004002 (NS_NOINTERFACE)"  location: "JS frame :: resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/actors/webbrowser.js :: TabActor.prototype._docShellsToWindows/< :: line 1066"  data: no]
Stack: TabActor.prototype._docShellsToWindows/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/actors/webbrowser.js:1066:11
TabActor.prototype._docShellsToWindows@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/actors/webbrowser.js:1063:1
TabActor.prototype._notifyDocShellsUpdate@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/actors/webbrowser.js:1089:19
TabActor.prototype._onDocShellCreated/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/actors/webbrowser.js:1041:7
makeInfallible/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/DevToolsUtils.js:82:14
Line: 1066, column: 01 DevToolsUtils.js:58:0
While this is a valid issue, this is not something that is consistently impacting a large number of end-users, therefore this is not a release blocking issue for FF41 and wont fix.

Tracked for FF42 which the hope that we can get a consistent repro to further investigate and fix.
status-firefox41: affected → wontfix
status-firefox42: --- → affected
tracking-firefox42: --- → +
I've been trying to reproduce this on win10 to help track down a regression range, but so far have been unable to. Has anybody seen this on anything other than OSX?
I am going to stop tracking it as we shipped several versions with this bug.
tracking-firefox42: + → -
Michael or Stuart, are you still able to reproduce this?
Flags: needinfo?(sphilp)
Flags: needinfo?(michael)

Comment 20

3 years ago
Yes, it still happens to me occasionally.
Flags: needinfo?(michael)
Any chance you can try tracking it down with mozregression? http://mozilla.github.io/mozregression/
Yeah I can still reproduce and mozregression still has the bug way back in 2009-01-01.
Flags: needinfo?(sphilp)
Keywords: regression, regressionwindow-wanted
Markus, you're the Mac expert these days I hear? :)
Flags: needinfo?(mstange)

Comment 24

3 years ago
I tried to do some mozregressioning on it, and I found it way too hard to reliably reproduce the bug :-/. If sphilip says it was around in '09 though, I'm not sure how much help I would be :S
Unlikely to be a widget issue, probably something in browser frontend JS.
What did you want my input on? If the bug has existed for that long, a regression range probably won't be all that useful. I think somebody with browser frontend knowledge just needs to be able to reproduce this consistently and have some time to debug this.
Flags: needinfo?(mstange) → needinfo?(ryanvm)
Fair enough, thanks.
Flags: needinfo?(ryanvm)


3 years ago
Duplicate of this bug: 1246444


3 years ago
Keywords: steps-wanted
OS: Unspecified → Mac OS X


3 years ago
Duplicate of this bug: 1258254

Comment 29

3 years ago
I find that the bug will more likely occur if there are more content intensive tabs present. If I just have a couple of browser windows with blank tabs and move those around it's not as likely but once I add some more tabs with more content like wikia articles or facebook or anything with flash content it happens a much larger percentage of the time.


2 years ago
Duplicate of this bug: 1207834


2 years ago
Duplicate of this bug: 1312454


2 years ago
Duplicate of this bug: 1330057


2 years ago
Duplicate of this bug: 1343023
You need to log in before you can comment on or make changes to this bug.