454578 - Mozillazine forum pages load with large font when loaded in background

Status: VERIFIED FIXED

(Core :: Layout, defect, P2)

Description

[Jim Jeffery not reading bug-mail 1/2/11]

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

Comment 1

[Jim Jeffery not reading bug-mail 1/2/11]

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

Comment 2

[RFLazaro]

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

Comment 3

[Jim Jeffery not reading bug-mail 1/2/11]

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

Comment 4

[Simon Bünzli]

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.

Comment 5

[Boris Zbarsky [:bzbarsky]]

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

Comment 6

[Jim Jeffery not reading bug-mail 1/2/11]

Yes, it first appeared with the build in comment #0

Previous nightly was OK.

Comment 7

[Boris Zbarsky [:bzbarsky]]

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

Comment 8

[Jim Jeffery not reading bug-mail 1/2/11]

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...

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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?

Comment 10

[Jim Jeffery not reading bug-mail 1/2/11]

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..

Comment 11

[Jim Jeffery not reading bug-mail 1/2/11]

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

Comment 12

[(mostly gone) XtC4UaLL [:xtc4uall]]

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;

Comment 13

[Boris Zbarsky [:bzbarsky]]

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 14

[(mostly gone) XtC4UaLL [:xtc4uall]]

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.

Comment 15

[Peter van der Woude [:Peter6]]

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

Comment 16

[Daniel C]

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.

Comment 17

[Daniel C]

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

Comment 18

[Jim Jeffery not reading bug-mail 1/2/11]

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..

Comment 19

[Jim Jeffery not reading bug-mail 1/2/11]

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

Comment 20

[Ian]

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

Comment 21

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(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?

Comment 22

[Daniel C]

(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.

Comment 23

[(not currently active) Ted Mielczarek]

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.

Comment 24

[IU]

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.

Comment 25

[Boris Zbarsky [:bzbarsky]]

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

Comment 26

[(not currently active) Ted Mielczarek]

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

Comment 27

[Daniel C]

(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.

Comment 28

[Boris Zbarsky [:bzbarsky]]

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?

Comment 29

[IU]

(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.

Comment 30

[Boris Zbarsky [:bzbarsky]]

Cache just affects timing is all.

Comment 31

[Jose Fandos]

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

Comment 32

[Jose Fandos]

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.

Comment 33

[harmhilvers]

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.

Comment 34

[Boris Zbarsky [:bzbarsky]]

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?

Comment 35

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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?)

Comment 36

[Boris Zbarsky [:bzbarsky]]

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 37

[Boris Zbarsky [:bzbarsky]]

Attachment: Something like this, perhaps?

Comment 38

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.)

Comment 39

[Boris Zbarsky [:bzbarsky]]

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.

Comment 40

[Jim Jeffery not reading bug-mail 1/2/11]

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

Comment 41

[IU]

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.

Comment 42

[Boris Zbarsky [:bzbarsky]]

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).