912975 - Windows and tabs are not always restored after Reseting Firefox

Status: RESOLVED WORKSFORME

(Firefox :: Session Restore, defect)

Description

[Simona Badau, Desktop QA]

Mozilla/5.0 (Windows NT 6.1; rv:26.0) Gecko/20100101 Firefox/26.0
Build ID: 20130904030204

Windows and tabs are not reset all the time after a Firefox reset. I managed to reproduce the issue several times, some times when resetting Firefox having several tabs and windows opened (in the first window - 2 pinned tabs, 2 normal tabs; in the second window with one tab opened) but in most of the cases I reproduced the issue when resetting having one Firefox window opened with one pinned tab and a normal one. 

Moreover if I click on the Restore button from the Welcome Back! page, Firefox will be closed without being automatically opened afterwards.

Reproducible: intermittent 

Steps to reproduce: 
1. Launch Firefox having one pinned tab and one normal tab (in a single window)
2. Go to the about:support page and chose to Reset Firefox
3. Wait for Firefox to be opened and in the Welcome Back! page, click on the Reset button.
4. Repeat steps 1-3 until the windows and tabs list in the Welcome Back page is empty.

Expected results:
The tabs opened in step 1 are present in the windows and tabs list each time. Clicking on the Reset button opens the windows and tabs from the Welcome Back! dialog.

Actual results:
The tabs are not reset and Firefox is closed when clicking on the Reset button.
Please see the screencast: http://screencast.com/t/enlfZidguF

Notes:
The issue is reproducible on Windows, Ubuntu 13.04 and Mac OS X.
The issue is reproducible on the latest Nightly 26.0a1 and on the latest Aurora 25.0a2.

Comment 1

[Petruta Horea [:phorea], Desktop QA]

Reproduced on Firefox 25 beta 1 (20130917123208) on Win XP 32-bit, Win 8.1 64-bit and Ubuntu 13.04 64-bit  by resetting Firefox from Reset Notification bar. 
The opened and pinned tabs are not displayed. On the about:sessionrestore page, clicking Restore will close Firefox session.

Comment 2

[u279076]

Is this reproducible in any version of Firefox previous to 25?

Comment 3

[Simona Badau, Desktop QA]

