Closed Bug 1035205 Opened 8 years ago Closed 8 years ago

Reset Notification bar is not shown after 60 days of inactivity

Categories

(Firefox :: General, defect)

29 Branch
All
macOS
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX
Tracking Status
firefox31 - unaffected
firefox32 + unaffected
firefox33 + unaffected

People

(Reporter: phorea, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: regression)

Reproducible on:
Firefox 31 beta 7 - 20140703154127
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Firefox/31.0		
latest Aurora 32.0a2 - 20140707004006
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0		
latest Nightly 33.0a1 - 20140706030226
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0		

Steps to reproduce:
1. Set your computer clock to at least 61 days in the past
2. Open Firefox 31 beta 7 with a new profile
2'. Add the pref browser.disableResetPrompt and set it to false
3. Close Firefox
4. Change the system date to the current date
5. Re-open Firefox
or
Open Firefox with a profile abandoned for more than 2 months

Actual results:
The Reset Notification bar doesn't appear at the bottom of the page.
In browser console, the "ReferenceError: Services is not defined" message is shown when running Services.appinfo.replacedLockTime.

Expected results:
The Reset Notification bar is visible at the bottom of the page.

Notes: 1. The issue also reproduces under Ubuntu 13.04 64-bit and Mac OSX 10.9.3
2. I could reproduce the issue using a Firefox 26 release build
Depends on: 955950
Flags: firefox-backlog+
Keywords: regression
Thanks for filing.

