23295 - [PERF][4.xP] linked .css file is slow to take effect, causing text to flash

Status: VERIFIED DUPLICATE of bug 17309

(Core :: CSS Parsing and Computation, defect, P3)

Description

[ekrock's old account (dead)]

Moz M12 1999122023 on WinNT 4.0 SP3.

To repro:
1) open s_agend1.htm

Expected: see only Agenda and 2 bullet items; remaining DIVs on page are hidden
by visibility rule settings in CSS files and as a result their enclosed text is
never seen by user.

Actual: the text of the DIV (which has visibility: hidden) shows on the screen
and then disappears in a split second, causing a flashing effect.

Here's the DIV:
<DIV ID="tutorialsection"><P>First we'll learn how to use the template. Then
we'll see some sample pages.</P></DIV>

Here's the CSS markup that sets its visibility:
/* style.css: CSS1 style sheet for htmlpres HTML presentation template.
   Eric Krock, Netscape Communications, 10 July 1997.  */

#speakernotessection {position:absolute; visibility:hidden;}
#tutorialsection {position:relative; visibility:hidden;}
.agendahilite    {color:red; background-color:yellow; }

Suspected source of problem:
1) We've turned on incremental layout, so now there's an initial display before
everything's been loaded.
2) There's a style.js JavaScript file in the HEAD that precedes the style.css
CSS file. This style.js file checks screen resolution and then creates a
bunch of CSS rules from JavaScript to adjust font sizes to match screen size.
The real source of the problem may be that this JavaScript file is processed too
slowly by M12, compared to Nav4 and IE5, and this is the delay that causes the
noticeable flash.
3) Be aware that the JavaScript evaluated on Nav4, IE5, and M12 to define CSS
rules from JavaScript is (necessarily) different JavaScript since these are
three different DOMs.

Note that you don't see this flashing effect in Nav4 or IE5, so this is a
noticeable performance problem compared to them.

Comment 1

[ekrock's old account (dead)]

Attachment: s_agend1.zip: WinZIP file with s_agend1.htm, style.css, style.js

Comment 2

[ekrock's old account (dead)]

I'm not marking this [TESTCASE] is it may be possible to simplify each of the
three files further, but I've got to do some other work right now! ;->

Comment 3

[ekrock's old account (dead)]

Another data point: if you modify s_agend1.htm so that the CSS rules are inline
in the HTML file in a STYLE element at the same location as the LINK was, the
problem no longer occurs. So this definitely has to do with performance on
loading externally LINKed CSS files as opposed to processing inline CSS style
rules. Attaching ZIP file with modified s_agend2.htm demonstrating this.

Comment 4

[ekrock's old account (dead)]

Attachment: WinZIP file with modified s_agend2.htm (inline CSS rules) and style.js, not showing bug.

Comment 5

[troy]

This sounds like the known issue that we load linked style sheets
asynchronously. Deferring to Pierre

Comment 6

[Pierre Saslawsky]

Correct: it's a dup of 17309 "Wait for primary style sheets before constructing
frames".


*** This bug has been marked as a duplicate of 17309 ***

Comment 7

[Chris Petersen]

Marking as verified dup of 17309.