Closed Bug 587990 Opened 9 years ago Closed 9 years ago

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

Categories

(Firefox Graveyard :: Panorama, defect, P1, major)

Tracking

(blocking2.0 betaN+)

VERIFIED FIXED
Firefox 4.0b7
Tracking Status
blocking2.0 --- betaN+

People

(Reporter: dao, Assigned: raymondlee)

References

Details

(Keywords: dataloss, regression)

Attachments

(3 files, 7 obsolete files)

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
blocking2.0: --- → ?
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)
Confirmed.  Switching tabs instead of opening a new one sometimes causes this.  Seems to only happen once per session though.
This is really annoying and a major usability issue -- requires me to restart the browser
Keywords: dataloss
Keywords: regression
blocking2.0: ? → beta5+
Assignee: nobody → raymond
(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.
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.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
(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.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Kurt: can we get the build ID of the version you repro'd on and the OS?
(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.
No longer blocks: 586788
Duplicate of this bug: 591829
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?
blocking2.0: beta5+ → beta6+
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?
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.
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
Status: REOPENED → RESOLVED
Closed: 9 years ago9 years ago
Resolution: --- → WORKSFORME
I can still reproduce with today's nightly.  I don't use PB mode.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
(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
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
Blocks: 594094
Happened to me again yesterday as well, but I'm not sure if I hovered the context menu item.
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
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.
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).
I still couldn't find a way to reproduce this.  A reliable STR would be appreciated.
I can reproduce it reliably by opening an instance of Firefox with only one tab open and doing the steps in comment 0.
(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 :(
I think you should not have the tabview iframe initialized.

Have you tried using a clean profile?
Could we get a screencast of someone reproducing this? Perhaps we're missing something crucial... :/
(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.
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.
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>
Blocks: 595808
Attached patch v1 (obsolete) — Splinter Review
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.
Attachment #474661 - Flags: feedback?(ian)
Attached patch v1 (obsolete) — Splinter Review
Attachment #474661 - Attachment is obsolete: true
Attachment #474662 - Flags: feedback?(ian)
Attachment #474661 - Flags: feedback?(ian)
Attachment #474662 - Attachment is patch: true
Attachment #474662 - Attachment mime type: application/octet-stream → text/plain
Resummarizing as many people are calling the tabs left hanging in general panorama space as "orphans"
Summary: TabCandy arbitrarily creates new groups → TabCandy arbitrarily creates new groups / orphans tabs in empty space
Passed try
Summary: TabCandy arbitrarily creates new groups / orphans tabs in empty space → TabCandy arbitrarily creates new groups / orphans tabs in empty space after hovering over "Move This Tab To..." menu item
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.
Attachment #474662 - Flags: review?(dietrich)
Attachment #474662 - Flags: feedback?(ian)
Attachment #474662 - Flags: feedback+
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.
(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 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.
Attachment #474662 - Flags: review?(dietrich) → review+
Attached patch v2 (obsolete) — Splinter Review
I've re-written the test to open a new window and run the test.  Pushed to try and waiting for the results.
Attachment #474662 - Attachment is obsolete: true
Attachment #474748 - Flags: feedback?(ian)
Attachment #474748 - Attachment is patch: true
Attachment #474748 - Attachment mime type: application/octet-stream → text/plain
Comment on attachment 474748 [details] [diff] [review]
v2

Looks good. Don't forget to address dietrich's comments (adding comments).
Attachment #474748 - Flags: feedback?(ian) → feedback+
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
Attached patch wip (obsolete) — Splinter Review
* Added comments
* Modified the test.

Pushed to the try and waiting for the results
Attachment #474748 - Attachment is obsolete: true
Attached patch v3 (obsolete) — Splinter Review
Attachment #474992 - Attachment is obsolete: true
Attachment #475108 - Flags: feedback?(ian)
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 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 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.
Attachment #475108 - Flags: feedback?(ian) → feedback-
Blocks: 588846
The try builds are inconclusive, but at any rate, I'd like to see Ehsan's comment addressed.
Perhaps use the same sort of window close observation Sean just now used in the test for bug 595236?
Attached patch v4 (obsolete) — Splinter Review
I added my whenWindowObservesOnce() fu.
Attachment #475108 - Attachment is obsolete: true
Attachment #475348 - Flags: feedback?(ehsan)
Attachment #475348 - Flags: feedback?(ehsan) → feedback+
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?
Attachment #475348 - Flags: review?(dietrich)
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.
Attachment #475348 - Flags: review?(dietrich)
Attachment #475348 - Attachment is obsolete: true
Blocks: 588712
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)
Not sure if the QI is necessary either.. ?
Pushed http://hg.mozilla.org/mozilla-central/rev/7276e29fbe04
Status: REOPENED → RESOLVED
Closed: 9 years ago9 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 4.0b7
Keywords: checkin-needed
I'll verify if I stop seeing this randomly happening.
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.
(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.
Was going to mark this verified but as I was checking one more time, the bug happened :(  Reopening.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Blocks: 597043
(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?
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
Summary: TabCandy arbitrarily creates new groups / orphans tabs in empty space after hovering over "Move This Tab To..." menu item → TabCandy arbitrarily creates new groups / orphans tabs in empty space after hovering over "Move to Group..." menu item
Raymond, maybe you should do bug 595893 sooner than later; it's sure to improve this situation.
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.
Attachment #475711 - Attachment is obsolete: true
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.
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.
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?
(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?
blocking2.0: beta7+ → betaN+
Priority: -- → P1
Depends on: 595893
dria experienced this bug again recently, not using the STR from comment 68 - would her sessionstore.js file help?
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)
(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.
bug 595893 has landed ... do we feel this bug is fixed by it?
Reopen this bug if necessary
Status: REOPENED → RESOLVED
Closed: 9 years ago9 years ago
Resolution: --- → FIXED
just got it with Mozilla/5.0 (Windows NT 5.1; rv:2.0b8pre) Gecko/20101011 Firefox/4.0b8pre
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(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?
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]
(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.
(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
(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"?
(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.
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.
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.
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)
This happens often to me after session restore.
(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.
Oh yeah, no the "move to group" part is entirely unrelated.  Is there another bug where I should be adding stuff instead?
(me too - I'd (mis)interpreted this as a general bug for "tab candy orphans tabs". Sorry for the bugspam.)
ditto
bug 587368 is about Session Store and TC. Returning this one to fixed.
Status: REOPENED → RESOLVED
Closed: 9 years ago9 years ago
Resolution: --- → FIXED
hover over Move to group no longer causes tab disappearance.
Status: RESOLVED → VERIFIED
just hit it with Mozilla/5.0 (Windows NT 5.1; rv:2.0b8pre) Gecko/20101015 Firefox/4.0b8pre, non session-restore related.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
(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?
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".
(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.
Status: REOPENED → RESOLVED
Closed: 9 years ago9 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
All of the recent comments on this bug sound like bug 598600 to me.
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.