1. Load 3 or 4 tabs with: forums.mozillazine.org 2. close/restart the browser 3. Note that at least 1 page will have very large fonts (clears to normal with page refresh F5) This happens with or without JIT enabled (content) Perhaps due to bug: https://bugzilla.mozilla.org/show_bug.cgi?id=396519 Today's nightly: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b1pre) Gecko/20080910043000 Minefield/3.1b1pre Firefox/3.0 ID:20080910043000 Vista HP SP1

Additional: Takes several tabs open to repo, and at least one of the tabs should contain the t-box page to get the issue to show. Using this t-box: http://tinderbox.mozilla.org/showbuilds.cgi?tree=Firefox

I can confirm this using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080910043000 Minefield/3.1b1pre

Backout of https://bugzilla.mozilla.org/show_bug.cgi?id=396519 didn't fix the 'large font' issue..

No Session Restore issue: 1. Load http://tinderbox.mozilla.org/showbuilds.cgi?tree=Firefox and http://forums.mozillazine.org/ 2. Open half a dozen forums in the background Actual result: A few of those pages will load with larger-than-default fonts.

Is this a regression? If so, when did it regress?

Yes, it first appeared with the build in comment #0 Previous nightly was OK.

This only happens when loading tabs in the background, right? I would bet that this is a regression from bug 453896, if so. The relevant checkin range is http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2008-09-09+00%3A00%3A00&enddate=2008-09-10+06%3A00%3A00

With the lack of hourly archieves, its going to be hard to pin this down any further unless someone can back out the patch noted above and test. I do not have the knowledge to do my own builds..or backout patches...

Could you look in DOM Inspector in the tabs that have the incorrect font size and see if rules from quirks.css are being applied? It's likewise a little hard for me to test if a backout of a particular patch helps if I can't see the bug in the first place. Do the tabs need to be loaded in the background while the tinderbox page is in the middle of loading or reloading?

Will try to look tomorrow, unless someone beats me to it. It seems to be when several tabs are loaded at browser start from a previous sessionstore. It does indeed seem to occur if the mozilla forum tabs are loading in background. My tab line up usually consistes of cnn.com msnbc.com 3-4 tabs of mozillazine tinderbox tab pushlog tab sometimes I have a couple tabs of interesting bugs I'm following. Save&Exit, restarting the browser will manifest the problem for me. Sometimes only one of the mozillazine tabs is affected, other startups all 3 are affected. A reload of the tab will usually restore the proper font size. Its not reliable, but I have seen the tabs jump to large font size on just a reload of the page, but I don't have a good STR for that..

While I'm not real familiar with the workings of DOMi, I looked at 'Stylesheets' and I don't see where there is anything like quirks.css Looking at the rules for both the bad tab, and a good one, the stylesheet rules are the same counts down the list. Also I looked at page info and it states there Render mode: Standards compliance mode Encoding: UTF-8 text/html content style: text/css sorry..appears this is not going to be much help..unless you can give me some guidance on where to look in DOMi

