137159 - [RR/RCF]HTTP Link headers interfere with page rendering

Status: RESOLVED FIXED

(Core :: CSS Parsing and Computation, defect)

Description

[Peter Janes]

I have enabled "Link" headers that provide common stylesheets for all of my
pages.  I've noticed that a lot of the time--reproducibly in a set of pages, but
not always on the same page--only the last part of the page will be rendered.

Reloading the page often fixes the problem, but it's sometimes necessary to
force a full reload with shift-refresh.  I've verified on the server logs that
the entire page and all of its related assets are retrieved.

This behaviour is independent of HTML or XHTML (served as HTML), and occurs
within frames (Javadoc-generated) and in normal pages.  It disappears entirely
when the Link header is disabled.

I've verified that even a trivial stylesheet with |body
{background-color:white;}| will cause the problem.

The Apache .htaccess line I use to turn this behaviour on is:

Header append Link "</default.css>; rel=\"stylesheet\"; type=\"text/css\";
title=\"My Styles\""

which causes

Link: </default.css>; rel="stylesheet"; type="text/css"; title="My Styles"

to appear as expected in the HTTP headers.

This happens on Linux build 2002040508, but I've seen it for some time so it
hasn't been introduced recently.

Comment 1

[Darin Fisher]

-> style system ?!

Comment 2

[Peter Janes]

It originally appeared that |Link: </>; rel="top"| had a similar effect, but
less often.  After doing some more tests today, I'm not convinced this is true
(although, as mentioned in other bugs, the site navigation bar doesn't deal with
HTTP headers yet, so it may not be triggered).

I previously tried including this stylesheet directly from the (X)HTML documents
using |<link rel="stylesheet" href="/default.css" />| with no problems, which is
why I believe it is localized to using the HTTP header.

Neither of these mean it *isn't* a style issue, but explain why I entered the
bug against Networking:HTTP to start rather than Networking:Cache, Layout or
Style System.

Comment 3

[David Barnes]

I created a test page with a Link header here: http://algonquin.tzo.com/header/

For me on build 2002041103 it will work properly the first time I hit it, but
refreshes seem to cause the external style sheet to not properly work. The first
seven test lines using stuff from the style sheet will disappear, but at the
bottom page where I resume using styles, they work. I looked at the http request
and it appears the external style sheet is being fully loaded each time. Be sure
to hit refresh on the test page to see the problem.

If I don't have all of that sample code in the middle, the style sheet works
fine for everything.

Comment 4

[Heikki Toivonen (remove -bugzilla when emailing directly)]

David Barnes, I was able to reproduce your test. Could you create another
testcase where the HTML is valid on the page? For example, the six divs in the
beginning should have p inside, and no empty p after them. I just want to make
sure that it is not limited to bad HTML. Please leave the original in place,
just add a new test...

Comment 5

[Peter Janes]

Better to have David Barnes confirm with his minimal test case, but I (the
reporter) can confirm that I've seen the problem with both bad HTML and valid
XHTML (verified against W3C's validator as well as nsgmls with the W3C DTD).

Comment 6

[David Barnes]

Sorry for the delay, I was gone for the weekend. Here is the new test case:
http://algonquin.tzo.com/header/valid.asp

I noticed that if I go to the first test http://algonquin.tzo.com/header/ and
then to the second, and then hit the Back button, the first test case works.
Then hitting refresh causes it not to work.

Also, the second case seems to make my red text disappear.

Comment 7

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Adding harishd in case this is something in the parser. Has anyone checked the
content model for that page when parts are missing, like with viewer dump
content or DOM Inspector?

Comment 8

[harishd]

The missing content appears in the content-model though! AFAIK, this is a layout
bug.

Comment 9

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

This seems like it could be related either to bug 138290 or another bug that bz
found a regression date for yesterday.

It also sounds like we're not reading the link headers as early as we should be.

Comment 10

[R.K.Aa.]

related to pipelining? (bug 140853, bug 140107, bug 144574 and more)

Comment 11

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

The other bug I was thinking of was bug 144004.

Comment 12

[Boris Zbarsky [:bzbarsky]]

This regressed in the same time-period as bug 138290... Dec 12, 2001 to Jan 7, 2002.

We process the Link: header in HTMLContentSink::Init (see the
ProcessHTTPHeaders() call).  I suspect the problem is that the return value of
ProcessHTTPHeaders() is not propagated out.  Nor is the return value of
ProcessHeaderData() propagated out by ProcessHTTPHeaders().  So the parser does
not block on the sheet load, unlike in the <link>-tag case...  worse yet, this
all happens before mParser has been set on the sink, so the sink has no way of
passing the parser to the CSSLoader, so it can't make the parser block if it
wanted to.  Then the sheet comes in partway through the pageload, we re-resolve
(instead of reframing as we used to) and things break.

Do we want the parser to block on such loads?  If so, we need to postpone
processing of these headers till after we have an mParser in the sink.... we
also need a way to block the parser "up front", so to say....  Finally, we need
to consider what happens in the case of multiple Link: headers... we would need
to only unblock on the last one or something...

Comment 13

[Hixie (not reading bugmail)]

In that case this should be fixed by fixing bug 84582.

Comment 14

[Boris Zbarsky [:bzbarsky]]

Yep.  Patch for bug 84582 makes us block layout for these sheets like other sheets.