587990 - TabCandy arbitrarily creates new groups / orphans tabs in empty space after hovering over "Move to Group..." menu item

Status: VERIFIED FIXED

(Firefox Graveyard :: Panorama, defect, P1)

Description

[Dão Gottwald [:dao]]

In a session without any grouped tabs:

- open a tab's context menu
- hover over "Move This Tab To..."
- dismiss the context menu
- open a new tab

result: all tabs except the new one disappear

Comment 1

[Michael Lefevre]

I've had this happen as well, but I can't reproduce reliably. Bug 587472 sounds similar though, and a couple of people mentioned something similar on MozillaZine forums (complaining that tabcandy was stealing their tabs when they had never used it and didn't want to)

Comment 2

[u88484]

Confirmed.  Switching tabs instead of opening a new one sometimes causes this.  Seems to only happen once per session though.

Comment 3

[Stuart Parmenter]

This is really annoying and a major usability issue -- requires me to restart the browser

Comment 4

[Michael Yoshitaka Erlewine [:mitcho]]

(In reply to comment #0)
> In a session without any grouped tabs:
> 
> - open a tab's context menu
> - hover over "Move This Tab To..."
> - dismiss the context menu
> - open a new tab
> 
> result: all tabs except the new one disappear

I'm unable to reproduce this both in beta 4 and on trunk.

Comment 5

[Mike Beltzner [:beltzner, not reading bugmail]]

Dao/Stuart/Kurt - reopen if you're still seeing this on latest nightly, until then, I'm resolving this as WFM, likely fixed by another bug.

Comment 6

[u88484]

(In reply to comment #5)
> Dao/Stuart/Kurt - reopen if you're still seeing this on latest nightly, until
> then, I'm resolving this as WFM, likely fixed by another bug.

I just reproduced this and Stuart was talking about this yesterday evening on irc.

Comment 7

[Mike Beltzner [:beltzner, not reading bugmail]]

Kurt: can we get the build ID of the version you repro'd on and the OS?

Comment 8

[u88484]

(In reply to comment #7)
> Kurt: can we get the build ID of the version you repro'd on and the OS?

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b5pre) Gecko/20100827 Minefield/4.0b5pre
Windows 7

Same steps as comment 0 but I switched tabs (by left-clicking on one) instead of opening a new tab.

Comment 10

[u88484]

Is there anything I can do here to help figure out what is going on here to fix this, like use a debug build or something?

Comment 11

[u88484]

Raymond Lee, this is marked blocking beta 6...any status here?

This is very, very annoying and I "lose" my tabs countless times a times a day and end up finding dozens upon dozens of tabs that I lost throughout the day.  No wonder why my startup times are slow as molasses.

Beltzner, gavin...can one of you please poke someone to fix this?

Comment 12

[Dennis Jacobfeuerborn]

I had to stop using Firefox 4 for the time being because every time I "undo close tab" I absentmindedly cross "move to group" and mess up my session.

Comment 13

[Aza Raskin [:aza]]

I cannot duplicate this bug using any of the above provide methods. Whether it is undoing a close tab, or hovering on the move-to context menu. Perhaps it got fixed while working on other bugs? If anyone can reproduce, please reopen this bug.

Note: there have been reports of strange interactions with Private Browsing mode: https://bugzilla.mozilla.org/show_bug.cgi?id=594644

Comment 14

[u88484]

I can still reproduce with today's nightly.  I don't use PB mode.

Comment 15

[u88484]

(In reply to comment #14)
> I can still reproduce with today's nightly.  I don't use PB mode.

Hmm, I've only been able to reproduce it once even after restarting a few times.  Not sure why it doesn't always happen.  I forgot to add that I do get this in the error console:

trace: tabview assert: Must provide a function
iQClass_unbind("keydown",null)@chrome://browser/content/tabview.js:709
switchToBeforeMode()@chrome://browser/content/tabview.js:7582
()@chrome://browser/content/tabview.js:7537
SearchEventHandlerClass()@chrome://browser/content/tabview.js:7510
@chrome://browser/content/tabview.js:7709

Comment 16

[u88484]

Not sure what I did for this to happen but could be related.

tabview assert: should already be linkedTabItems_update([object XULElement])@chrome://browser/content/tabview.js:4740
([object XULElement],[object Event])@chrome://browser/content/tabview.js:4691
((function (tab) {if (tab.ownerDocument.defaultView != gWindow || tab.pinned) {return;}self.update(tab);}),0,[object Array])@resource:///modules/tabview/AllTabs.jsm:127
([object Event])@resource:///modules/tabview/AllTabs.jsm:125
_tabAttrModified([object XULElement])@chrome://browser/content/tabbrowser.xml:888
updateCurrentBrowser()@chrome://browser/content/tabbrowser.xml:855
onselect([object Event])@chrome://browser/content/browser.xul:1
set_selectedIndex(4)@chrome://global/content/bindings/tabbox.xml:654
set_selectedPanel([object XULElement])@chrome://global/content/bindings/tabbox.xml:673
set_selectedIndex(5)@chrome://global/content/bindings/tabbox.xml:394
set_selectedItem([object XULElement])@chrome://global/content/bindings/tabbox.xml:426
set_selectedTab([object XULElement])@chrome://global/content/bindings/tabbox.xml:106
set_selectedTab([object XULElement])@chrome://browser/content/tabbrowser.xml:1895
_blurTab([object XULElement])@chrome://browser/content/tabbrowser.xml:1614
removeTab([object XULElement],[object Object])@chrome://browser/content/tabbrowser.xml:1400
onxblclick([object MouseEvent])@chrome://browser/content/tabbrowser.xml:3257

Comment 17

[Dão Gottwald [:dao]]

Happened to me again yesterday as well, but I'm not sure if I hovered the context menu item.

Comment 18

[u88484]

another one, which refers to different line number than the first error console thing I posted

trace: tabview assert: Must provide a function
switchToBeforeMode()@chrome://browser/content/tabview.js:7625
()@chrome://browser/content/tabview.js:7580
SearchEventHandlerClass()@chrome://browser/content/tabview.js:7553
@chrome://browser/content/tabview.js:7752

Comment 19

[Michael Yoshitaka Erlewine [:mitcho]]

I believe the assert console messages in comments 15 + 18 are being investigated (and fixed) in bug 595228. I believe they are unrelated to the problem at hand.

Comment 20

[Rain [:rain1] (inactive)]

I just reproduced this with Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b6pre) Gecko/20100912 Firefox/4.0b6pre. The tabs seemed to have escaped the group they were in, and so showed up as singletons. I could get all my tabs back through the Panorama interface (Ctrl+space).

Comment 21

[Raymond Lee [:raymondlee]]

I still couldn't find a way to reproduce this.  A reliable STR would be appreciated.

Comment 22

[(no longer active)]

I can reproduce it reliably by opening an instance of Firefox with only one tab open and doing the steps in comment 0.

Comment 23

[Raymond Lee [:raymondlee]]

(In reply to comment #22)
> I can reproduce it reliably by opening an instance of Firefox with only one tab
> open and doing the steps in comment 0.

I still can't reproduce it :(

Comment 24

[(no longer active)]

I think you should not have the tabview iframe initialized.

Have you tried using a clean profile?

Comment 25

[(no longer active)]

FWIW, commenting these lines out fixes the issue:

<http://mxr.mozilla.org/mozilla-central/source/browser/base/content/browser-tabview.js?mark=149-165#141>

Comment 26

[Michael Yoshitaka Erlewine [:mitcho]]

Could we get a screencast of someone reproducing this? Perhaps we're missing something crucial... :/

Comment 27

[Raymond Lee [:raymondlee]]

(In reply to comment #24)
> I think you should not have the tabview iframe initialized.
>
The reason the iframe gets initialised is that we want to populate all the named group to the menu popup.

> Have you tried using a clean profile
Yes, but still couldn't reproduce it.

Comment 28

[(no longer active)]

When you open a new tab in the restored session and then init the iframe through the context menu, GroupItems.newTab is called on the newly opened tab item, but both activeGroupItem and orphanTab variables are null, so positionNewTabAtBottom is called: <http://mxr.mozilla.org/mozilla-central/source/browser/base/content/tabview/groupitems.js#1731>

This doesn't seem right to me.  It appears to me that we need to add this tab to the group item of its siblings.

Comment 29

[(no longer active)]

This screen cast shows how I reproduce the bug.  I have just opened Firefox with the home page tab restored from the previous session.

<http://people.mozilla.org/~eakhgari/587990.mov>

Comment 30

[Raymond Lee [:raymondlee]]

Attachment: v1

The test is named _browser_tabview_bug587990.js so it's the first Panorama test get called first in order for it to run properly.  Filed the follow-up two bug 595806 and bug 595808 to fix that.

Pushed the try server and waiting for the results.

Comment 31

[Raymond Lee [:raymondlee]]

Attachment: v1

Comment 32

[Mike Beltzner [:beltzner, not reading bugmail]]

Resummarizing as many people are calling the tabs left hanging in general panorama space as "orphans"

Comment 33

[Raymond Lee [:raymondlee]]

Passed try

Comment 34

[Ian Gilman [:iangilman]]

Comment on attachment 474662 [details] [diff] [review]
v1

Looks good, though I can image there might be situations that this fix wouldn't catch (since it only works with reconnection/adding), but maybe I'm just paranoid. At any rate, I've proposed bug 595893 as a follow up for this and other issues.

Comment 35

[(no longer active)]

The patch seems good to me, both in terms of the code && test, and in the sense that it indeed fixes all the manifestations of this problem.

Comment 36

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #30)
> The test is named _browser_tabview_bug587990.js so it's the first Panorama test

Huh, I didn't think this would work. Apparently I forgot a "^" at http://hg.mozilla.org/mozilla-central/annotate/c8f0c42cfa44/testing/mochitest/browser-harness.xul#l222 .

Comment 37

[Dietrich Ayala (:dietrich)]

Comment on attachment 474662 [details] [diff] [review]
v1

>diff --git a/browser/base/content/tabview/groupitems.js b/browser/base/content/tabview/groupitems.js
>--- a/browser/base/content/tabview/groupitems.js
>+++ b/browser/base/content/tabview/groupitems.js
>@@ -785,17 +785,18 @@ GroupItem.prototype = Utils.extend(new I

>-        if (item.tab == gBrowser.selectedTab)
>+        if (item.tab == gBrowser.selectedTab || 
>+            (!GroupItems.getActiveGroupItem() && !item.tab.hidden))
>           GroupItems.setActiveGroupItem(this);

can you summarize with a comment

>diff --git a/browser/base/content/tabview/tabitems.js b/browser/base/content/tabview/tabitems.js
>--- a/browser/base/content/tabview/tabitems.js
>+++ b/browser/base/content/tabview/tabitems.js
>@@ -988,17 +988,18 @@ let TabItems = {

>-            if (item.tab == gBrowser.selectedTab)
>+            if (item.tab == gBrowser.selectedTab || 
>+                (!GroupItems.getActiveGroupItem() && !item.tab.hidden))
>               GroupItems.setActiveGroupItem(item.parent);

same code from above. if there's a way to make it DRY easily, please do so.

>+      let event = document.createEvent("Events");
>+      event.initEvent("tabviewframeinitialized", true, false);
>+      dispatchEvent(event);

document this event please.

r=me with these fixed.

Comment 38

[Raymond Lee [:raymondlee]]

Attachment: v2

I've re-written the test to open a new window and run the test.  Pushed to try and waiting for the results.

Comment 39

[Ian Gilman [:iangilman]]

Comment on attachment 474748 [details] [diff] [review]
v2

Looks good. Don't forget to address dietrich's comments (adding comments).

Comment 40

[Ian Gilman [:iangilman]]

Looks like we've got an orange in linux on the try server: 

TEST-UNEXPECTED-FAIL | chrome://mochikit/content/browser/browser/components/privatebrowsing/test/browser/browser_privatebrowsing_protocolhandler.js | application timed out after 330 seconds with no output

Ehsan doesn't think it's an intermittent. Here's the test:

http://mxr.mozilla.org/mozilla-central/source/browser/components/privatebrowsing/test/browser/browser_privatebrowsing_protocolhandler.js

Here's the log for Linux 64 opt:

http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTry/1284413980.1284415149.21825.gz

... and here's the log for Linux opt:

http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTry/1284418237.1284419409.8996.gz

Comment 41

[Raymond Lee [:raymondlee]]

Attachment: wip

* Added comments
* Modified the test.

Pushed to the try and waiting for the results

Comment 42

[Raymond Lee [:raymondlee]]

Attachment: v3

Comment 43

[Raymond Lee [:raymondlee]]

Comment on attachment 475108 [details] [diff] [review]
v3

Win2003 debug has an orange (mochitest 3) so I've push another one for Win32 to try again

Comment 44

[Ian Gilman [:iangilman]]

Comment on attachment 475108 [details] [diff] [review]
v3

I assume the key change here is the setTimeout at the bottom? Is there a more reliable way to know the window's gone?

Comment 45

[(no longer active)]

Comment on attachment 475108 [details] [diff] [review]
v3

(In reply to comment #44)
> I assume the key change here is the setTimeout at the bottom? Is there a more
> reliable way to know the window's gone?

Yes!  In fact, that timeout does not guarantee that the window is really closed, and will just open us up to intermittent oranges depending on timing issues.

The correct way to do this would be to use the domwindowclosed notification.  You can find many samples of its use in tests throughout the tree.

Comment 46

[Ian Gilman [:iangilman]]

The try builds are inconclusive, but at any rate, I'd like to see Ehsan's comment addressed.

Comment 47

[Ian Gilman [:iangilman]]

Perhaps use the same sort of window close observation Sean just now used in the test for bug 595236?

Comment 48

[Sean Dunn]

Attachment: v4

I added my whenWindowObservesOnce() fu.

Comment 49

[Ian Gilman [:iangilman]]

Comment on attachment 475348 [details] [diff] [review]
v4

Try looks clean. Dietrich: you have this an r+ for version 1, but probably worth getting another for version 4?

Comment 50

[Aza Raskin [:aza]]

Comment on attachment 475348 [details] [diff] [review]
v4

Given that we've already had an r+ and we've only changed tests, I believe protocol is that we do not need another r+. I think we are good for landing given that this is a blocker.

Comment 51

[Ian Gilman [:iangilman]]

Attachment: patch for check-in [r=dietrich, a=blocking]

Comment 52

[Ed Lee :Mardak]

Comment on attachment 475711 [details] [diff] [review]
patch for check-in [r=dietrich, a=blocking]

>+function whenWindowObservesOnce(win, topic, func) {
>+    let windowWatcher = Components.classes["@mozilla.org/embedcomp/window-watcher;1"]
>+      .getService(Components.interfaces.nsIWindowWatcher);
>+    let origWin = win;
>+    let origTopic = topic;
>+    let origFunc = func;        
>+    function windowObserver(aSubject, aTopic, aData) {
>+      let theWin = aSubject.QueryInterface(Ci.nsIDOMWindow);
>+      if (origWin && theWin != origWin)
>+        return;
>+      if(aTopic == origTopic) {
>+          windowWatcher.unregisterNotification(windowObserver);
>+          origFunc.apply(this, []);
>+      }
>+    }
>+    windowWatcher.registerNotification(windowObserver);
>+}
All the orig* variables aren't necessary and some other cleanups:

function whenWindowObservesOnce(win, top, fun) {
  Services.ww.registerNotification(function(subject, topic) {
    if (sub.QueryInterface(Ci.nsIDOMWindow) == win) && topic == top) {
      Services.ww.unregisterNotification(arguments.callee);
      fun();
    }
  });
}

perhaps with some variable name changes (untested! :P)

Comment 53

[Ed Lee :Mardak]

Not sure if the QI is necessary either.. ?

Comment 54

[Justin Dolske [:Dolske]]

Pushed http://hg.mozilla.org/mozilla-central/rev/7276e29fbe04

Comment 55

[Tracy Walker [:tracy]]

I'll verify if I stop seeing this randomly happening.

Comment 56

[Rain [:rain1] (inactive)]

With the September 17 nightly, I don't see this every time I restart the browser, but I still see it once in, say, 5 times. I haven't been able to pin down what's different those times, though.

Comment 57

[u88484]

(In reply to comment #56)
> With the September 17 nightly, I don't see this every time I restart the
> browser, but I still see it once in, say, 5 times. I haven't been able to pin
> down what's different those times, though.

bug 589665?  Either way, it is a separate bug.  I think I expierence the same thing you are describing and it sucks because I kept thinking bug 589665 was it but reading through it it isn't the same bug I need to file.

Comment 58

[u88484]

Was going to mark this verified but as I was checking one more time, the bug happened :(  Reopening.

Comment 59

[Raymond Lee [:raymondlee]]

(In reply to comment #58)
> Was going to mark this verified but as I was checking one more time, the bug
> happened :(  Reopening.

I couldn't reproduce this.  Do you have the exact STR?

Comment 60

[eyal gruss]

STR:
1. have only two tabs open
2. pin one of the tabs
3. close the app tab via tab context menu with hovering over "Move This Tab To..." menu item
4. tabcandy opens with the remaining tab as orphan

Mozilla/5.0 (Windows NT 5.1; rv:2.0b7pre) Gecko/20100919 Firefox/4.0b7pre

Comment 61

[Ian Gilman [:iangilman]]

Raymond, maybe you should do bug 595893 sooner than later; it's sure to improve this situation.

Comment 62

[Ian Gilman [:iangilman]]

Comment on attachment 475711 [details] [diff] [review]
patch for check-in [r=dietrich, a=blocking]

Marking this patch as obsolete; it's already landed. The bug has been reopened because the symptoms persist; we need a new patch.

Comment 63

[Ed Lee :Mardak]

Probably should open a new bug if the orphan tabs only appear under new conditions unless this bug was never fixed at all in the first place.

Comment 64

[Johnathan Nightingale [:johnath]]

Can we get some clarification, here? If this should still block beta7 (i.e. if it's still just as broken) then an ETA on updated fix would be helpful.

Comment 65

[Aza Raskin [:aza]]

We can probably move this to now block beta8. We've committed a patch, but it appears that it solved the most common case of data loss, but not all.

Raymond, do you have any thoughts on when we can get a fix here?

Comment 66

[Raymond Lee [:raymondlee]]

(In reply to comment #60)
> STR:
> 1. have only two tabs open
> 2. pin one of the tabs
> 3. close the app tab via tab context menu with hovering over "Move This Tab
> To..." menu item
> 4. tabcandy opens with the remaining tab as orphan
> 
> Mozilla/5.0 (Windows NT 5.1; rv:2.0b7pre) Gecko/20100919 Firefox/4.0b7pre

The situation  should no longer exist after bug 594176 is landed.

Is it the only STR to reproduce the problem?

Comment 67

[Mike Beltzner [:beltzner, not reading bugmail]]

dria experienced this bug again recently, not using the STR from comment 68 - would her sessionstore.js file help?

Comment 68

[Mike Beltzner [:beltzner, not reading bugmail]]

Attachment: sessionstore.js file experiencing the problem

The three singleton tabs in this sessionstore.js are orphans. Not sure what I did to make them, but I *believe* that all of those tabs were things that were opened from external applications (IM or email, specifically)

Comment 69

[Raymond Lee [:raymondlee]]

(In reply to comment #68)
> Created attachment 480657 [details]
> sessionstore.js file experiencing the problem
> 
> The three singleton tabs in this sessionstore.js are orphans. Not sure what I
> did to make them, but I *believe* that all of those tabs were things that were
> opened from external applications (IM or email, specifically)

Bug 595893 should solve this.

Comment 70

[Ian Gilman [:iangilman]]

bug 595893 has landed ... do we feel this bug is fixed by it?

Comment 71

[Raymond Lee [:raymondlee]]

Reopen this bug if necessary

Comment 72

[eyal gruss]

just got it with Mozilla/5.0 (Windows NT 5.1; rv:2.0b8pre) Gecko/20101011 Firefox/4.0b8pre

Comment 73

[Raymond Lee [:raymondlee]]

(In reply to comment #72)
> just got it with Mozilla/5.0 (Windows NT 5.1; rv:2.0b8pre) Gecko/20101011
> Firefox/4.0b8pre

Could you provide the steps to reproduce please?

Comment 74

[Thomas Stache]

Attachment: Orphan tabs in top-left corner after initial tabview opening

I also just hit "this". I had a lot of tabs open the whole day, never visiting Tab View. When I did only "old" tabs where grouped in the "Main" group. Today's tabs, most (all?) opened "diverted" from my external Twitter/feed reader apps, where stuffed as small as they get into the top-left corner. Never seen this before...

[Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101012 Firefox/4.0b8pre]

Comment 75

[Thomas Stache]

(In reply to comment #74)
> I also just hit "this". I had a lot of tabs open the whole day, never visiting
> Tab View. When I did - only "old" tabs where grouped in the "Main" group. Today's
> tabs, most (all?) opened "diverted" from my external Twitter/feed reader apps,
> where stuffed as small as they get into the top-left corner.

Speaking of which... I have changed the pref
  browser.tabs.loadDivertedInBackground
to true, maybe someone could check the code if that could contribute.

Comment 76

[Ian Gilman [:iangilman]]

(In reply to comment #74)
> Created attachment 482558 [details]
> Orphan tabs in top-left corner after initial tabview opening
> 
> I also just hit "this". I had a lot of tabs open the whole day, never visiting
> Tab View. When I did only "old" tabs where grouped in the "Main" group. Today's
> tabs, most (all?) opened "diverted" from my external Twitter/feed reader apps,
> where stuffed as small as they get into the top-left corner. Never seen this
> before...
> 
> [Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101012
> Firefox/4.0b8pre]

Sounds like bug 598600

Comment 77

[Thomas Stache]

(In reply to comment #76)
> Sounds like bug 598600

Hmmm, but that was filed before the fix for bug 595893, which my build should have had. Did it not fix every case of "New tabs should never be orphans"?

Comment 78

[Ian Gilman [:iangilman]]

(In reply to comment #77)
> Hmmm, but that was filed before the fix for bug 595893, which my build should
> have had. Did it not fix every case of "New tabs should never be orphans"?

Yup... bug 598600 is a loophole that bug 595893 didn't catch.

Comment 79

[Deb Richardson [:dria] (plz NEEDINFO)]

Attachment: continued panorama brokenness

Comment 80

[Deb Richardson [:dria] (plz NEEDINFO)]

I've just run into this again on the latest nightly, with some tabs orphaned, tiny, and stuffed up into the upper left corner. (See attachment in #79).  Added bonus is that when I click on one of the orphaned tabs and then go back to Panorama, it goes all long and skinny in Panorama view.

Comment 81

[Daniel Holbert [:dholbert]]

Same here.  I just entered Panorama for the first time in a while to see if I could confirm 603734 for stechz, and I got a big empty tab group, with all my tabs outside of it as tiny orphaned nodes in the upper-left corner.

Comment 82

[Daniel Holbert [:dholbert]]

AFAICT, the "tiny" orphaned tabs (e.g. the upper-left one in deb's attachment 483087 [details] -- showing just the favicon --  aren't technically orphaned, but in fact are single-tab tab-groups, which have been initialized to start out at a very tiny size.  (as distinguished from "true" orphaned tabs, which are rectangles that show the tab's contents)

I discovered this when I tried to draw a new tab-group over them to "capture" them -- that lets you aggregate "true" orphans into a single group, but it didn't work for the tiny ones. (since they were already in singleton groups)

Comment 83

[Chris AtLee [:catlee]]

This happens often to me after session restore.

Comment 84

[Thomas Stache]

(In reply to comment #79, comment #81, comment #83)
:dria, :dholbert, :catlee, were your experiences related to the "Move to group" tab context menu item, as indicated in this bug's description? My comments in (comment #74, comment #75) were not...

Either the description needs changing, or we should take the discussion elsewhere.

Comment 85

[Deb Richardson [:dria] (plz NEEDINFO)]

Oh yeah, no the "move to group" part is entirely unrelated.  Is there another bug where I should be adding stuff instead?

Comment 86

[Daniel Holbert [:dholbert]]

(me too - I'd (mis)interpreted this as a general bug for "tab candy orphans tabs". Sorry for the bugspam.)

Comment 87

[Chris AtLee [:catlee]]

ditto

Comment 88

[Tracy Walker [:tracy]]

bug 587368 is about Session Store and TC. Returning this one to fixed.

Comment 89

[Tracy Walker [:tracy]]

hover over Move to group no longer causes tab disappearance.

Comment 90

[eyal gruss]

just hit it with Mozilla/5.0 (Windows NT 5.1; rv:2.0b8pre) Gecko/20101015 Firefox/4.0b8pre, non session-restore related.

Comment 91

[Mike Beltzner [:beltzner, not reading bugmail]]

(In reply to comment #90)
> just hit it with Mozilla/5.0 (Windows NT 5.1; rv:2.0b8pre) Gecko/20101015
> Firefox/4.0b8pre, non session-restore related.

But is it after hovering over move to group?

Comment 92

[eyal gruss]

it is always after clicking close or undo closed in the tab context menu, so it entails the mouse pointer passing over "move to group".

Comment 93

[Tracy Walker [:tracy]]

(In reply to comment #90)
> just hit it with Mozilla/5.0 (Windows NT 5.1; rv:2.0b8pre) Gecko/20101015
> Firefox/4.0b8pre, non session-restore related.

I can not reproduce this with the same build in a clean profile.  The bug "as reported" is fixed.

Also, clicking close or undo close does not cause any unwanted tab disappearance for me. If that's when a bug is triggered for you, then it is a different bug than this.  Please file a new bug.

This bug got dog piled on. Comments about switching tabs or restarting are also different bugs.

Comment 94

[Ian Gilman [:iangilman]]

All of the recent comments on this bug sound like bug 598600 to me.