User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b7) Gecko/20100101 Firefox/4.0b7 Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b7) Gecko/20100101 Firefox/4.0b7 When browser.sessionstore.max_concurrent_tabs is set to 0, dragging an unloaded (to-be-restored) tab into a different tab group shows the tab successfully moved into the new tab group although the change is not saved. Reproducible: Always Steps to Reproduce: 1. Set browser.sessionstore.max_concurrent_tabs to 0. 2. Restart the browser, restoring a previous session with multiple tabs. 3. Activate TabCandy view. 4. Drag an unloaded tab into a different tab group. 5. Restart the browser. Actual Results: The tab remains in the old tab group. Expected Results: The tab has been moved to the new tab group.
Filed the bug using the wrong browser. The bug is still in Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101119 Firefox/4.0b8pre
Is this indicative of a larger problem? Or does this only occur when you manually set browser.sessionstore.max_concurrent_tabs to 0?
Priority: -- → P2
The problem is that tab group changes are not saved for an unloaded tab. Even with a non-zero value for browser.sessionstore.max_concurrent_tabs there are still unloaded tabs while the session is still being restored (due to the new cascaded session restore).
Are you still seeing this in the latest build? I am using 4.0b10pre (2011-01-24) and it seems to work fine for me.
I've tried the STR today with latest trunk but couldn't reproduce it. Please re-open this bug if needed.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → WORKSFORME
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.