Wikimedia Bugzilla is closed!

*** Bug 41402 has been marked as a duplicate of this bug. ***

Although it is a valid bug that MobileFrontend's beta shouldn't activate RL mode on wikis that haven't been updated to the latest wmf branch yet (which includes "target" in RL) - part of this is due to bug 41340.

None of the exceptions thrown are related to the script not supporting "mobile", they are thrown due to the currently RL-implementation being incomplete or broken (see bug 41340).

No.. the problem I am raising here is that if a version of MediaWiki is run which has a ResourceLoader that does not support the target property - the mobile site will receive all javascript from the desktop site including gadgets.

The issue here is that gadgets that __haven't__ specified themselves as mobile friendly are being loaded when they shouldn't be.

This is going to be a problem going forward. Although this particular exception can be fixed by solving bug 41340, gadgets that expect certain elements that do not exist on mobile could potentially break.

I am proposing we do the following:

if ( ResourceLoader supports target property ) {
useResourceLoader();
} else {
useMockMw();
}

We should probably set $wgMFEnableResourceLoader = false in the meantime; this will disable the partial RL enabling since we don't yet need it on wmf2 wikis and it's broken on wmf1 wikis.

(In reply to comment #3)
> No.. the problem I am raising here is that if a version of MediaWiki is run
> which has a ResourceLoader that does not support the target property - the
> mobile site will receive all javascript from the desktop site including
> gadgets.
> 

No no, yes! We are saying exactly the same thing.

Both wmf branches were updated with the latest version of MobileFrontend, but only the latest wmf branch is branched from MediaWiki after 'target' was implemented. As a result load.php?modules=startup&target=mobile on older wikis loads all modules (the 'target' parameter is ignored as it doesn't exist yet in the old mediawiki version).

I didn't mean to suggest that bug 41340 should be fixed to solve this problem (I would've marked it as a dependency in that case).

I'm merely trying to clarify that the fact that those gadgets throw exceptions for Geo, wgPageName and mw.config etc. is not related to the fact that it is an older version of ResourceLoader but due to bug 41340.

Having said that, lets rewind:
(In reply to comment #0)
> Go to
> http://pt.m.wikipedia.org/wiki/Wikipédia:Accueil%20principal?title=Wikipédia:Accueil_principal&mobileaction=toggle_view_mobile
> 
> It throws an exception due to a gadget.
> 

It throws an exception due to bug 41340. And (obviously) this bug is not gadgets related, various core and extension modules are equally failing due to the incompatible environment.

> Brion suggested this might be due to the fact that the mediawiki core on this
> box has not been updated.
> 
> Possibly we should be feature detecting whether ResourceLoader has support for
> target before adding javascript as it's possible we could break backwards
> compatibility on various wiki sites.

(In reply to comment #3)
> [..]
> 
> I am proposing we do the following:
> 
> if ( ResourceLoader supports target property ) {
> useResourceLoader();
> } else {
> useMockMw();
> }

I'd recommend instead to simply not deploy the latest MobileFrontend master on older wikis. It is a reasonable requirement that the latest 'master' head of an extension requires the latest 'master' head of mediawiki/core.

When there are breaking changes in master, extensions are updated and deployed at the same time.

When a wmf-branch is created this link is fixed, and during the 2-week period various core updates and extension updates are backported. We shouldn't fast-forward extensions in the older wmf-branches unless there are critical updates. And in that case we make a wmf-branch in the extension repo, cherry-pick the fix to there, and update the mediawiki/core wmf-branch to that revision.

Basically the same as in the svn days.

Ahh I see
Sorry about that - I wrote the original comment in haste so that wasn't clear.

Is there a way to make MobileFrontend throw an exception when there is not target ResourceLoader support?

I'm worried that people will install latest MobileFrontend to older mediawiki instances and moan that it is broken. I'm keen to leave no ambiguity.

(In reply to comment #6)
> Ahh I see
> Sorry about that - I wrote the original comment in haste so that wasn't clear.
> 
> Is there a way to make MobileFrontend throw an exception when there is not
> target ResourceLoader support?
> 
> I'm worried that people will install latest MobileFrontend to older mediawiki
> instances and moan that it is broken. I'm keen to leave no ambiguity.

The basic version_compare() we always use should be fine. Require at least 1.21alpha in the master branch of MobileFrontend.

People should always use extensions from the same version as their mediawiki version, and if not, extensions can choose to fail randomly or throw early with a version_compare.

Then the only fail scenario is people running a before-last-week MediaWiki 1.21alpha with this-or-after-this-week MobileFrontend, in that case I'd say a note in the documentation should suffice. The kind of people running those alpha installs may be expected of that they read documentation before deployment and/or don't run it in production.

I'd rather use something like method_exists( 'ResourceLoaderModule', 'getTargets') -- this will protect against the case we had where one 1.21alpha had the feature and another one didn't.

Config change to temporarily disable this feature until we improve the detection and fix it:

https://gerrit.wikimedia.org/r/#/c/30070/

THis is fixed now that all wikis in production are using updated code.