Page MenuHomePhabricator

User js not getting invalidated without debug=false
Closed, ResolvedPublic

Description

I recently introduced some css to User:Jdlrobson/minerva.css

As you can see now my user css is empty and was last edited 4 hours ago, but clearly the css is still being applied (indicated by green/red boxes around elements)

( for reference http://en.m.wikipedia.beta.wmflabs.org/wiki/User:Jdlrobson/minerva.css )

I suspect this is a bug in how ResourceLoader caching works.

the module providing this functionality is ResourceLoaderUserModule which only overrides getPages:
http://git.wikimedia.org/blob/mediawiki%2Fextensions%2FMobileFrontend.git/8ef371ec32184938fe11718be377dd4636a113dd/includes%2Fmodules%2FMobileUserModule.php

Would appreciate ResourceLoader expertise. I can replicate this on production too.

Event Timeline

Jdlrobson raised the priority of this task from to Needs Triage.
Jdlrobson updated the task description. (Show Details)
Jdlrobson moved this task to Incoming on the Readers-Web-Backlog board.
Jdlrobson added a subscriber: Jdlrobson.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJun 15 2015, 9:59 PM

This is probably because you're using addModules and not addModuleStyles/addModuleScripts which have special handling for the cache invalidation of user modules.

Change 218552 had a related patch set uploaded (by Jdlrobson):
Don't mess with the cache

https://gerrit.wikimedia.org/r/218552

Change 218552 merged by jenkins-bot:
Don't mess with the cache

https://gerrit.wikimedia.org/r/218552

phuedx closed this task as Resolved.Jun 18 2015, 3:39 PM
phuedx claimed this task.
Jdlrobson reopened this task as Open.Jul 16 2015, 10:22 AM

This has not been fixed apparently..

Jdlrobson removed phuedx as the assignee of this task.Jul 29 2015, 11:25 PM
Jdlrobson removed a project: Patch-For-Review.
Jdlrobson moved this task from 2017-18 Q3 to 2016-17 Q2 on the Readers-Web-Backlog board.
Krinkle added a subscriber: Krinkle.EditedJul 29 2015, 11:54 PM

Indeed. Using addModules() means the modules are requested through mw.loader.load() which builds the load.php url based on version information from the startup module which is shared with all users. That version will not change when you change your own user script because the general "user" module implementation hasn't changed.

This is why user-specific modules are always embedded as their own load.php request with a version directly in the html so that invalidation happens directly for the user (since you get your own version string directly in the html). And this also improves caching by providing a url with a "version" that can be cached by the browser.

The current way of loading the user module in MobileFrontend is not supported and works by accident.

As @Legoktm pointed out, using addModuleStyles/addModuleScripts instead should mitigate this. Be sure to verify this by looking at the generated html output and looking for a <link> and <script src> for load.php..modules=user..only=styles and only=scripts respectively.

@Legoktm @Krinkle could you point me to where it gets added in core. Somethings not quite right. When I use addModuleScripts it is not appearing on the page :-S

It'll be in the page footer, the relevant code is in OutputPage::getScriptsForBottomQueue().

Jhernandez triaged this task as Low priority.Aug 13 2015, 7:15 PM
Restricted Application added a project: Readers-Web-Backlog. · View Herald TranscriptAug 13 2015, 8:51 PM

@Legoktm @Krinkle the more I think about this I wonder if we should just enable common.css and common.js on mobile. This will cause breakage for some users, but might be a worthy exercise to identify for users to revisit their common.js scripts - what would be a responsible way to do this, given that some libraries are not available and some DOM elements that might be expected do not exist in the page?

I don't see what that has to do with this bug? Probably should be split into a separate bug since it's a different issue.

MobileFrontend currently uses its own separate user module which as this bug states has cache validation issues.
If we want this to stay separate we'd have to refactor core functions or do some nasty hijacking.
So actually not using this module would be another possible simpler solution to this bug. I'd rather clarify that we are doing the right thing by having a separate module before investing the time in fixing this bug.

Oh, you meant User:Foo/common.js and not MediaWiki:Common.js. Yeah, that makes sense and sounds reasonable.

But the fix for this bug is pretty trivial...

The concept is already generalised and is working fine for the "user", "user.groups", and "ext.globalCssJs.user" modules. Mobile can just do the same.

Jdlrobson added a comment.EditedAug 24 2015, 7:41 PM

I see I need to be less vague here as I'm not getting myself understood.
There are two options

  1. Mobile uses 'user' module. We break stuff
  2. Mobile continues to use 'mobile.user' code, and either duplicates code in core to do so or makes core code more general.

For complete clarity..
The existing code is here:
http://git.wikimedia.org/blob/mediawiki%2Fcore.git/634ec8dc1e918aaee72e2227dfb443040dffcba6/includes%2FOutputPage.php#L3089

if mobile continues to use a mobile.user module rather than the user module L3103 will need to change to allow us to register other custom modules - it is not generalised in that respect.
http://git.wikimedia.org/blob/mediawiki%2Fcore.git/634ec8dc1e918aaee72e2227dfb443040dffcba6/includes%2FOutputPage.php#L3103

I'm asking if this is the preferred route or we should just make mobile use the same mechanism as core... the side effect of this is some user's mobile experience will break due to common.js modules not working on the mobile site.

I'm hoping this is clear as possible.
What am I misunderstanding if anything?

Change 233653 had a related patch set uploaded (by Legoktm):
Have mobile.usermodule cache invalidate properly

https://gerrit.wikimedia.org/r/233653

Legoktm claimed this task.Aug 25 2015, 2:37 AM

There are two options

  1. Mobile uses 'user' module. We break stuff

Yes, that is an option. A bit out of scope for this bug though.

  1. Mobile continues to use 'mobile.user' code, and either duplicates code in core to do so or makes core code more general.

Or... 3) Do what I suggested back in June aka https://gerrit.wikimedia.org/r/233653

The existing code is here:
http://git.wikimedia.org/blob/mediawiki%2Fcore.git/634ec8dc1e918aaee72e2227dfb443040dffcba6/includes%2FOutputPage.php#L3089
if mobile continues to use a mobile.user module rather than the user module L3103 will need to change to allow us to register other custom modules - it is not generalised in that respect.
http://git.wikimedia.org/blob/mediawiki%2Fcore.git/634ec8dc1e918aaee72e2227dfb443040dffcba6/includes%2FOutputPage.php#L3103

No, it doesn't need any change. This code hardcodes "user" but that's only to implement the excludepage behaviour for live preview. The way the user module is loaded by OutputPage (e.g. parameters to makeResourceLoaderLink) is not special and exactly the same as what OutputPage does for any other group=user modules added via addModuleStyles/addModuleScripts by extensions. As example, the cache behaviour is working fine for ext.globalCssJs.user.

Change 233653 merged by jenkins-bot:
Have mobile.usermodule cache invalidate properly

https://gerrit.wikimedia.org/r/233653