79021 - All stylesheets are loaded regardless of rendering media

Status: RESOLVED WONTFIX

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

Description

[Sampo Syreeni]

User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; 0.8.1) Gecko/20010327
BuildID:    2001032722

When I fire Mozilla on my site, which has separate print and aural styles,
Mozilla still loads all stylesheets, making for needlessly bad performance for
the first page over low speed connections. Probably eats style memory and
rendering speed as well (as I understand it, Mozilla currently keeps all the
style data in memory, and in this case overrides for different media cause
extraneous tree traversal when rendering).

Reproducible: Always
Steps to Reproduce:
1.Go to a site with media="aural"-tagged stylesheet links
2.See server log

Actual Results:  Aural, print, etc. sheets are fetched immediately upon entering
the site

Expected Results:  Stylesheets should only be loaded when they are truly needed
(in the current versions, Mozilla does not need aural stylesheets, for instance,
and print stylesheets should not be fetched until it is time to print)

I acknowledge that this is a pure performance problem, and since caching seems
to be working, it becomes a nuisance. A one that may not even be easily fixed (I
imagine one would have to change the plumbing of the style system a bit to get
lazy fetches). So I'm marking this as minor.

Comment 1

[Alvaro Munoz-Aycuens]

Worksforme on Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.1+)
Gecko/20010615, pages load as expected, since post is almost a month old i going
to mark it as worksforme, poster if you try it with a current build and problems
persist feel free to reopen the bug.

Comment 2

[Sampo Syreeni]

As I said, this is a performance issue only. There are absolutely *no*
correctness or standards issues, here.

Going to a rough copy of the page cited above, the screen stylesheets are
fetched, but in addition, we get:

131.228.6.20 - - [18/Jun/2001:11:28:54 +0300] "GET
/shared/style/dc-mono/dc-mono-11-aural-xstruct.css HTTP/1.1" 200 453
131.228.6.20 - - [18/Jun/2001:11:28:55 +0300] "GET
/shared/style/dc-mono/dc-mono-11-aural-xhtml.css HTTP/1.1" 200 1450
131.228.6.20 - - [18/Jun/2001:11:28:55 +0300] "GET
/shared/style/dc-mono/dc-mono-11-paged-xhtml.css HTTP/1.1" 200 372
on Mozilla 0.9.1-MathML-SVG (2001-06-09-17). It's pretty clear that stylesheets
for all media are loaded, when only the screen sheets are actually ever used.
I'm not sure whether this should be minor bug, an RFE, or if it's sheer pedantry
that should be left closed - this is about performance when non-screen
stylesheets are present (especially when working without HTTP 1.1 pipelining and
a high roundtrip delay), not a common occurrence nowadays. Reopening for now,
with apologies for the extra work if it ain't worth it.

Comment 3

[James Lariviere]

This sounds like a good idea to me. [rfe]

This should be considered at a future date.

MArking NEW. :-)

Comment 4

[Pierre Saslawsky]

Marked dependency on bug 84582.

Comment 5

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

Assigning pierre's remaining Style System-related bugs to myself.

Comment 6

[Brant Gurganus]

[RFE] is deprecated in favor of severity: enhancement.  They have the same meaning.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Hmm.. So what exactly should we do here?  We probably need to load the screen
and print sheets no matter what, so we can print.  What about the rest?  Problem
is, the CSSOM will expect them to be there...

Comment 8

[Henri Sivonen (:hsivonen)]

> We probably need to load the screen and print sheets no matter what, so we can 
> print.  What about the rest?  Problem is, the CSSOM will expect them to be 
> there...

I suggest not loading the other style sheets and filing a bug against the CSSOM
spec if it requires inapplicable style sheets to hang around in the object
model. It makes no sense to waste bandwidth downloading eg. handheld style
sheets that don't get applied in any reasonable real-world use case for the
normal builds of Mozilla. 

Isn't the whole point of declaring the applicable media types at the <link>
level as opposed to the at-rule level that the UA can omit downloading the style
sheets that don't get used? 

I would like to offer media="handheld" style sheets for the Series 60 version of
Opera but I wouldn't want to make Mozilla download unnecessary HTTP objects.

Comment 9

[Hixie (not reading bugmail)]

bz: Can't you make the OM block-on-read? i.e., only download what you need,
then, if script tries to access a disabled/non-applicable/unselected stylesheet,
block the script while you load the sheet then resume the script once you have
the file loaded.

Comment 10

[Boris Zbarsky [:bzbarsky]]

Blocking a script blocks the entire Mozilla UI, remember? Yay smart design.

Henri, CaScadeS, for example, surely depends on all the stylesheets being loaded
so that you can load all of them.  So there are definitely cases when the CSSOM
needs access to all sheets associated with a page...

Comment 11

[Hixie (not reading bugmail)]

bz: Well can the JS guys fix that?

Comment 12

[Boris Zbarsky [:bzbarsky]]

Back in 1998, maybe.  The problem is that _chrome_ js/DOM/layout need to happen
on the "ui thread".  And the DOM of a webpage is part of the chrome's DOM.

Oh, and if chrome JS accesses the CSSOM, we would be blocking the UI no matter
what if we block it.

Comment 13

[Hixie (not reading bugmail)]

Isn't JS interruptible?

JS script runs, calls into OM. OM tells JS to stop and yield. OM loads
stylesheet in background, waiting for load/fail event. At this stage, the UI is
responsive. Upon receiving the event, OM tells JS to resume.

