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.

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.

This sounds like a good idea to me. [rfe] This should be considered at a future date. MArking NEW. :-)

Marked dependency on bug 84582.

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

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

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...

> 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). /be

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

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 saved?

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.

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.

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

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?

is this fixed by bug 1386840?

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