Closed
Bug 6541
Opened 26 years ago
Closed 26 years ago
M5: loading of linked CSS style sheet is slow
Categories
(Core :: CSS Parsing and Computation, defect, P3)
Tracking
()
VERIFIED
INVALID
People
(Reporter: ekrock, Assigned: peterl-retired)
References
()
Details
To repro:
1) open URl; slide #1 is displayed
2) click "right arrow" (blue image on right) twice; when slide #3 displays,
note that some black text briefly appears at the bottom of the slide and
then disappears [this is file s_agenda.htm]
3) click "right arrow" again; when slide #4 displays,
same thing happens [this is file s_agend1.htm]
Try the same thing in Nav4.51 and you never see the text at all.
What's happening: each slide includes a link at the top of the BODY:
<LINK REL=STYLESHEET TYPE="text/css" HREF="style.css">
[ this is file http://blues/users/ekrock/publish/bugs/M5/onclick2/style.css ]
Here is the CSS markup of that file:
#speakernotessection {position:absolute; visibility:hidden;}
#tutorialsection {position:relative; visibility:hidden;}
That markup causes the DIV at the bottom of agenda.htm to be hidden:
<DIV ID="speakernotessection">
<H1>Speaker Notes</H1>
<P>This is speaker note text for testing ...</P>
<P>Look how the scroll bars click on in frameset document notes.htm
when we have many lines of</P>
<P>text</P>
<P>text</P>
<P>text</P>
</DIV>
Or, perhaps the problem is that Gecko is so fast that it displays all the HTML
first, *then* applies the style markup in a second pass? Regardless, when Gecko
first displays content on the screen, the content should reflect the effect of
any included static style sheets.
Assignee | ||
Updated•26 years ago
|
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → INVALID
Assignee | ||
Comment 1•26 years ago
|
||
This is a feature. When loading external style sheets (via <LINK>), we first
dispolay the document without the style sheets without waiting for them to load.
Then when all sheets are loaded, we reflow with the sheets.
If you don't want your document to display without the sheet, change the rel to
"important stylesheet" (or "stylesheet important"), or put all of your style
inline.
Updated•26 years ago
|
Status: RESOLVED → VERIFIED
Comment 2•26 years ago
|
||
Verifying invalid
Comment 3•26 years ago
|
||
Will we get this second reflow with style if the stylesheet has been cached
already?
This is a real problem for XUL dialogs that use CSS, because the user sees a
double-load effect. Look at the preferences dialog in apprunner for a
particularly painful example.
Assignee | ||
Comment 4•26 years ago
|
||
Two things: first, for XML content, we don't display the document without the
*persistent* style sheets (those with no title). So you'll only see one reflow.
If you have style sheets with titles, you'll get two reflows.
Second, you can instruct us to always wait for the style sheet (in HTML or XML)
by changing the rel to "important stylesheet".
Comment 5•26 years ago
|
||
cc: matt, so he sees the comments about how to avoid the double reflow in the
prefs dialog.
Assignee | ||
Comment 6•26 years ago
|
||
I don't see a "double load" in the prefs dialog in AppRunner. Also verifyied
under the debugger that all CSS loading for XUL documents wait for the style
sheet to load.
The only ways to get an XML document to display first without its stylesheet(s)
are: 1) explictly specify the sheet as an alterate. (<?xml-stylesheet
alternate="yes" ... ?>) 2) Give the sheet a title (making it either preferred or
alternate, not persistent) or 3) Have your processing instruction after the
content (then the content before the PI may display without the sheet).
The rel="important" trick actually only works for HTML style links and HTTP
header links. (Since XML style sheet PIs don't have a "rel" attribute.)
Comment 7•26 years ago
|
||
I'm not seeing it now in the prefs either, but it certainly happened a few
days ago. Prefs crash now anyway, so it's rather hard to test.
Comment 8•26 years ago
|
||
Yeah, I don't see this either.
Comment 9•26 years ago
|
||
Verifying bug invalid per 5/26 comments by peterl.
You need to log in
before you can comment on or make changes to this bug.
Description
•