Benefits:
* Full per-language icons support. Icons that differ for each language
(such as the 'Bold' icon) will now always display correctly
according to user interface language, even on old browsers.
* MediaWiki UI icons support. When the 'mediawiki.ui.icon' module is
loaded, you can use syntaxes such as below to display any OOUI icons
(from the packs that were loaded) without involving OOUI itself.
<div class="mw-ui-icon mw-ui-icon-before mw-ui-icon-check">OK</div>
<div class="mw-ui-icon mw-ui-icon-after mw-ui-icon-check">OK</div>
<div class="mw-ui-icon mw-ui-icon-element mw-ui-icon-check">OK</div>
Summary of changes:
* Resources.php:
* Remove icons CSS files. Include image data JSON files instead.
* Split the images from 'oojs-ui.styles' module to separate ones.
* OutputPage: Update enableOOUI() method for newly split modules.
* ResourceLoaderImageModule: Make it possible to load image data from
a JSON file.
* update-oojs-ui.sh: Copy source files rather than distribution for
icon packs.
This is not an improvement when it comes to code quality, though :(
Issues include some nasty code duplication, using "source code" (image
definitions) from OOUI rather than just distribution files, and hacky
methods to load image data from JSON files live.
Bug: T92551
Change-Id: Id369ecaec7048dcf68ba1e4df748362760533782
Changing 'window.jQuery && jQuery.ready()' to 'if ( window.jQuery )
jQuery.ready()' means no *<![CDATA[*/ /*]]>* is required (because we
got rid of the ampersands). It's also more readable and more consistent
with if(window.mw).
Change-Id: I28262efb978c085e732b40f9dc5ddb1bda5c4376
Someone could theoretically try to hide malicious code in their user
common.js and then trick an admin into previewing it by asking for help.
Bug: T85855
Change-Id: I5a7a75306695859df5d848f6105b81bea0098f0a
The patch did not improve performance. I'd like to think that the increased
control over when inline scripts are executed makes the patch worthwhile
regardless, but that is post hoc justification and possibly a bit of personal
ego. Krinkle agrees that we may use some of the ideas in this patch in the
future but he thinks we're better off not heading down this path before we
have a better sense of where we're going, and I trust his judgment.
This reverts commit e86e5f8460.
Change-Id: I151f74a41dd664b5a0aa5cfd99fcc95e2686a1e6
The current ordering of scripts and stylesheets in <head> causes all major
browsers to serialize and defer requests that could be performed in parallel.
The problem is that external stylesheets are loaded before inline scripts. As
Steven Souders explains, "all major browsers preserve the order of CSS and
JavaScript. The stylesheet has to be fully downloaded, parsed, and applied
before the inline script is executed. And the inline script must be executed
before the remaining resources can be downloaded. Therefore, resources that
follow a stylesheet and inline script are blocked from downloading."[1]
In other words: the browser could start loading body images, but it refuses to
do that until it has executed inline scripts in head. And it refuses to execute
those scripts until the external CSS is downloaded, parsed and applied. You can
see the effect of this in this image, showing the request waterfall for
[[en:Gothic Alphabet]]: [2]. Notice how no images were requested before the
browser had finished processing the three load.php requests at the top.
To fix this, we want to move the inline scripts above the external CSS. This is
a little bit tricky, because the inline scripts depend on mw.loader, which is
loaded via an external script. If we move the external script so that it too is
above the external stylesheet, we force the browser to serialize requests,
because the browser will not retrieve the external CSS until it has retrieved
and executed the external JS code. So what we want is to move the inline
scripts above the external stylesheet, but keep the external script (which the
inline scripts depend on) below the external stylesheet.
We can do this by wrapping the inline script code in a closure (which binds
'mw') and enqueuing the closure in a global array which will be processed by
the startup module at just the right time.
Net result: external CSS and JS is retrieved in parallel, retrieval of images
(and other external assets) is unblocked, but the order in which code is
evaluated remains the same.
[1]: <http://www.stevesouders.com/blog/2009/05/06/positioning-inline-scripts/>
[2]: <http://people.wikimedia.org/~ori/enwiki-waterfall.png> (excerpted from
<http://www.webpagetest.org/result/150316_0C_7MB/1/details/>.
Change-Id: I98d383a6299ffbd10210431544a505338ca8643f
Replace spaces by underscore to build correct links to wiki pages. IE11
will show %20 for spaces. Also use urlencode to make the url safe.
Follow-Up: I2934b1708a0d207dcf3d940264f140613646f203
Change-Id: I5ef08441406e96aa9749476af0a81fc11fa4e4d6
Follows-up 9d390a09cd. It already wraps the only=script requests
for 'site' and 'user', but forgot about 'user.groups' which is
not 'scripts' but 'combined' (as regular module requests).
That request responds with mw.loader.implement whih will be absent
if the environment is unsupported.
With normal module requests, this is naturally covered by those
requests not being fired from mw.loader in the first place but
with hardcoded requests like these the condition wrap with
document.write is unfortunately required in the current reality.
Change-Id: Ib3a7378d0c44e601760fbbc5174da09bd7b7f492
All the chosen targets are translatable public domain help pages
on MediaWiki.org. Mostly special pages and actions for privileged
users for now.
Adapted from the Translate extension, credit to Niklas Laxström
(TranslateUtils::addSpecialHelpLink).
Depends on 6f5b29ff4e, whose commit
message has a typo addIndicator() instead of setIndicator().
Bug: T45591
Change-Id: I2934b1708a0d207dcf3d940264f140613646f203
Xhprof generates this data now. Custom profiling of various
sub-function units are kept.
Calls to profiler represented about 3% of page execution
time on Special:BlankPage (1.5% in/out); after this change
it's down to about 0.98% of page execution time.
Change-Id: Id9a1dc9d8f80bbd52e42226b724a1e1213d07af7
Add an 'export' subpage to SpecialJavaScriptTest which allows
one to request a self-sufficient JavaScript payload that will
bootstrap a ResourceLoader client and load the test suites.
This is needed for using Karma (which only loads JavaScript,
no full html pages). As such elements from the Skin and OutputPage
will not exist. While all QUnit tests in MediaWiki core and
most extensions I've seen already use #qunit-fixture, this is
now required. This to prevent leakage of elements from one
test to another, but it also prevents tests from depending
on elements provided by the server.
While the Karma setup is still in the pipeline (might land before
this commit loses WIP status), for now this can be tested via
the 'Special:JavaScriptTest/qunit/plain' subpage.
Refactor:
* Use HTTP status code 404 in the response for "noframework".
* Simplify HTML footprint by using <div id="qunit"> instead of
hardcoding the full structure. This feature was added to QUnit
since v1.3.0 (Feb 2012), we're using v1.14.0 (Jan 2014).
QUnit's header is automatically derived from document.title.
* Remove redundant addModules() for 'test.mediawiki.qunit.testrunner'.
This is already added by default.
* Move allowClickjacking() call so that it applies to other modes
as well. The exported javascript needs to have wgBreakFrame set
to false so that test runners can frame it.
* Change mediawiki.special.javaScriptTest to not depend on QUnit.
It caused QUnit to load on error pages. And in theory the page
is suited for other frameworks and shouldn't load QUnit this way.
Bug: T74063
Change-Id: I3d4d0df43bb426d9579eb0349b8b5477281a7cfc
RevertAction::getDescription cannot set subtitle on OutputPage,
because the subtitle on OutputPage gets cleared before the
result of getDescription is added and than the subtitle is gone.
Refactored the code for building the backlink into a static function
and use it.
Change-Id: Iedad0b8e040035a9a10a0b140d2322357e6b539a
This mostly reverts commit 614d7e5c27.
Many wikis use MediaWiki:Common.css and associated pages to create a
custom "theme" for their wiki, which would no longer load on login
or preference pages, creating an inconsistent UI.
This re-adds the difference in module origin for different types
(styles, scripts, etc.), and now OutputPage::disallowUserJs()
checks the value of the "AllowSiteCSSOnRestrictedPages" config setting
to determine whether to allow site-wide CSS styles or not.
By default this feature is disabled to be secure by default.
Bug: 71621
Change-Id: I1bf4dd1845b6952c3985e179fbea48181ffb8907
Page status indicators are icons (or short text snippets) usually
displayed in the top-right corner of the page, outside of the main
content. Basically, <indicator name="foo">[[File:Foo.svg|20px]]</indicator>
may be used on a page to place the icon in the indicator area. They
are also known as top icons, page icons, heading icons or title icons.
I found the discussion on bug 23796 highly illuminating. I suggest
that everyone read it before suggesting different design choices.
I spent some time with a thesaurus pondering the name. "Emblems" and
"badges" were also considered, but the former has a much more limited
meaning and the latter is already taken by Wikidata, with a similar
but subtly different feature set. I am not aware of any naming
conflicts ;) besides new talk page message "indicator" (used by core
and Echo in some documents) and OOjs UI indicators (tiny icons like
the arrow on a dropdown form element), which shouldn't be confusing.
Potential use cases include:
* "Lock" indicators for page protection levels
* Featured/good article indicators
* Redirect shortcuts display ("WP:VPT")
* Links to help/manual for special pages
* Coordinates?… or globe icon for inline pop-up maps
Design features:
* Skin-customizable. Skins can fully control where and how indicators
are shown, or may just do <?php echo $this->getIndicators(); ?> to
output the default structure. By default they are not shown at all.
* Extension-customizable. Extensions can call ParserOutput::addIndicator()
to insert an indicator from one of the numerous parser hooks.
* Wiki-customizable. In addition to just using the parser functions,
on-wiki styles and scripts can use the provided classes and ids
(.mw-indicator, #mw-indicator-<name>) to customize their display.
Design limitations:
* Every indicator must have a unique identifier (name). It's not
possible to create arrays, or to have several indicators with the
same name. In case of duplicates, the latest occurrence of the
parser function wins.
* Indicators are displayed ordered by their names (and not occurrence
order). This ensures consistency across pages and provides a simple
means of ordering or grouping them.
* Indicators are not stored, tracked or accessible outside of
ParserOutput (in particular they're not in the page_props table).
They are intended to merely reflect the content or metadata that is
already present on the page, and not be data themselves. If you ever
think you need to list pages with a given status indicator, instead
figure out what it means and use the appropriate tracking category,
special page report, already existing page_prop, or other means.
Corresponding patch in Vector: I90a8ae15ac8275d084ea5f47b6b2684d5e6c7412.
I'll implement support in the other three skins included in the tarball
and document it on mediawiki.org after this is merged.
Bug: 23796
Change-Id: I2389ff9a5332a2b1d033eb75f0946e5241cfaaf4
Also, as this method is never called with an argument in any Gerrit-hosted
extension, shortened it to just `throw new ReadOnlyError;` on the assumption
that the removed portion was only left in for EditPage.
Change-Id: Icc2fc166b155eac548dfd5f3e67b0b1f92ef90d3
* No longer segment module origin allowance by an "only=" content
type. Both can be sensitive security-wise and there's no valid
use case for allowing CSS anywhere you want to disallow JS. Both
can significantly impact the user interface and cause unintended
actions to be taken on the user's behalf, or desired actions to
be made practically impossible.
* While at it, also remove the ability to set the module allowance
directly. The reduceAllowedModuleOrigin method is all we need.
I couldn't find usage or mention of setAllowedModules() in
mediawiki-core nor in any other Wikimedia-hosted repository.
Bug: 70672
Change-Id: I308e794daca27a9380c67be350f8ab51f9c2de34
- Added newline at end of file
- Removed double spaces/newlines
- Added space after if/function and parentheses/brackets
- Removed space before comma/cast
- Fixed indent of some lines
Change-Id: I29867ffdffdfb7d2b56997e9393497c7dc12f7d3
This reverts most of commit 2d842f1425,
leaving only the test added in it, and reimplements the same
functionality better.
Instead of stripping /*@noflip*/ annotations in CSSJanus, which is
incompatible with other implementations that preserve it, extend
CSSMin to allow other CSS comments to be present before the
rule-global @embed annotation. (This required making the regex logic
in it even worse than it was, but it's actually slightly less terrible
than I expected it would be. Good thing we have tests!)
Bug: 69698
Change-Id: I58603ef64f7d7cdc6461b34721a4d6b15f15ad79
Follows-up 9272bc6c47, 03c503da22, 1e063f6078.
One can't wrap arbitrary JavaScript in an if-statement and have
its inner-body mean exactly the same.
Certain statements are only allowed in the top of a scope (such
as hoisted function declarations). These are not allowed inside
a block. They're fine in both global scope and local function
scope, but not inside an if-block of any scope.
The ECMAScript spec only describes what is an allowed token.
Any unexpected token should result in a SyntaxError.
Chrome's implementation (V8) allows function declarations in
blocks and hoists them to *outside* the condition. Firefox's
SpiderMonkey silently ignores the statement. Neither throw a
SyntaxError.
Rgular ResourceLoader responses only contain mw.loader.implement()
and mw.loader.state() call which could be wrapped without issues.
However such responses don't need wrapping as they're only made
by mediawiki.js (in which case mw is obviously loaded). The
wrapping is for legacy scripts that execute in the global scope.
For those, let's wrap the script tag itself (instead of the
response). That seems like the most water-tight and semantically
correct solution.
Had to bring in $isRaw from ResourceLoader.php, else the startup
module would have been wrapped as well (added regression test).
Bug: 69924
Change-Id: Iedda0464f734ba5f7a884726487f6c7e07d444f1
Follows-up 9272bc6c47, 03c503da22.
* In 9272bc6c47, the condition wrap was removed from
OutputPage for no reason. This went unnnoticed as I had also
accidentally made the cond wrap in makeModuleResponse apply
to both only=scripts and regular (faux) responses, such as by
OutputPage embedding private modules.
* In 03c503da22, the latter bug was fixed, thus exposing the former.
This wrapper belongs in OutputPage, not in ResourceLoader. It's
OutputPage making the loader request. And just like in other places,
it's the "client"'s responsibility to ensure the request is either not
made or wrapped appropriately.
The test for "private module (only=scripts)" could be removed but
I'll keep it so we can see how this changes in the future. It's
a case that can't ever happen, but if it would, it currently gets
a double condition wrapper, which is fine.
Change-Id: Id333e4958ed769831fabca02164c1e8505962d57
This has been the subject of multiple complaints from Google, it
apparently prevents them from properly indexing the variant-specific
pages. Instead, send the variant-independent link as rel=alternate
hreflang=x-default, which is recommended by Google as the preferred way
of specifying "auto-redirecting homepages" in this help page:
https://support.google.com/webmasters/answer/189077?hl=en
Send rel=alternate links unconditionally, since that is also recommended
by that help page: "each language page must identify all language
versions, including itself".
Remove $wgCanonicalLanguageLinks since it would be rather pointless and
poorly named if it only controlled rel=alternate links.
Bug: 52429
Change-Id: Ic75717f6e4ac1f73aa600c2e1bdb9c60e607edb4
We never assign to the variable, only call some (mutating) methods on
the object. With PHP 5 we don't need to pass this by reference.
The functions that evolved into this family were originally added in
r12337, back then we probably still ran on PHP 4 or something.
Change-Id: Ib4ab141ca6d803f9df0351b1f65c7e9955c37d57
Also don't cast $model to int in LinkCache::addGoodLinkObj(); content
model IDs are non-numeric strings, not integers, so that field was
always populated with the value 0. Because 0 is a falsy value, this
caused subsequent calls to Title::getContentModel() to return the
default model rather than the correct one.
Also (hopefully) fixed every single query that could cause a
LinkCache entry to be added without the content model.
Bug: 69789
Change-Id: I94f06baf406afa538cd2b10139598442f9fc6759
