Open Bug 734943 Opened 12 years ago Updated 6 years ago

FAT/FAT32: Theme reset back to "default" after daylight saving time change

Categories

(SeaMonkey :: Themes, defect)

Product:
SeaMonkey
Component:
Themes
Version:
SeaMonkey 2.7 Branch
Platform:
x86
Windows
Type:
defect
Priority:
Not set
Severity:
minor

Tracking

(seamonkey2.38 affected)

Tracking Flags:
Tracking Status
seamonkey2.38 --- affected

People

(Reporter: commander4bugs, Unassigned)

Details

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Firefox/10.0.2 SeaMonkey/2.7.2
Build ID: 20120216055339

Steps to reproduce:

The first time I run SeaMonkey after a daylight savings time switch, SeaMonkey
resets its theme back to the "Default theme". Originally, I was using the
"Modern theme". Once I set the theme back to "Modern", everything works
until the next daylight savings time switch.

I observed this behavior this weekend (when US switched the time) on four
computers: two Windows 7 and two Windows XP. I vaguely remember the same
theme reset half a year ago when the time was switched back to the winter time.


Actual results:

The theme was reset to "default" on the first boot.


Expected results:

The theme should have been preserved regardless of the daylight savings time.
Did you by chance start up in Safe Mode?
Safe Mode, Help | Restart with Add-ons Disabled, also sets the theme to Default (for that session).