(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #2)
> Is this reproducible in any version of Firefox previous to 25?

No, this is not reproducible on the versions prior Firefox 25. The option to reset Windows and Tabs was added in Bug 833943 which landed in Firefox 25.

Comment 4

[u279076]

Nominating this for tracking given it's a regression tied to implementing Window/Tab Reset (bug 833943).

Comment 5

[Lukas Blakk [:lsblakk] use ?needinfo]

Gijs - does this block the shipping of the feature or can it be a follow up fix in 26? We're closing in on our last week of Beta so only critical fixes should be landing - please let us know if this intermittent issue would put the whole feature ship at risk.

Comment 6

[:Gijs (he/him)]

AFAICT this is an issue in session restore. The screencast shows that the reset code is convinced it's happily copied the session data into the new profile, which presumably means the new session data either wasn't written completely in the old profile yet after having been modified (by closing a tab), or is corrupted for some other reason. I don't know how likely this case is in practice: the screencast shows the user resetting Firefox several times in a row; you wouldn't normally bother resetting more than once (it's not going to add any value, or "reset better"). I don't know if/how this is more generally reproducible, and/or if anything could be done (in particular, is there something we could/should do to inform session restore that we're about to reset).

The fact that the restore button closes Firefox completely (which is the only regression here, as the user always lost all their tabs previous to the feature having been implemented) is definitely a session restore bug. We may be able to fix that in a relatively precise/limited way within session restore, but I'd have to defer to Tim. I'd imagine we could sanity check the form data we're restoring to contain at least one window, or something.

Tim, could you help me out here in terms of assessing the severity of the issue and the possibility of fixing?

Comment 7

[Matthew N. [:MattN]]

Driveby comment which may be totally wrong: Perhaps we need something like attachment 812511 [details] [diff] [review]? Is quit-application-requested getting fired for the reset?

Comment 8

[Alex Keybl [:akeybl]]

(In reply to :Gijs Kruitbosch from comment #6)
> Tim, could you help me out here in terms of assessing the severity of the
> issue and the possibility of fixing?

This info would be great, since it feels like an edge case (especially step 4).

Comment 9

[Tim Taubert [:ttaubert] (inactive)]

(In reply to Matthew N. [:MattN] from comment #7)
> Driveby comment which may be totally wrong: Perhaps we need something like
> attachment 812511 [details] [diff] [review]? Is quit-application-requested
> getting fired for the reset?

You're absolutely right:

http://mxr.mozilla.org/mozilla-central/source/toolkit/modules/ResetProfile.jsm#82

We should send quit-application-requested here and check the result before shutting down. That's the same as bug 919532 which means this issue should be fixed in Fx 25+.

Can someone please verify that this is fixed now?

Also, it would be good to file a follow-up bug to fire quit-application-requested.

Comment 10

[:Gijs (he/him)]

(In reply to Tim Taubert [:ttaubert] (limited availability, work week) from comment #9)
> (In reply to Matthew N. [:MattN] from comment #7)
> > Driveby comment which may be totally wrong: Perhaps we need something like
> > attachment 812511 [details] [diff] [review]? Is quit-application-requested
> > getting fired for the reset?
> 
> You're absolutely right:
> 
> http://mxr.mozilla.org/mozilla-central/source/toolkit/modules/ResetProfile.
> jsm#82
> 
> We should send quit-application-requested here and check the result before
> shutting down. That's the same as bug 919532 which means this issue should
> be fixed in Fx 25+.
> 
> Can someone please verify that this is fixed now?
> 
> Also, it would be good to file a follow-up bug to fire
> quit-application-requested.

Filed followup bug 927393 and bug 927395.

Simona or Anthony, can you still reproduce on 25b8 builds?

Comment 11

[Simona Badau, Desktop QA]

I can't reproduce the issue as described in Comment 0 on the latest Firefox 25 beta 8 on Windows 7, Mac OS X 10.9 and Ubuntu 13.04- the tabs are always restored.

I did however encountered a strange behavior on my Ubuntu 13.04 32-bit machine. After restoring Firefox for about 7 times, Firefox is not restarted and that last profile that was supposed to be backed out in the Old Firefox Data file is not placed there. Resetting Firefox from that point on will not generate a new profile anymore.

Steps to reproduce:
1. Open Firefox with a new profile 
2. Open several tabs (pin some of them)
3. Go to the about:support page and choose to Reset Firefox
4. Repeat step 3 several times (7-8 times does the trick for me)

Expected results:
After resetting Firefox, the browser is restarted and the previous profile is backed out in the Old Firefox Data file.

Actual results:
Firefox is not restarted, no other profile is generated and the last profile that was generated is not existent in the Old Firefox Data file.

I could only reproduce the above issue on my Ubuntu 13.04 32-bit machine. Tried to reproduce it also on Windows 7, and Mac 10.9, but with no success. 
On a different Ubuntu 13.04 64-bit machine(with an AMD Radeon HD3000 video card) - the issue is NOT reproducible but on Ubuntu 12.04 32-bit with an AMD Radeon HD 6450 video card, the issue is reproducible. The machine I initially found the issue is also equipped with an ATI Radeon HD 5450 video card.
On Firefox 25 beta 7 I can't reproduce this issue.

Any thoughts?

Comment 12

[:Gijs (he/him)]

(In reply to Simona B [QA] from comment #11)
> I can't reproduce the issue as described in Comment 0 on the latest Firefox
> 25 beta 8 on Windows 7, Mac OS X 10.9 and Ubuntu 13.04- the tabs are always
> restored.
> 
> I did however encountered a strange behavior on my Ubuntu 13.04 32-bit
> machine. After restoring Firefox for about 7 times, Firefox is not restarted
> and that last profile that was supposed to be backed out in the Old Firefox
> Data file is not placed there. Resetting Firefox from that point on will not
> generate a new profile anymore.
> 
> Steps to reproduce:
> 1. Open Firefox with a new profile 
> 2. Open several tabs (pin some of them)
> 3. Go to the about:support page and choose to Reset Firefox
> 4. Repeat step 3 several times (7-8 times does the trick for me)
> 
> Expected results:
> After resetting Firefox, the browser is restarted and the previous profile
> is backed out in the Old Firefox Data file.
> 
> Actual results:
> Firefox is not restarted, no other profile is generated and the last profile
> that was generated is not existent in the Old Firefox Data file.
> 
> I could only reproduce the above issue on my Ubuntu 13.04 32-bit machine.
> Tried to reproduce it also on Windows 7, and Mac 10.9, but with no success. 
> On a different Ubuntu 13.04 64-bit machine(with an AMD Radeon HD3000 video
> card) - the issue is NOT reproducible but on Ubuntu 12.04 32-bit with an AMD
> Radeon HD 6450 video card, the issue is reproducible. The machine I
> initially found the issue is also equipped with an ATI Radeon HD 5450 video
> card.
> On Firefox 25 beta 7 I can't reproduce this issue.
> 
> Any thoughts?

Sounds like a startup or exit crash that's specific to certain configurations. Nothing relevant in about:crashes when you open Firefox with the old profile? (I'm assuming that if you manually re-open Firefox, it starts up in the profile you had?)

Comment 13

[Simona Badau, Desktop QA]

(In reply to :Gijs Kruitbosch from comment #12)
> Sounds like a startup or exit crash that's specific to certain
> configurations. Nothing relevant in about:crashes when you open Firefox with
> the old profile? (I'm assuming that if you manually re-open Firefox, it
> starts up in the profile you had?)

There is no new entry in the about:crashes section when I open Firefox with the old profile (you're assumption is correct).

Comment 14

[Alex Keybl [:akeybl]]

Too late to fix in FF25 at this point, leaving nominated for 26 and up for triage to decide next steps.

Comment 15

[Lukas Blakk [:lsblakk] use ?needinfo]

I'm not convinced this is a widely hit issue but also don't want to mess with people's experience around reset feature, so tracking.

Comment 16

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

Is this already fixed in 26 and 27 by bug 919532's patch?

Comment 17

[:Gijs (he/him)]

(In reply to :Gavin Sharp (use [e-mail] for email) from comment #16)
> Is this already fixed in 26 and 27 by bug 919532's patch?

The issue in comment #0 is fixed in 25,26,27 by bug 919532's patch. The issue in comment #11 is undiagnosed, AFAIK.

Comment 18

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

This bug (and its tracking flags) can only be about one bug - which is it? :)

If comment 11 needs a separate bug filed, let's do that.

Comment 19

[:Gijs (he/him)]

(In reply to :Gavin Sharp (use [e-mail] for email) from comment #18)
> This bug (and its tracking flags) can only be about one bug - which is it? :)
> 
> If comment 11 needs a separate bug filed, let's do that.

A good point. Per the work in bug 919532, I've updated the status flags here, and am marking this WFM. I've filed bug 929450 about the issue in comment #11 and have updated the tracking flags there inasmuch as bugzilla lets me.

Comment 20

[Tracy Walker [:tracy]]

Simona, please verify this is WFM, if you can.

Comment 21

[Simona Badau, Desktop QA]

The Windows and tabs are restored with the latest Nightly 27.0a1 (Build ID: 20131025030239) across all platforms (Windows 7 64-bit, Ubuntu 12.04 and Mac OS X 10.8) and with Aurora 26.0a2 (Build ID: 20131025004002) on Windows 7 64-bit and Mac OS X 10.8 (on Ubuntu I filed Bug 931026).