Created attachment 656463 [details] Screenshot-Slashdot: News for nerds, stuff that matters - Mozilla Firefox.png User Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:14.0) Gecko/20100101 Firefox/14.0.1 Build ID: 20120713230316 Steps to reproduce: Multiple windows each with multiple tabs were open. I closed the browser by clicking X, and opted to save tabs. Actual results: Firefox closed, saving three opened web pages (Slashdot, Google, Enter a Bug). When I reopened Firefox, all pages were saved from previous session however the first tab (Slashdot) is invisible. For instance, the tabs show (from left to right) | + | Google | Enter A Bug | If I control-tab through the open tabs there are actually three pages (the third is the invisible tab, ie, Slashdot). The third page (invisible tab) was correctly saved from my previous session, it just does not have a tab. Expected results: The browser should reopen with a tab corresponding to each page from the prior session. Additionally, the + tab (add new tab) should be placed at the end of the list of retrieved tabs, not at the beginning. Using the example above, the session should have been restored with: | Slashdot | Google | Enter A Bug | + |
I experienced this bug once with tabs that were closed just became "invisible" as you say. You could still ctrl-tab through them. That seems to have fixed itself at some point in nightly or a addon I disabled. Can you replicate this using safe mode?
Jesper, my system notified me of a new version of Firefox (15x) moments ago. I will install and retest.
Problem resolved in version 15.0.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → WORKSFORME
Great. Reopen if it reappears
Created attachment 665597 [details] Shows the condition of two windows after restart: one with 1 tab and 1 which had 2 tabs. Shows the condition of two windows after restart: one with 1 tab and one which had 2 tabs. Each is showing one less tab than before the restart occurred. Also to mention is that occasionally the "+" mini-tab (Ctrl+t) is often out of place (at the right, at the left, or in between tabs) which I believe is a related issue.
This bug is repeatable (and annoying)! It essentially makes tab-1 unselectable. And if you ever navigate to a different tab then tab-1 is in limbo just sitting there eating resources) for ever and ever until the window is closed. This is pretty major IMHO! Mac Pro Processor 2 x 2.66 GHz x5355 (total 8 cores) Memory 12 GB 667 MHz DDR2 FB-DIMM Graphics NVIDIA GeForce 7300 GT 256 MB Software Mac OS X Server Lion 10.7.5 (11G56) Firefox 15.0.1
I guess this bug needs to be reopened? Or is it in transit and will appear in the next compile?
Reopening -- confirmed in latest build.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
I've seen this happen from time to time. I wasn't doing anything else so I took a look at it in the devtools. I found that the invisible tab had a width of 0.1px while the others had normal sizes. The others also had a min-width, while the invisible one did not. Turns out that the min-width comes from a style rule that only applies when the tab has a "fadein" attribute set. This attribute is used to trigger the animation of the tab growing to full size. Since this particular tab didn't have that attribute set on it, the animation was never triggered and the size stayed at 0.1px. I don't have any theories to explain why the attribute wasn't set. Setting the pref browser.tabs.animate to false might mitigate this, though because it's rare I've no way to prove it.
Status: UNCONFIRMED → NEW
Ever confirmed: true
You need to log in before you can comment on or make changes to this bug.