Otherwise some sort of corruption causing it to reset to Default?
(In reply to therube from comment #1)
> Did you by chance start up in Safe Mode?

No, no chance. I launch SeaMonkey every time from the same shortcut
on the desktop, which points to the regular mode, not safe mode.

> Otherwise some sort of corruption causing it to reset to Default?

Since this happens exactly on the first start after a daylight savings
time switch, I could imagine SeaMonkey storing the time stamp
somewhere and then getting confused when this time stamp gets
whacked off by one hour.

As a side note, on all my systems I store the profile on a FAT32 volume.
I have no idea whether this bug would be reproducible with
the profile stored on NTFS. In theory, FAT32 and NTFS store file stamps
in different formats. NTFS stores in UTC but FAT32 in the local time.
If SeaMonkey tries to use the last modification time of some file
as a consistency check, it could be possible that the operating system
would return a different file modification time depending on
whether or not you are asking for the time before or after a daylight
savings time switch.

BTW, only the theme selection is affected by this bug. All other settings
work fine and are not reset. If this is indeed some DST-related corruption,
it should be isolated in the theme handling code.
Did you see any theme resets when DST ended in 2012?
Did you see any theme resets when DST started in 2013?
Flags: needinfo?(commander4bugs)
(In reply to Philip Chee from comment #3)
> Did you see any theme resets when DST ended in 2012?
> Did you see any theme resets when DST started in 2013?

Yes, I saw them most recently this Spring when DST started for 2013.
I don't remember if I saw them in 2012.
Flags: needinfo?(commander4bugs)
That's very strange. Do you have a theme switcher addon that cycles your themes? Please go to about:support and C&P the list of addons there into a comment here in this bug.
(In reply to Philip Chee from comment #5)
> That's very strange.

Yes, it is. The only thing that I can think of is
the FAT/NTFS difference I was talking about in comment #2.
NTFS stores file times in GMT, FAT in local time. Thus,
when the DST is turned on or off, recently modified files
on FAT may gain or lose 1 hour depending on the library used
to deal with file times.

> Do you have a theme switcher addon that cycles your themes?

No. The only add-ons I have are these:

* Adblock Plus
* Russian spell checking dictionary

I also have these three, but they are disabled:

* DOM inspector
* DownThemAll
* User Agent Switcher

> Please go to about:support and C&P the list of addons there into a
> comment here in this bug.

Adblock Plus 2.2.3 true {d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d}
Russian spellchecking dictionary 0.4.4.1 true ru@dictionaries.addons.mozilla.org
DOM Inspector 2.0.14 false inspector@mozilla.org
DownThemAll! 2.0.16 false {DDC359D1-844A-42a7-9AA1-88A850A938A8}
User Agent Switcher 0.7.3 false {e968fc70-8f95-4ab9-9e79-304de2a71ee1}
I'm out of ideas sorry.
@reporter: 
Still a problem for you? 
If yes, can you provoke the Theme change with a shifted Computer clock?
(In reply to Rainer Bielefeld from comment #8)
> @reporter: 
> Still a problem for you? 

The last time I saw this was during the day light savings a few months ago
in March 2015.
@reporter:
Any idea how to provoke the problem with computer clock manipulation?
I will switch all my profiles to MODERN and we will see what happens after 2015-10-25
(In reply to Rainer Bielefeld from comment #10)
> @reporter:
> Any idea how to provoke the problem with computer clock manipulation?

I have never tried doing this explicitly. I usually see this problem
whenever we switch to daylight savings time and back.
(In reply to Rainer Bielefeld from comment #11)
> I will switch all my profiles to MODERN and we will see what
> happens after 2015-10-25

Please place your profile on a FAT/FAT32 volume.

On NTFS file times are natively stored in UTC, so changing
to winter time would not affect time stamps. However, on FAT/FAT32
file times are stored in local time. When the system clock moves,
file times effectively shift by an hour. Thus, if there is a piece
of code in SeaMonkey which uses the time stamp to determine the validity
of a file, it would get fooled into thinking that the file has
been corrupted.

A long long time ago we actually ran into a similar problem
with CDs - our master was cut right before the switch to
the winter time. When the time changed, suddenly all CDs
starting thinking that they contained a corrupted license file
(its time stamp was used among other things to detect changes).
Luckily for us, we caught this before sending the master
to manufacturing - otherwise the entire Christmas batch
of CDs would have been wasted.

BTW, do you want me to do anything special on my systems
before the time shift to help you diagnose this problem?
I created a user profile on a FAT32 USB stick - we will see ...

@Commander:
Is there any possibility to test that more often than 2 times a year (WIN settings, whatever)?
@Commander, are we using the current SeaMonkey, 2.38?

Have you tested with a new, clean Profile?
IOW, it cannot hurt to set up a new Profile, now, open it, set its' theme to Modern, exit, then wait November 1, 2015 (here in the US) & see what happens.

Also can't hurt to make a backup of your existing Profile, a day before & then again after this bug hits you, so you can compare the two backups to see just what has changed.

Are you "syncing"? Restoring from backups? Running Windows System Restore?
Clearing Private Data, using Session Restore?
 
 
I cannot fathom how time or DST, or disk format, FAT/NTFS, have any bearing on a theme reverting?

The Default & Modern themes are stored, loaded, from the Mozilla installation directory, not from the user Profile.

The instalDir does not change unless you install a new version.  There are no date related changes to it. (Possible that some other program affects the instalDir, like A/V [Norton] has been known to remove pieces  of the program itself.)

So you're left with the Profile.

From what I'm seeing, a theme change affects:

> extensions.ini, extensions.json, & prefs.js ... [hmmm] & sessionstore.json ?

Changes are minimal only reflecting the state of things.  No files are added or removed.
 
 
If its happening, & no happening because of a user initiated action, I'm thinking some external cause, with external including extensions. (With possible exception dealing with sessionstore.json.  And while "themes" are referenced in there, I don't know how or if it has any bearing?)
I am 99% sure that I reproduced the problem: today in the morning when I switched from my normal user profile to a test user profile on FAT32 USB stick, SeaMonkey opened with Standard (Classic) Theme, not with Modern Theme I have been used to see with that profile. Unfortunately I yesterday forgot to check whether really "Modern" is selected, there is a very small possibility that I accidentally changed Theme to "Classic" before daytime save change.
Severity: normal → minor
Status: UNCONFIRMED → NEW
status-seamonkey2.38: --- → affected
Ever confirmed: true
OS: Windows XP → Windows
Summary: Theme reset back to "default" after daylight savings time → FAT/FAT32: Theme reset back to "default" after daylight saving time change
(In reply to Rainer Bielefeld from comment #14)
> @Commander:
> Is there any possibility to test that more often than 2 times
> a year (WIN settings, whatever)?

I guess, theoretically it should be possible. If the time
syncing is turned off in Windows and the clock moved back prior
to the DST change, there should be nothing on the computer
that would "give away" the fake. I suspect that one would need
to use the browser for some time to make sure whatever triggers
this bug is written to the profile. If I had to guess, simply
changing the time back and forth would not be sufficient
because the trigger for this bug would not even be generated.
(In reply to therube from comment #15)
> @Commander, are we using the current SeaMonkey, 2.38?

Yes.

> Have you tested with a new, clean Profile?

When I saw this, I was using the same profile I have been
using for years. It has happened on several computers I use.

> Are you "syncing"?

If you mean syncing time through Windows Time - no. If you
mean syncing through SeaMonkey profile sync - no.

> Restoring from backups?

No. Just regular every day use - email, news etc.

> Running Windows System Restore?

I have it completely turned off and disabled.

> Clearing Private Data, using Session Restore?

Neither of those. I typically have all cookies disabled
and enable session specific cookies only for certain
website that actually need them.

> I cannot fathom how time or DST, or disk format, FAT/NTFS,
> have any bearing on a theme reverting?

The problem with FAT is that all dates/times are stored in local
time on disk. However, all Win32 APIs deal with time in UTC.
Thus, Windows has to make a conversion.

Imagine that you modified a file, say, at 14:00 on Saturday
before the DST change. Also imagine that this is happening
in California, which is GMT-8 hours. Due to the summer time,
it is actually 1 hour ahead, so GMT-7.

If you were to look at this file on disk and through Win32
you would see this:

disk:  14:00
Win32: 21:00 (14:00 + 7 hours)

Then you wait a day and let the time go back to winter time.
Thus, Windows now thinks that the computer is GMT-8 now.
If you look at the same file again, you will see this:

disk:  14:00
Win32: 22:00 (14:00 + 8 hours)

Notice that on disk nothing has changed. However, through
the Win32 API the file went forward by 1 hour. If the file
time stamp was recorded and stored in some other file (for
consistency checking) prior to the time change and then
compared to the actual file stamp after the time change,
you would see 1 hour difference, which would fail the
consistency check.

As you can see, this has nothing to do with any external
activity, it is the time change that triggers a purely
mathematical change in time stamp perception.

> (Possible that some other program affects the instalDir,
> like A/V [Norton] has been known to remove pieces  of the program
> itself.)

In my case I do not run any antivirus. Even the Windows Defender
is disabled and blocked from starting. Personally, I prefer
running a very strict firewall with explicit in/out restrictions
only for applications I know need to go out. Everything else
is blocked. That does require being careful which links you
click on but in return I get the full speed of my system.

> If its happening, & no happening because of a user initiated
> action, I'm thinking some external cause, with external including
> extensions.

I have a limit set of extensions in my browser:

* Adblock Plus
* DOM Inspector
* True Full Screen in SeaMonkey
* DownThemAll (disabled)
* User Agent Switcher (disabled)
Something new here?
You need to log in before you can comment on or make changes to this bug.