Special pages and edit pages bypass the cache so not sure what this gains us.

(Also with RL not sure if this is an issue any more)

MaxSem: jdlrobson, I'm not sure 44017 is 100% resolved - I'd rather close it when we switched to OutputPage linking, which supports module groups

jgonera wrote:

Jon, this is about browser cache. Unless people disable cache in their browsers, special and edit pages use it.

I had a go
https://gerrit.wikimedia.org/r/52577

https://gerrit.wikimedia.org/r/52577 (Gerrit Change I688128038a2e9366a4dca4bdf52dcbfcc548c0e0) | Code-Review: Reviewed:+2 Verified:+2 Patch Set 1: Verified+2 Code-Review+2

Doesn't seem to explode in my testing... [by com.google.gerrit.server.events.AccountAttribute@7c73eaa8]

https://gerrit.wikimedia.org/r/52577 (Gerrit Change I688128038a2e9366a4dca4bdf52dcbfcc548c0e0) | Patch Set 1: -Verified

Starting gate-and-submit jobs.
http://integration.mediawiki.org/zuul/status [by com.google.gerrit.server.events.AccountAttribute@2a4e2ecb]

Related URL: https://gerrit.wikimedia.org/r//r/gitweb?p=mediawiki%2Fextensions%2FMobileFrontend.git;a=commit;h=770f3e7f7261305cd48373cc136100d952b0e2e4 (Git: 770f3e7f7261305cd48373cc136100d952b0e2e4)

https://gerrit.wikimedia.org/r/52577 (Gerrit Change I688128038a2e9366a4dca4bdf52dcbfcc548c0e0) | change APPROVED and MERGED [by com.google.gerrit.server.events.AccountAttribute@775e9138]

https://gerrit.wikimedia.org/r/52577 (Gerrit Change I688128038a2e9366a4dca4bdf52dcbfcc548c0e0) | Patch Set 1:

Build successful

• http://integration.mediawiki.org/ci/job/mwext-MobileFrontend-merge/1855/console : SUCCESS
• http://integration.mediawiki.org/ci/job/mwext-MobileFrontend-jslint/1714/checkstyleResult/ : SUCCESS (non-voting)
• http://integration.mediawiki.org/ci/job/mwext-MobileFrontend-lint/1856/console : SUCCESS
• http://integration.mediawiki.org/ci/job/mwext-MobileFrontend-testextensions-master/457/console : SUCCESS [by com.google.gerrit.server.events.AccountAttribute@7e8b3874]

jgonera wrote:

I think I haven't explained well enough what this bug is about.

Go to https://en.m.wikipedia.org/
There's only one <link> tag to styles:
https://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=mobile.styles&only=styles&skin=mobile&*

Now go to Settings, there's again only one <link> tag, *but* it's different:
https://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=mobile.styles%7Cmobile.mobileoptions.styles&only=styles&skin=mobile&*

What does this mean? Settings page loads additional styles, but it also certainly uses some of the styles from the main page. *But* instead of reusing the browser cache and using the CSS requested on the main page:

https://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=mobile.styles&only=styles&skin=mobile&*

*and* adding its own styles in a *separate* <link> tag, it just issues a request that fetches everything together.

This way, we keep reloading (re-requesting) CSS that already is in browser cache instead of reusing it because every <link> tag issues a request for the *entire* CSS of MobileFrontend (+ sometimes page-specific CSS) on every page.

Yes.. and this is what the above patch does..
If you try out master on a local machine you'll notice two link tags for css files.

On local copy of master I see these urls on Special:MobileOptions:

• http://localhost/w/load.php?debug=false&lang=en&modules=mobile.styles&only=styles&skin=mobile&*

• http://localhost/w/load.php?debug=false&lang=en&modules=mobile.mobileoptions.styles&only=styles&skin=mobile&*

On the main page I see (currently incorrectly 2 urls) but they are:

• http://localhost/w/load.php?debug=false&lang=en&modules=mobile.styles&only=styles&skin=mobile&*

• http://localhost/w/load.php?debug=false&lang=en&modules=&only=styles&skin=mobile&*

The latter is empty and shouldn't be added. That was an oversight on my part (as I've been refactoring css to make sure this is never empty - https://gerrit.wikimedia.org/r/52577 )