for me it happens occasionally when loading the build forum (http://forums.mozillazine.org/viewforum.php?f=23) and then ctrl+click/middle-clicking on a thread. it happens only on the first tab being loaded in the background. with DOMi inspecting the first table gives me: table resource://gre/res/html.css line 165 with display: table; border-spacing: 2px; border-collapse: separate; margin-top: 0pt; margin-bottom: 0pt; -moz-box-sizing: border-box; text-indent: 0pt; table resource://gre/res/quirk.css line 96 with text-align: start; white-space: normal; line-height: normal; font-size: -moz-initial; font-weight: -moz-initial; font-style: -moz-initial; font-variant: -moz-initial; table, td, th resource://gre/res/quirk.css line 112 with border-top-color: gray; border-right-color-value: gray; border-bottom-color: gray; border-left-color-value: gray; border-left-color-ltr-source: physical; border-left-color-rtl-source: physical; border-right-color-ltr-source: physical; border-right-color-rtl-source: physical; * http://forums.mozillazine.org/style.php?sid=ddd5aa351cfda1223a1a7add059288c6&id=1&lang=en line 15 with margin-top: 0pt; margin-right-value: 0pt; margin-bottom: 0pt; margin-left-value: 0pt; margin-left-ltr-source: physical; margin-left-rtl-source: physical; margin-right-ltr-source: physical; margin-right-rtl-source: physical; padding-top: 0pt; padding-right-value: 0pt; padding-bottom: 0pt; padding-left-value: 0pt; padding-left-ltr-source: physical; padding-left-rtl-source: physical; padding-right-ltr-source: physical; padding-right-rtl-source: physical;

Jim, you want to click on a node in the DOM tree, then in the top right hand box select the "CSS Style Rules" viewer to see all rules applying to that DOM node. <table> or <p> elements are often good ones to look for in terms of figuring out whether quirk.css is applied. XtC4UaLL, was that in the failing case, or the non-failing case? Do you also see the quirk stylesheet in the other case?

comment 12 is the failing case. the non-failing case lists for the same tab after hitting ctrl+f5 (just) following files with above mentioned rules: table resource://gre/res/html.css line 165 * http://forums.mozillazine.org/style.php?sid=ddd5aa351cfda1223a1a7add059288c6&id=1&lang=en line 15 so the quirk.css file is not being applied at all.

A misrendered Mozilazine page was 32kb in size and after hitting F5 it grew to 58kb (and was rendered correct needless to say)

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b1pre) Gecko/20080920020551 Minefield/3.1b1pre I just hit this again with 2 Mozillazine forum tabs and no others. One had normal fonts, and one had large fonts. I think the large one was loaded in the background but I'm not sure... Both show Render mode: Standards compliance mode in Page Info. Highlighting a large-font element in DOM Inspector shows font-size: 28.8px and line-height: 33.4px in computed style. A normal-sized element from the other tab shows font-size: 18px and line-height: 20.8667px for computed style. Following the CSS Style rules up the tree shows no difference until the <td> and <table> elements which include rules from resource://gre/res/quirk.css in the large-font case including line-height: normal and font-size: -moz-initial This didn't involve having a Tinderbox page open, but I think it did involve loading in the background (it's not easily reproducible and happen during normal browsing so I can't really remember). Hope this helps.

Unlike comment 15, after refreshing the large-font page, it fixed itself but the size was the same.

I was testing a TraceMonkey try-server build yesterday, and it did not experience this issue at all no matter how hard I tried. What could be the difference ? The TM try-server builds from what I can see was merged with m-c builds just a couple days ago, this bug has been around longer than that..

NeverMind comment above, I finally made the TM build mess up also.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b1pre) Gecko/20080926073419 SeaMonkey/2.0a2pre ID:20080926073419 Happens here as well http://www.bookspotcentral.com/forum/viewtopic.php?f=27&t=6155 just so you have a different forum for testing on Definitely loading in the background, oddly enough not all tabs do this just one or two maybe

