All stylesheets are loaded regardless of rendering media




18 years ago
11 months ago


(Reporter: decoy, Unassigned, NeedInfo)


({perf, testcase-wanted})

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


(Whiteboard: (WG: how do interfaces appear if the sheet isn't loaded yet), )



18 years ago
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.
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.
Last Resolved: 18 years ago
Resolution: --- → WORKSFORME

Comment 2

18 years ago
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.
Resolution: WORKSFORME → ---

Comment 3

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

This should be considered at a future date.

MArking NEW. :-)
Ever confirmed: true
Summary: All stylesheets are loaded regardless of rendering media → [rfe] All stylesheets are loaded regardless of rendering media

Comment 4

18 years ago
Marked dependency on bug 84582.
Depends on: 84582
Keywords: perf
Target Milestone: --- → Future
Assigning pierre's remaining Style System-related bugs to myself.
Assignee: pierre → dbaron
Priority: -- → P3

Comment 6

17 years ago
[RFE] is deprecated in favor of severity: enhancement.  They have the same meaning.
Severity: minor → enhancement
Severity: enhancement → minor
Summary: [rfe] All stylesheets are loaded regardless of rendering media → All stylesheets are loaded regardless of rendering media
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...
Keywords: qawanted
> 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.
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.
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...

bz: Well can the JS guys fix that?
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.
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.
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.
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).

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.

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.
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.
Well we should probably do that anyway.

This will all become even more amusing when we implement CSS3 Media Queries...
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
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.
Whiteboard: (WG: how do interfaces appear if the sheet isn't loaded yet)
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.


16 years ago
OS: Windows NT → All
Hardware: PC → All
Assignee: dbaron → nobody
QA Contact: ian → style-system


10 years ago
Duplicate of this bug: 436014

Comment 25

6 years ago
Is this still an issue? The linked page doesn't contain both stylesheets anymore, so I can't verify that.
Keywords: qawanted


6 years ago
Keywords: testcase-wanted

Comment 26

2 years ago
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).
> 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?
Flags: needinfo?(mirco.andreon)

Comment 28

11 months ago
is this fixed by bug 1386840?
Not as filed.  We deprioritize the loads, but we still do them.
You need to log in before you can comment on or make changes to this bug.