Cache version not bumped for Fx 10

RESOLVED WONTFIX

Status

()

RESOLVED WONTFIX
7 years ago
3 years ago

People

(Reporter: scoobidiver, Unassigned)

Tracking

10 Branch
Points:
---

Firefox Tracking Flags

(firefox10-, firefox11-)

Details

(Reporter)

Description

7 years ago
Fx 10 has a cache format different from Fx 9 causing many website displaying problems to users that think it's caused by the new version.
Those displaying problems are fixed after clearing the cache.

There should be a dialog box on the first run after upgrading Firefox to warn users to clear the cache to prevent displaying problems in case the cache format is different from the previous version.

Comment 1

7 years ago
I don't know of any disk cache changes that would cause this. Anyone else?

Comment 2

7 years ago
Digging through the code, it looks like this is when the PRBool->bool transition hit release. The dirty bit in the cache map was changed in the code. Does anyone know if PRBool and bool serialize differently (either in value or size)? That's the only thing that might have gone wrong from what I can see, if the change now causes the map to be read incorrectly. If the two types do serialize differently, then the cache version should have been bumped, which would have blown away the cache on startup, meaning users would never have seen any errors caused by differences in the cache format.

Scoobidiver, do we know what kinds of issues the users are seeing? Are the errors along the lines of "I got the wrong content" (ie, went to google.com got showed microsoft.com), or "it looked funny" (as if we failed to load CSS or something), or "the page didn't load"?

Comment 3

7 years ago
OK, according to IRC, there are at least some platforms on which sizeof(PRBool) != sizeof(bool), so this could conceivably be the source of our problems. We should probably not be writing a C++ bool to disk at all, given there's no guarantee that the compiler can't change its size on us between versions or even with different compiler flags.

Sadly, if this is the source of our problems, there's obviously not much we can do for 10.0 or 10.0.1, but we should probably bump the cache version for 11 (and use some other, known-size type for the dirty flag starting then, as well).
(Reporter)

Comment 4

7 years ago
(In reply to Nick Hurley [:hurley] from comment #2)
> Scoobidiver, do we know what kinds of issues the users are seeing?
* Missing formatting for some websites. See http://www.geckozone.org/forum/viewtopic.php?f=5&t=102553
* Loading in progress on a webmail. See http://www.geckozone.org/forum/viewtopic.php?f=5&t=102337
* A user got a "Firefox prevents the page to be redirected" message on some forums after upgrading from 10.0 to 10.0.1. See http://www.geckozone.org/forum/viewtopic.php?f=5&t=102762
Bug 94199 added some kind of startup cache for XBL bindings that landed in 10, but I have no idea if that's the same cache or something else entirely.
(Reporter)

Updated

7 years ago
Summary: Warn to clear the cache on the first run after upgrading Firefox if the cache format has been changed → Cache version not bumped for Fx 10
(Reporter)

Updated

7 years ago
Version: unspecified → 10 Branch
(Reporter)

Updated

7 years ago
Severity: enhancement → normal

Comment 6

7 years ago
Hrm, actually, the type we serialize to disk didn't change (it's always been a PRUint32). However, we switched from assigning a PR_{TRUE,FALSE} to assigning a {true,false} value. This might not be the problem after all...
tracking-firefox10: --- → +
tracking-firefox11: --- → +
If the cache wasn't invalidated properly from 9->10, I guess that could explain why bug 724129 was so common.

Comment 8

7 years ago
Yeah, looking at this more, I don't think the PRBool->bool switch was the problem, given that the type written to disk stayed the same. I can't imagine the compiler failing to properly cast 0 or 1 to false or true (respecitvely). Furthermore, other than PRBool->bool in this one instance, I can't see anything in the disk cache that changed the on-disk format, so I don't think that's the source of our problems. Sorry for the red herring, folks.
(Reporter)

Comment 9

7 years ago
Here are the cache bugs that were introduced in Fx 10:
bug 661900, bug 681546, bug 687081, bug 687085, bug 699409
Here are the storage bugs that were introduced in Fx 10:
bug 658303, bug 672324, bug 678977, bug 688913

Comment 10

7 years ago
None of those cache bugs affected on-disk format at all, so we're safe from that perspective (ie, we didn't need to bump the version number). One (bug 661900) is memory cache, so that doesn't survive browser restarts anyway. Three (bug 687081, bug 687085, and bug 699409) are all telemetry gathering, so fairly minor changes. The last one (bug 661900) was a change to our algorithm for calculating the max size of the disk cache, to make it less likely that we would cause a lot of I/O on startup. I don't know that code too well (Michal knows better than I do), but I can't imagine this change causing issues loading/rendering/redirecting pages.

I can't speak to the storage bugs, as I don't know that code at all.
(In reply to Scoobidiver from comment #0)
> Fx 10 has a cache format different from Fx 9 causing many website displaying
> problems to users that think it's caused by the new version.
> Those displaying problems are fixed after clearing the cache.

How do we actually know there is a different "format" of the cache on the disk?  If we would change it, I don't think the cache would work at all and we would figure that out very soon.



(In reply to Scoobidiver from comment #4)
> * A user got a "Firefox prevents the page to be redirected" message on some
> forums after upgrading from 10.0 to 10.0.1. See
> http://www.geckozone.org/forum/viewtopic.php?f=5&t=102762

I really don't speak French, sorry :)  According this comment, however, the problem seems to appear after update from 10.0 to 10.0.1.  But I don't see anything in the pushlog that would have any affect on this: http://hg.mozilla.org/releases/mozilla-release/pushloghtml?fromchange=697df1a1ba3c&tochange=976d144a254c


What was the presumption of a single problem with cache format?  The issues from comment 4 seems unrelated to any cache format mismatch.  I think it's more some change in how we validate responses or process redirects.
(Reporter)

Comment 12

7 years ago
(In reply to Nick Hurley [:hurley] from comment #2)
> Scoobidiver, do we know what kinds of issues the users are seeing?
* Missing formatting for some websites. See http://www.geckozone.org/forum/viewtopic.php?f=5&t=102895
Based upon the discussion in this bug, we don't think there's reason to believe that the issues in comment#4 are related to a cache version bump. I've emailed cww to see if we've seen similar issues on SUMO. If yes, this bug can be repurposed to no longer imply relation to a cache bump and would turn into a QA repro investigation.
tracking-firefox11: + → -
tracking-firefox11: - → +
(In reply to Alex Keybl [:akeybl] from comment #13)
> Based upon the discussion in this bug, we don't think there's reason to
> believe that the issues in comment#4 are related to a cache version bump.
> I've emailed cww to see if we've seen similar issues on SUMO. If yes, this
> bug can be repurposed to no longer imply relation to a cache bump and would
> turn into a QA repro investigation.

SUMO has nothing that matches this bug report at this time. Untracking for FF10/11.
tracking-firefox10: + → -
tracking-firefox11: + → -
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.