(In reply to Petruta Rasa [QA] [:petruta] from comment #0)
> In browser console, the "ReferenceError: Services is not defined" message is
> shown when running Services.appinfo.replacedLockTime.

Are you sure this was the Browser Console and not the Web Console?
Flags: needinfo?(petruta.rasa)
Iteration: --- → 33.3
(In reply to Matthew N. [:MattN] (behind on bugmail) from comment #1)
> Are you sure this was the Browser Console and not the Web Console?

Sorry, I was using the Web Console. Please see the results using Win 7, 64-bit system.

In Browser Console, using an old profile I've got:
Services.appinfo.replacedLockTime
1404805471980

With a new profile when changing the system time (step2 form comment 0):
Services.appinfo.replacedLockTime
1404806530919

With a new profile when changing the system time and adding the pref (step2' from comment 0):
Services.appinfo.replacedLockTime
1404807029432
Flags: needinfo?(petruta.rasa)
Iteration: 33.3 → ---
Depends on: 1036187
Too late in the 31 beta cycle but we could take a fix for 32.
Points: --- → 3
QA Whiteboard: [qa+]
I just started looking at this (via bug 1036187), and a few things don't make sense yet.  I'll note them here as a kind of note to self.  I haven't been able to reproduce yet (because I didn't notice at first that profile resets are only offered for default profiles).

Relevant code is: http://mxr.mozilla.org/mozilla-central/source/browser/components/nsBrowserGlue.js#688

Setting browser.disableResetPrompt to false just means that the pref getter doesn't throw, but in either case, the disableResetPrompt var will be false, and the same path is taken [1].

(In reply to Petruta Rasa [QA] [:petruta] (Away 12-19 Aug) from comment #0)
> In browser console, the "ReferenceError: Services is not defined" message is
> shown when running Services.appinfo.replacedLockTime.

Services.appinfo.replacedLockTime is gotten before the pref is gotten, so if this line really is a problem, I can't see how it's due to the pref.  (Maybe this code has changed since 31b7, so I need to find the difference.)

Finally, why would the error show up in the web console and not the browser console?
(In reply to Drew Willcoxon :adw from comment #4)
> Finally, why would the error show up in the web console and not the browser
> console?

That's because the Web Console is unprivileged and runs in the scope of the page. Ignore the "Services is not defined" stuff as I'm pretty sure it's a red herring.
I don't think this bug is important enough to pursue in 32 at this point in the schedule.

Drew - Do you intend to get this prioritized into the current iteration to fix on Aurora 33?
Flags: needinfo?(adw)
Petruta, are you sure about your affected versions?  This is what I could reproduce (on OS X 10.9.4, but I doubt that matters):

    26  OK
    27  OK
    28  OK
    29  BAD
29.0.1  BAD
    30  BAD
    31  OK
  32b1  OK
  33a2  OK
  34a1  OK

OK means the bar appeared as expected, BAD means it didn't.  In all cases, the pref in comment 0 didn't matter, and I didn't see any related errors or warnings, so I think those things aren't relevant.  I don't know why Petruta's and my affected versions differ so much.

On 29, the problem is that BrowserGlue.prototype._resetUnusedProfileNotification returns early here because getMostRecentBrowserWindow returns null: http://hg.mozilla.org/releases/mozilla-release/file/92738325aaf7/browser/components/nsBrowserGlue.js#l588

Which is because RecentWindow.getMostRecentBrowserWindow returns null here: http://hg.mozilla.org/releases/mozilla-release/file/92738325aaf7/browser/modules/RecentWindow.jsm#l66

I can continue debugging, but if 29 and 30 are really the only affected versions, I don't think it matters at this point?
Flags: needinfo?(adw) → needinfo?(petruta.rasa)
The notification bar also works for me with Windows 7 on Nightly (34) and Release (31) so this is probably WONTFIX unless Petruta can still reproduce.

Petruta, please make sure you keep in mind that Resets only work with the default profile (as mentioned in comment 4) when you're testing.
Hrm, was this a dupe of bug 924456?
Oh, no - that's Mac only. But maybe Windows had a similar issue also fixed by bug 974197?
Drew, Matt: I tested with new or old profiles (not used for more than 2 months) when logging this bug.

What were your steps to reproduce it using "default" profile, as I still don't see the notification bar with the steps from description? 
(I tried under Win 7 64-bit with "Default User" profile suggested by Firefox as I probably deleted long time ago the "default" one and under Ubuntu 13.04 32-bit where "default" was still available and not used since Aug 2013).
Flags: needinfo?(petruta.rasa)
To ensure the profiles I was testing with were default profiles, I did:

1. Start Firefox with -P
2. Create a new profile
3. Make sure the new profile is selected (in the "Choose User Profile" dialog)
4. Make sure "Use the selected profile without asking at startup" is checked
5. Click "Start Nightly"

So the entire series of steps I did was:

1. Set system clock back a year
2. Create a new default profile as described above and start Firefox
3. Quit Firefox
4. Correct the system clock
5. Start Firefox with the new profile again (by passing -P newProfileName)

I also tried reproducing by using the `touch` command to change the date of the .parentLock file in my profile (parent.lock in the roaming profile on Windows) instead of changing my system clock.
Thanks for the detailed steps, Drew!

Using Firefox -P newProfileName I could see the notification bar, but it didn't appear if opening from "Choose User Profile" dialog or using Firefox -P and selecting the new profile, so I believe this was by my fault, sorry.

I've tested using Firefox 32 beta 8, latest Aurora 33.0a2 and latest Nightly 34.0a1 under Win 7 64-bit and Ubuntu 13.04 32-bit.

The notification is hidden if the pref browser.disableResetPrompt is set to true and appears otherwise.

On those platform versions I could also see the bar using Firefox 29 and 30 RC.

Considering this, I think this bug can be closed and bug 955950 marked as verified. Agree?
(In reply to Petruta Rasa [QA] [:petruta] from comment #13)
> I've tested using Firefox 32 beta 8, latest Aurora 33.0a2 and latest Nightly
> 34.0a1 under Win 7 64-bit and Ubuntu 13.04 32-bit.
> 
> ...
> 
> On those platform versions I could also see the bar using Firefox 29 and 30
> RC.

That's interesting, maybe there is a difference on OS X.  I double checked my results from comment 7 on 29, 30, and 31 just now and was able to reproduce them.

> Considering this, I think this bug can be closed and bug 955950 marked as
> verified. Agree?

Agreed, thanks Petruta.  Since the bug does happen (for me) on OS X on 29 and 30, and we're not going to patch those versions at this point, I'll mark this as wontfix instead of WFM and change the platform to OS X.  I'll also close bug 1036187.
Status: NEW → RESOLVED
Closed: 8 years ago
OS: All → Mac OS X
Resolution: --- → WONTFIX
Version: Trunk → 29 Branch
Points: 3 → ---
QA Whiteboard: [qa+]
Flags: firefox-backlog+ → firefox-backlog-
You need to log in before you can comment on or make changes to this bug.