(In reply to comment #16) > Following the CSS Style rules up the tree shows no difference until the <td> > and <table> elements which include rules from resource://gre/res/quirk.css in > the large-font case including line-height: normal and font-size: -moz-initial So you're saying that there was a difference between the case where the page loaded correctly and the case where you saw the bug? And was it that the quirks.css rules were present in the case where you saw the bug?

(In reply to comment #21) > (In reply to comment #16) > > Following the CSS Style rules up the tree shows no difference until the <td> > > and <table> elements which include rules from resource://gre/res/quirk.css in > > the large-font case including line-height: normal and font-size: -moz-initial > > So you're saying that there was a difference between the case where the page > loaded correctly and the case where you saw the bug? And was it that the > quirks.css rules were present in the case where you saw the bug? Yes and yes.

dbaron asked me to try commenting out the nsPresShell change from this changeset: http://hg.mozilla.org/mozilla-central/rev/250798f99819 + mViewManager->FlushDelayedResize(); I did so and rebuilt, and I can still reproduce the large font issue.

Could this be a regression from bug 290018? I don't understand that bug, but here's my observation: The problem occurs only when pulling the page content from disk cache. If disk cache is completely disable and purged, subsequent restarts do not exhibit this bug.

Hmm. I assume people _are_ seeing this in safe mode, right?

I just double checked, and I can reproduce it in safe mode.

(In reply to comment #25) > Hmm. I assume people _are_ seeing this in safe mode, right? Yes. I forgot to mention it but comment 16 was in a fresh profile.

Ted did some poking around into this, and this _could_ be fallout from my cloning changes, maybe. One effect of that change is that now there is a single quirks stylesheet that is shared by all style sets, whereas before there were multiple nsICSSStyleSheets (but only one inner). I've been thinking about why this doesn't bite more pages, and I suspect that what happens is that we enable/disable the quirks sheet, then get the rule cascade before anything else happens, so the rule cascade is correct even though later on the quirks sheet's state can change. So to hit this bug we have to either clear the rule cascade on the UA sheet or to request a different rule cascade from it, or to not create the rule cascade until some other pageload has changed the quirks sheet state. David, can you think of any way to trigger any of those reliably?

(In reply to comment #28) > > I've been thinking about why this doesn't bite more pages, ... My thought is that you won't see this with any potentially susceptible page, if that page is not cacheable and thus is not loaded from cache after a restart.

Cache just affects timing is all.

I've just had this happen to me on lwn.net homepage with Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.4pre) Gecko/2008101305 GranParadiso/3.0.4pre

hmm, forget that. Now I'm not certain if on previous visits I had this page text zoom applied. On resetting the zoom it went back to normal. Sorry for the spam.

I'm on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b2pre) Gecko/20081020 Minefield/3.1b2pre and I just experienced this bug, at least it looks a lot like it. I had one tab open and opened http://forums.mozillazine.org/viewtopic.php?f=23&t=911635 in that tab. While this tab/page was still loading I pressed cmd+t to open a new tab to load http://planet.gnome.org/. When I went back to my first tab with MozillaZine the font was way too large, not zoomed. After a reload everything went back to normal. Apparantly this bug is not Windows specific, but I don't seem to able to edit the platform.

OK, so the obvious options are either to stop importing quirk.css from ua.css and instead load it directly from nsContentDLF and put it directly into style sets (and then disable/enable it as now) or to change the quirk-disabling code to do something different from the way it works right now. David, any preference as to which way we go here?

Loading quirk.css directly from nsContentDLF makes sense to me -- although maybe we should load both it and ua.css from nsLayoutStyleSheetCache... (You're thinking this is related to bug 450191, then?)

I think it's basically related to comment 28. On trunk right now we're basically relying on the UA-level rule cascade being constructed once right after the quirks state is reset and never cleared afterward, which seems like it could fail as an assumption. I guess we should fix that and then see what this bug looks like.

Comment on attachment 345052 [details] [diff] [review] Something like this, perhaps? r+sr=dbaron. Can we get rid of some of the assertions in nsStyleSet::EnableQuirkStyleSheet now? (Then again, it might be worth keeping something to warn about the performance implications of toggling too late.)

I don't think we can get rid of those assertions quite yet, no. The document.write case is still a problem, I think. Pushed changeset acb5b8cace74. This should be fixed, but if someone who could reproduce can verify, that would be very nice.

I hit this bug all the time, and using build below I can verify its indeed fixed. Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b2pre) Gecko/20081103 Minefield/3.1b2pre Firefox/3.0 ID:20081103002737 <- hourly build Changeset: http://hg.mozilla.org/mozilla-central/rev/87267825681b

I'm not sure this bug is completely fixed. Either the Update Scanner v.2.2.3 extension exposes lingering issues with this bug or there is a problem with the extension itself. To see what I mean: 1. Download and install Update Scanner (https://addons.mozilla.org/en-US/firefox/addon/3362). Use Nightly Tester Tools or edit install.rdf to install it. 2. Visit http://forums.mozillazine.org 3. Click the Update Scanner icon in the statusbar 4. Click the "New Entry" button (the first button from left) in the sidebar 5. Click OK. 6. Click the "Index page * mozillaZine Forums" entry you just added. 7. Notice the page just got loaded with large fonts. Most other sites are okay, but sites like mozdev.org also exhibit the problem. Note: if you want to very with other sites, be warned that the latest nightlies have introduced a problem that prevents Step 6 from working, beyond the first entry, until Firefox is restarted.

That's a bug in the extension: it sticks the DOM for the page into a quirks-mode about:blank document (probably also screws up all sorts of security checks in the process, but whatever).