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

Status: NEW

(Firefox :: Tabbed Browser, defect)

Description

[Nika Layzell [:nika] (ni? for response)]

Attachment: 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

[lanreb]

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

[Nika Layzell [:nika] (ni? for response)]

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

[Nika Layzell [:nika] (ni? for response)]

(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)

Comment 4

[Boris Zbarsky [:bzbarsky]]

[Tracking Requested - why for this release]: I've been seeing this too.  It's pretty broken-looking...

Comment 5

[Boris Zbarsky [:bzbarsky]]

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.

Comment 6

[:Gijs (he/him)]

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.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Ok, I just reproduced in an e10s window as well.  So the e10s bit is not relevant.

Comment 8

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

Tracking for 40+.  It sounds like this may affect versions as far back as 37 and we're not sure what caused the regression.

Comment 9

[Mike Conley (:mconley) (:⚙️)]

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. :)

Comment 10

[Boris Zbarsky [:bzbarsky]]

> Is there anything in the Browser Console when this occurs? 

Not that I saw.

Comment 11

[Mike Conley (:mconley) (:⚙️)]

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.

Comment 13

[Mike Conley (:mconley) (:⚙️)]

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. :/

Comment 14

[Sylvestre Ledru [:Sylvestre]]

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.

Comment 15

[Stuart Philp :sphilp]

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

Comment 16

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

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.

Comment 17

[Ryan VanderMeulen [:RyanVM]]

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?

Comment 18

[Sylvestre Ledru [:Sylvestre]]

I am going to stop tracking it as we shipped several versions with this bug.

Comment 19

[Ryan VanderMeulen [:RyanVM]]

Michael or Stuart, are you still able to reproduce this?

Comment 20

[Nika Layzell [:nika] (ni? for response)]

Yes, it still happens to me occasionally.

Comment 21

[Ryan VanderMeulen [:RyanVM]]

Any chance you can try tracking it down with mozregression? http://mozilla.github.io/mozregression/

Comment 22

[Stuart Philp :sphilp]

Yeah I can still reproduce and mozregression still has the bug way back in 2009-01-01.

Comment 23

[Ryan VanderMeulen [:RyanVM]]

Markus, you're the Mac expert these days I hear? :)

Comment 24

[Nika Layzell [:nika] (ni? for response)]

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

Comment 25

[Markus Stange [:mstange]]

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.

Comment 26

[Ryan VanderMeulen [:RyanVM]]

Fair enough, thanks.

Comment 29

[Autre31415]

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.

Comment 34

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 7 duplicates.
:dao, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 35

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.