Comment 14

[Boris Zbarsky [:bzbarsky]]

JS is not interruptible to my knowledge. I can only not return back into the JS
engine from the CSSOM call.  I _could_ throw my own event queue to process ui
events while the sheet loads (this is what alert() does, more or less).  There
are all sorts of issues with this, as rginda will testify (venkman's breakpoint
functionality took him forever to get sorta working).

Not to mention that we could have CSSOM access from C++ or python or whatever,
not just JS.  So depending on properties of JS is not acceptable.

Oh, and throwing my own event queue is _really_ messy in an embedding situation.

Comment 15

[Brendan Eich [:brendan]]

Hixie, the JS engine is not interruptible in general, because it uses C stack
space for state.  That could be fixed at some cost, but even then the callers
into the JS engine, which include things like plugins, including Java, would
need to be interruptible.  The NS_INTERRUPTED return code would become a virus
infecting most of the codebase.

The alternative bz alludes to, threading, is more easily done within the JS
engine (it has been threadsafe for at least six years), but not easily done
within Gecko.

If Gecko were sufficiently reentrant, the native JS method that wants to block
could conceivably nest a non-modal event loop.  But all JS authors would have to
know that they were giving up their invariants by getting or setting CSSOM
properties.  That's a big change from the run-to-completion execution semantics
that JS-in-the-browser has purveyed for almost eight years.

Regarding bz's latest comment, the point about language neutrality: the only
language-neutral execution model that I know of is a least-common-denominator
thread system, _a la_ NSPR.  But Gecko is not nearly ready for multi-threading
(meaning, the payoff isn't there, and the cost in effort is large, and the
opportunity cost is high too, in view of things Gecko experts can fix instead).

/be

Comment 16

[Brendan Eich [:brendan]]

I should have written "the only language-neutral execution model supporting some
kind of concurrency that I know of".  Obviously, some languages support
coroutines intimately, and NSPR user-level threads are implemented using
setjmp/longjmp or similar coroutine primitives, and a preemption signal on Unix
for scheduling.

Anyway, the point is that if you have a large system with embeddable third party
code, you don't want to dictate things like manual state save/restore from
control blocks in each module (NS_INTERRUPTED).  Dictating thread safety in the
face of preemption and SMP races is hard, too, which is why only a few modules
such as JS (which is used in multi-threaded servers) have bothered with it.  No
free lunch.

/be

Comment 17

[Hixie (not reading bugmail)]

Yeah, I thought you might say that. :-)

I was looking in Bugzilla for a discussion we (bz and I) had had a few
weeks/months ago about this, where I seem to recall we'd decided that the
objects representing unloaded sheets would raise exceptions (?) or return null
(?). I'm not sure which exactly. But I can't find it.

Comment 18

[Boris Zbarsky [:bzbarsky]]

One other option would be to defer sheets loads for media we do not support just
like we defer alternate sheet loads..... Not sure what that would help, though,
especially once we stop blocking the parser for this stuff.

Comment 19

[Hixie (not reading bugmail)]

Well we should probably do that anyway.

This will all become even more amusing when we implement CSS3 Media Queries...

Comment 20

[Boris Zbarsky [:bzbarsky]]

Perhaps the WG should address the expected behavior here as it works on the
CSSOM?  :)

Most importantly, how does one tell apart sheets being loaded so that they will
apply to the page and sheets being loaded so that they can be modified and then
saved?

Comment 21

[Hixie (not reading bugmail)]

Yeah, I'll have to remember to bring that up when the OM is under consideration.

How do you tell if you should apply a stylesheet anyway? Just apply that
algorithm to work out if you are going to apply it when it is loaded...

See also bug 84582.

Comment 22

[Boris Zbarsky [:bzbarsky]]

Um... right now we tell whether we plan to apply a stylesheet in the style
resolution code itself.  More importantly, whether a sheet is applied is a
property of the presentation (printing/screen/whatever) whereas the sheet data
being loaded and especially the CSSOM (computed style excluded) are properties
of the document object (which is presentation-independant).

For reference, we _do_ load a document specified by the "src" of an <iframe>
with display:none -- and we do this because there was great demand for it from
the web developer community.  This case seems pretty similar to me.

Comment 25

[Ioana (away)]

Is this still an issue? The linked page doesn't contain both stylesheets anymore, so I can't verify that.

Comment 26

[mirco.andreon]

Is this still open? I'm experiencing very bad performances in page loads when I use my mediawiki site on Firefox (on IE and Chrome it is fast).

Comment 27

[Boris Zbarsky [:bzbarsky]]

> Is this still open?

Yes.  The current behavior is pretty much required by specs.

> I'm experiencing very bad performances in page loads when I use my mediawiki site on Firefox

Can you please file a separate bug with a link and steps to reproduce?

Comment 28

[j.j.]

is this fixed by bug 1386840?

Comment 29

[Boris Zbarsky [:bzbarsky]]

Not as filed.  We deprioritize the loads, but we still do them.

Comment 30

[Andrew McCreight [:mccr8]]

(In reply to Boris Zbarsky [:bzbarsky, bz on IRC] from comment #27)

Can you please file a separate bug with a link and steps to reproduce?

Looks like no.

Comment 31

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S4. However, the bug has 12 votes.
:emilio, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 32

[Emilio Cobos Álvarez (:emilio)]

This behavior matches all browsers and people rely on this to asynchronously load CSS, but we delay loading non-matching media queries and don't block rendering on them.