| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 2e2ac756e7224 upgraded us to jQuery Migrate 3.0.1.
I mistakenly kept this comment when re-applying our patches.
Change-Id: Id5fa8c03bc5791971a6406376ca8abf5503268f6
|
| |
|
|
|
|
|
|
|
| |
* Fixes IE9 issues with console.log.
* Add warning for $.fn.hover().
* Add warning for $.holdReady().
* Improve handling of jQuery.easing methods.
Change-Id: I38084ac6367b6d2ba47d6ecc6c9934a8bb7d8ae0
|
| |
|
|
|
|
|
|
|
| |
jquery.migrate
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 cb20b5aa5a68d, 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 a77525e56ac1a.
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.js
https://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-plugin
https://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
|
