940140 - "It looks like you haven't used Firefox in a while..." due to interaction between replacedLockTime and a profile shared between OSs

Status: UNCONFIRMED

(Toolkit :: Startup and Profile System, defect)

Description

[vincent]

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:25.0) Gecko/20100101 Firefox/25.0 (Beta/Release)
Build ID: 20131025151332

Steps to reproduce:

I get the message "It looks like you haven't used Firefox in a while, blablabla", even though I am using Firefox exclusively, every day, every time I launch Firefox (version 25.0.1) on Mac OS X 10.7.5.


Actual results:

Message is displayed, suggesting I should reset my settings.


Expected results:

No message should appear.

Comment 1

[vincent]

Copied from my entries in bug 896276, which is not the same as this one:

Hi, sorry to barge in, but that bug is back, at least for me. It happens every single time I launch Firefox 25.0 or 25.0.1 on my MacBook. I believe the problem started with version 25.0, but I am not entirely sure. I have 3 partitions on my MacBook, NTFS and Mac OS for the OSes (Mac OS X 10.7.5 and Windows 7 Pro, 32 bit edition), and a FAT32 partition to share data between the OSes, including my Mozilla profiles. I have some odd issues like the addon for AVG is considered "new" the first time I launch Firefox after a reboot into Windows, but this issue is happening every single time I launch Firefox on the Mac side (not sure at this point about Windows side).

Because the MacBook deals with time differently in Windows and Mac OS, the clock is 3 hours off when I reboot until it can connect to the internet for clock adjustment, so I could understand that files may have a creation time which could be up to 3h in the future on occasion, but not 61 days off. Please fix that bug or indicate a way to disable that feature. If I hit the reset button by mistake, I might as well just look for a different browser than have to rebuild my customization over and over.

By the way, from above request to previous user:
[22:09:42.730] Services.appinfo.replacedLockTime
[22:09:42.733] 1340812112000
[22:09:53.937] Services.startup.getStartupInfo().process
[22:09:53.940] [object Date]
[22:10:32.489] Services.startup.getStartupInfo().process.toString()
[22:10:32.491] "Sun Nov 17 2013 22:07:59 GMT-0500 (EST)"

SYSTEM INFO:
MacBook Pro
15-inch, Mid 2012

Processor  2.3 GHz Intel Core i7
Memory  4 GB 1600 MHz DDR3
Graphics  Intel HD Graphics 4000 384 MB
Software  Mac OS X Lion 10.7.5 (11G63)


Same, on the Windows side, as suggested by [e-mail]:

[20:37:10.208] Services.appinfo.replacedLockTime
[20:37:10.211] 1384842378000
[20:37:31.934] Services.startup.getStartupInfo().process.toString()
[20:37:31.939] "Mon Nov 18 2013 20:28:54 GMT-0500 (Eastern Standard Time)

The message does NOT appear on Windows at all. The "lock time" is very different indeed.

Comment 2

[vincent]

For completeness, here is how it looks today on my Mac OS:

[20:48:31.647] Services.appinfo.replacedLockTime
[20:48:31.650] 1340812112000
[20:48:41.311] Services.startup.getStartupInfo().process.toString()
[20:48:41.313] "Mon Nov 18 2013 20:47:03 GMT-0500 (EST)"



Also, here is the comment from gabriele svelto to my original post in the other bug thread:

From your description of the problem and from the data you posted I think that we're seeing a different issue here, see below:

(In reply to vincent from comment #48)
> [22:09:42.730] Services.appinfo.replacedLockTime
> [22:09:42.733] 1340812112000
> [22:09:53.937] Services.startup.getStartupInfo().process
> [22:09:53.940] [object Date]
> [22:10:32.489] Services.startup.getStartupInfo().process.toString()
> [22:10:32.491] "Sun Nov 17 2013 22:07:59 GMT-0500 (EST)"

Your replacedLockTime is off by over a year compared to the current startup time. It would be interesting to see those two values when running in Windows to compare; my gut feeling is that on Mac the modified time of files on a FAT32 device might be interpreted incorrectly.

Either way the problem is different than what we faced in this bug so could you please open a new one by cloning this bug? It would be very helpful if you could put the info above when running on both Mac and Windows.

In the meantime as a workaround you could consider using separate profiles and sync them via Firefox Sync which works very well for me across multiple devices and OSes.

Comment 3

[Gabriele Svelto [:gsvelto]]

This (In reply to vincent from comment #1)
> Same, on the Windows side, as suggested by [e-mail]:
> 
> [20:37:10.208] Services.appinfo.replacedLockTime
> [20:37:10.211] 1384842378000
> [20:37:31.934] Services.startup.getStartupInfo().process.toString()
> [20:37:31.939] "Mon Nov 18 2013 20:28:54 GMT-0500 (Eastern Standard Time)

Here the relacedLockTime looks correct, but what's more interesting is that ...

(In reply to vincent from comment #2)
> For completeness, here is how it looks today on my Mac OS:
> 
> [20:48:31.647] Services.appinfo.replacedLockTime
> [20:48:31.650] 1340812112000
> [20:48:41.311] Services.startup.getStartupInfo().process.toString()
> [20:48:41.313] "Mon Nov 18 2013 20:47:03 GMT-0500 (EST)"

... the replacedLockTime on the Mac did not change. I have the feeling that what you're seeing on the Mac is not the last file modification time but the file creation time instead or something along the lines. The reason why this is happening is probably the following: on Mac the lock-file is called .parentlock; it used to be called parent.lock however see here:

http://hg.mozilla.org/mozilla-central/file/c335eaa4494a/profile/dirserviceprovider/src/nsProfileLock.cpp#l436

We handle this file in a special way if it's called parent.lock as we expect it to be coming from a very old profile that was not migrated to a recent Firefox version yet. As it turns out on on Windows the lock file is still called parent.lock:

http://hg.mozilla.org/mozilla-central/file/c335eaa4494a/profile/dirserviceprovider/src/nsProfileLock.cpp#l442

So every time you run Windows that file will be re-created if it's not already there and our code will think you have an old lock file or something. The problem should happen when switching between Linux and Windows too.

I'll see if I can reproduce this problem on my box and see if we can do something about it next week if I have some spare time. It could just be a matter of ignoring the old lock file when under Mac/Linux if the new one is already present.