https://bugzilla.wikimedia.org/show_bug.cgi?id=47277

Krinkle <krinklem...@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #5 from Krinkle <krinklem...@gmail.com> ---
There is two things that inflate the number of stylesheets in debug mode:

* unversioned module styles loaded via OutputPage::addModuleStyles each get
their own <link rel=stylesheet>

* regularly loaded modules constructed by ResourceLoaderFileModule (as opposed
to DataModule or WikiModule) via mw.loader.load will get their .js and .css
files loaded raw from disk.

An item not in this list is regular styles for the majority of modules. Both in
debug mode and production mode, each module gets its own <style> tag as it
arrives from the server (we don't keep appending to the same <style> tag, not
even in production mode, as doing so is significantly more expensive and
visibly worsens client-side performance, per bug 45810). 

However in IE9 and below we do resort to recycling the same <style> tag again
and again because of the IE stylesheet limit (bug 31676).

The only place where we actually concatenate stylesheets on the server side
(and naturally, the only place that doesn't concatenate them in debug mode) is
unversioned skin styles loaded through OutputPage::addModuleStyles.

(The regular ResourceLoader module requests are also concatenated, but as JSON,
not as css text.)

It is limited to debug mode (which we plan to get rid of since it has almost
become obsolete and full of bugs that don't happen in production; the few use
cases left for browsers without support for source maps or developer tools
"prettify" source, can be addressed in better ways).

And aside from being a use case that isn't worth upsetting stuff all over the
place for (IE9 and below, only debug mode), even if we would want to fix this,
we'd have no way to do so. Resorting to browser sniffing server side is not
acceptable per current Wikimedia operations status quo, and conditioning it
client side is not acceptable per the very nature of these requests being for
basic styles before javascript.

Also let me reiterate that addModuleStyles should be used very sparingly. Often
do I find uses of it that are "wrong" due to developers overusing it thinking
they deserve the special priority treatment (and backfiring with a performance
regression as a result). It is by design a hack and circumvents all principles
of ResourceLoader. It is there for basic skin styles and should never get
anywhere near 20 modules, even on large installs like Wikipedia.

---

So how do we debug IE9 and below? Well, for starters, don't use the "debug"
mode (this needs no justification, since per this bug, debug mode is broken).

Secondly, as minified as things may be, the error message and originating
request should contain enough identifiers for a MediaWiki developer to figure
out the source of a problem. It will be harder to trace, but it'll have to do.

Once the problem can be reproduced outside your production site, one can
reproducing it on a local MediaWiki install and, if you need the exact line
number, manually disable minification there (add `return $data;` in
ResourceLoader::filter).


-- 

Closing as WONTFIX, but if anyone has an idea of tackling, I'd be happy to hear
it :)

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

Reply via email to