Persona is no longer an option for authentication on BMO. For more details see Persona Deprecated.
Last Comment Bug 79021 - All stylesheets are loaded regardless of rendering media
: All stylesheets are loaded regardless of rendering media
Status: NEW
(WG: how do interfaces appear if the ...
: perf, testcase-wanted
Product: Core
Classification: Components
Component: CSS Parsing and Computation (show other bugs)
: Trunk
: All All
: P5 minor with 12 votes (vote)
: Future
Assigned To: Nobody; OK to take it and work on it
: Jet Villegas (:jet)
: 436014 537674 (view as bug list)
Depends on: 84582
  Show dependency treegraph
Reported: 2001-05-05 06:05 PDT by Sampo Syreeni
Modified: 2013-07-29 05:12 PDT (History)
22 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description Sampo Syreeni 2001-05-05 06:05:41 PDT
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 2001-06-16 06:19:22 PDT
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 2001-06-18 01:45:22 PDT
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: - - [18/Jun/2001:11:28:54 +0300] "GET
/shared/style/dc-mono/dc-mono-11-aural-xstruct.css HTTP/1.1" 200 453 - - [18/Jun/2001:11:28:55 +0300] "GET
/shared/style/dc-mono/dc-mono-11-aural-xhtml.css HTTP/1.1" 200 1450 - - [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 2001-06-25 13:23:56 PDT
This sounds like a good idea to me. [rfe]

This should be considered at a future date.

MArking NEW. :-)
Comment 4 Pierre Saslawsky 2001-07-15 13:49:12 PDT
Marked dependency on bug 84582.
Comment 5 David Baron :dbaron: ⌚️UTC-7 (busy until November 7) 2002-06-19 21:12:48 PDT
Assigning pierre's remaining Style System-related bugs to myself.
Comment 6 Brant Gurganus 2002-10-13 11:29:28 PDT
[RFE] is deprecated in favor of severity: enhancement.  They have the same meaning.
Comment 7 Boris Zbarsky [:bz] (still a bit busy) 2003-05-03 22:12:05 PDT
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) (not reading bugmail or doing reviews until 2016-10-27) 2003-05-04 06:17:58 PDT
> 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) 2003-05-04 07:03:52 PDT
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 [:bz] (still a bit busy) 2003-05-04 08:15:01 PDT
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) 2003-05-04 08:53:05 PDT
bz: Well can the JS guys fix that?
Comment 12 Boris Zbarsky [:bz] (still a bit busy) 2003-05-04 09:12:02 PDT
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) 2003-05-04 09:17:48 PDT
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 [:bz] (still a bit busy) 2003-05-04 09:27:04 PDT
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] 2003-05-04 09:59:17 PDT
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).

Comment 16 Brendan Eich [:brendan] 2003-05-04 10:12:42 PDT
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.

Comment 17 Hixie (not reading bugmail) 2003-05-04 10:14:22 PDT
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 [:bz] (still a bit busy) 2003-05-04 10:17:27 PDT
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) 2003-05-04 10:21:25 PDT
Well we should probably do that anyway.

This will all become even more amusing when we implement CSS3 Media Queries...
Comment 20 Boris Zbarsky [:bz] (still a bit busy) 2003-05-04 10:33:48 PDT
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
Comment 21 Hixie (not reading bugmail) 2003-05-04 11:17:03 PDT
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 [:bz] (still a bit busy) 2003-05-04 11:24:00 PDT
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 23 Christian Schmidt 2009-06-11 06:44:26 PDT
*** Bug 436014 has been marked as a duplicate of this bug. ***
Comment 24 David Baron :dbaron: ⌚️UTC-7 (busy until November 7) 2010-05-01 09:13:20 PDT
*** Bug 537674 has been marked as a duplicate of this bug. ***
Comment 25 Ioana (away) 2013-07-29 04:35:19 PDT
Is this still an issue? The linked page doesn't contain both stylesheets anymore, so I can't verify that.

Note You need to log in before you can comment on or make changes to this bug.