This commit implements step 4 and step 5 of the plan outlined at T192623.
Before this task began, the typical JavaScript execution flow was:
* HTML triggers request for startup module (js req 1).
* Startup module contains registry, site config, and triggers
a request for the base modules (js req 2).
* After the base modules arrive (which define jQuery and mw.loader),
the startup module invokes a callback that processes RLQ,
which is what will request modules for this page (js req 3).
In past weeks, we have:
* Made mediawiki.js independent of jQuery.
* Spun off 'mediawiki.base' from mediawiki.js – for everything
that wasn't needed for defining `mw.loader`.
* Moved mediawiki.js from the base module request to being embedded
as part of startup.js.
The concept of dependencies is native to ResourceLoader, and thanks to the
use of closures in mw.loader.implement() responses, we can download any
number of interdependant modules in a single request (or parallel requests).
Then, when a response arrives, mw.loader takes care to pause or resume
execution as-needed. It is normal for ResourceLoader to batch several modules
together, including their dependencies.
As such, we can eliminate one of the two roundtrips required before a
page can request modules. Specifically, we can eliminate "js req 2" (above),
by making the two remaining base modules ("jquery" and "mediawiki.base") an
implied dependency for all other modules, which ResourceLoader will naturally
fetch and execute in the right order as part of the batch request.
Bug: T192623
Change-Id: I17cd13dffebd6ae476044d8d038dc3974a1fa176
They are slow and spammy, especially given in modern browsers
console.warn() already provides a trace (and one that is collapsed
by default in Chrome, which seems preferred).
Change-Id: I94d3c7bf6deb47c2f3f660dfd2298ee293e7d825
This patch was merged upstream and is no longer a local patch
since 2e2ac756e7 upgraded us to jQuery Migrate 3.0.1.
I mistakenly kept this comment when re-applying our patches.
Change-Id: Id5fa8c03bc5791971a6406376ca8abf5503268f6
Some migrateWarn() calls (like the one for compatMode) happen before
mw is created. Don't crash on trying to call mw.track() in that case.
Change-Id: I9e33af2865bb10adc0473045f714fe4f9f699861
Inspired by cb20b5aa5a, which added similar instrumentation
during the jQuery 1.11 migration for MediaWiki in 2014.
This way we can plot overall usage in a Grafana dashboard and
help us track the progres of the on-going migration.
Bug: T124742
Change-Id: Ifab13d52d5681189cfb2faae342373558369b8c0
Highlights:
* Event: Warn and fill jQuery.event.props.concat
> Adds back-compat for a removed property. (Undocumented)
> This makes jQuery 3 compatible with jQuery Mobile pre-1.5
* Effects: Warn on use of jQuery.fx.interval
> Adds detection for a deprecated property.
* Event: Warn about late use of $(window).on("load"...)
* Data: Fix support for object as second argument
> Fixes minor regression that jQuery Migrate introduced
> over jQuery 3.0 plain.
* Docs: Clarify wording around deprecated/removed methods
> Avoids confusion between whether a method was removed
> in jQuery 3, or merely deprecated.
Full change log:
https://github.com/jquery/jquery-migrate/compare/3.0.0...9e3dfcb
Also re-apply and document hot patch from a77525e56a.
Bug: T124742
Change-Id: Ia55b6aad1648667648cc511eddea12b808d7e898
jQuery Migrate has to monkey-patch jQuery.Deferred, but in doing so
it also effectively disables exceptionHook, which means exceptions
are no longer logged to the console.
<https://github.com/jquery/jquery-migrate/pull/262>
Bug: T168086
Change-Id: Id46abcc7fb5e65954532b114636bf0f1f000a551
Source code:
https://code.jquery.com/jquery-3.2.1.jshttps://code.jquery.com/jquery-migrate-3.0.0.js
Documentation:
https://blog.jquery.com/2016/06/09/jquery-3-0-final-released/https://jquery.com/upgrade-guide/3.0/
This is not a breaking change because jQuery Migrate covers
all breaking changes.
However some extensions (especially unit tests) may've relied
on undocumented behaviour. For that reason, and due to unresolved
upsteam issues this is still behind a feature flag for now.
It is true by default to ensure this has wide exposure to discover
issues as quickly as possible. If this is not resolved before
the end of the 1.29 release cycle it should be turned off again.
Bug: T124742
Change-Id: I3c3dedaa9a9d449eaa2b7e5d24b4540e7fa421c0
As indicated in MediaWiki 1.24, removing the jQuery Migrate bridging patch
that allows legacy Javascript code that depends ancient features of
jQuery removed in jQuery 1.9 to work.
Change-Id: I0934247182e2737716c9d40f4bf93415adcdadf3
Can't use mw.log.deprecate because many of these are fired
for specific behaviour within a method, not for access to the method
itself.
And mustn't fire the events with topic "mw.deprecate" as we can't satisfy
all the requires properties of that event schema (such as having a search
phrase to find offending code). These tracking hits would be for hit
counts only, not for finding where it comes from (we'll still have wikiid,
pagename, revision id and referral information from EventLogging though).
Change-Id: I6c868f2ce831d74889ed58b6ab4a69b233b3923f
We're currently on jQuery v1.8.3. jQuery v1.9 introduces breaking
changes. The jQuery Migrate plugin adds a compatibility layer
that brings back most removed or altered functionality.
It can also be loaded on an older version of jQuery to make use
of the plugins' accessor tracking that helps finding code
that makes use of the deprecated functionality prior to upgrading.
Code:
http://code.jquery.com/jquery-migrate-1.2.1.js
Info:
http://blog.jquery.com/2013/01/15/jquery-1-9-final-jquery-2-0-beta-migrate-final-released/http://jquery.com/upgrade-guide/1.9/#jquery-migrate-pluginhttps://github.com/jquery/jquery-migrate/
> The plugin can be included with versions of jQuery as old as
> 1.6.4 to identify potential upgrade issues via its JQMIGRATE
> console warnings. However, the plugin is only required for
> version 1.9.0 or higher to restore deprecated and removed
> functionality.
Loading it alongside jquery.js should be harmless. However to
benefit performance, I'm only loading it in debug mode.
Plus, there's a small chance that it does actually change
functionality because of the way it is implemented. The plugin
always overloads the methods with compatibility versions, which
should effectively be a no-op on top of old version of jQuery
like ours (one that already has the old functionality), but it
feels too risky at this stage when our only intent is
instrumentation.
Bug: 44740
Change-Id: I468d6b45eae8368fac6af746bbb2ccb702f862ff
