Types should not have spaces in them. In the current example this
results in a page preview element with an additional class "<"\'>"
I'm not sure what this is protecting against since we can trust types
to always be in a sensible class friendly form. It would be better
to throw an error in the mw.popups.register function than allow this.
Change-Id: If08c5162c1ca0fc3db4944092231061e22113263
Allow extensions to register new types of previews via
extension attributes.
Changes:
- The check for reference previews doesn't make sense
as $('a[ href*="#" ]' ) will match any elements with a hash
fragment, so the additional check to Title.getFragment
will not provide a different result. This was introduced in
I9ec57e0fbb0d21beaaa7b359c1c2bef64d2c14f5
- Links that point to themselves are marked with mw-selflink
in MediaWiki so this can use the not selector we already have.
- The new API is used internally and only available via extension
Attributes
- An example is provided in SkinJSON
(https://github.com/jdlrobson/mediawiki-skins-skinjson/pull/14)
Bug: T233099
Change-Id: Iefe98c1f0422dbf034e385b1a41a859d030a2cf4
The requirement for landscape images is to be at least 320px
wide. The requirement for portrait images is more relaxed,
only 250px high. Images that fall between these two
requirements currently don't show a thumbnail, even if they
could.
This change affects a very specific group of images:
* Square images from 250 x 250 to 319 x 319.
* Landscape images from 251 x 250 to 319 x 250.
* Landscape images from 319 x 250 to 319 x 318.
The most extreme ratio is 319 x 250. This will be cut to
203 x 250. I.e. the absolute extreme are 58px missing left
and right, but never more.
Requested at https://www.mediawiki.org/wiki/Topic:Vwl97pm6as9fuf6k
Additional stories for testing more extreme small images:
* Small Tall - 300x1000px
* Small Short - 300x200px
Update tests accordingly.
Bug: T268999
Change-Id: I811f1c0e7e9b0c30280b36a61cc7831a5b9e58c8
Turns out this was only in place because the test was
(intentionally) incomplete. But it's dead code in
production. Let's get rid of it.
Change-Id: Ieeb145b6972dceb7eeda3a167d907b680d5c3ce4
* Change more places to not hard-code the popup types, but use
loops and such.
* Change many `function ()` headers to use the more streamlined
ES6 sytnax.
Bug: T277639
Bug: T277640
Change-Id: Ifece87d51012e0e069286453b27f5c9ae273710e
We added reference preview as a checkbox the the
anonymous user settings. To handle both popup types
(pages and references), we changed the usage of
preview.enabled. We pass on all types as a map
inside preview.enabled. The footer link to edit the
settings will appear for anonymous users if at least
one type is disabled.
Bug: T277639
Change-Id: I860a1b35ac7749d8d0884575f6acb7186ad8e4d0
Add message, description, extension for title. Update createPagePreview, renderPagePreview methods to add title attribute to settings gear icon. Add test for title attribute. Increase maxSize, maxAssetSize, maxEntrypointSize. Add compiled js files.
Bug: T274887
Change-Id: Ibb29deb3418569d8283b954b4b22074423e78bda
Update copy and remove unnecessary reference preview preference
in favor of using the default preference. It seems there is no
stable method to link to the subsections on the preference page
for gadgets. So in all cases does the link just point to the
gadgets pref page.
These changes should only be visible when reference previews
are no longer marked as a beta feature.
Bug: T265709
Change-Id: I7b8ab91331092ada04b230315373548673b9272c
This reduces a lot of churn in creating the SVG
element and related helpers.
When IE11 is dropped, the SVG code-path can also be dropped.
Bug: T269336
Change-Id: I7f91192dedc2a78f1c7c84179cff1687593177c0
Reduce layout/style thrashing by measuring all required geometries
at event handler, not waiting for delays/redux/style changes.
Use CSS bottom instead of top, to avoid having to measure the popup
before positioning it, if it's placed above the link ("flippedY").
Disable some test cases that relied on implementation detail of using
"top" CSS.
Change-Id: Id0cbf506009b824d0fb6af4d6fe220e2f69aaaad
Now that the footnote label links to the references section, we don't
need this additional link.
Bug: T265482
Change-Id: Ib9b2939eb49e7b826c7699a5b7fa0e8255fa9da1
Elements that are marked as collapsible (often tables, but can
actually be anything) are most certainly marked as such because
they are big and don't fit in a popup.
Another plugin makes tables sortable.
In both cases non-functional UI elements appear in the popup.
We decided:
* Hide collapsible elements (no matter if currently collapsed
or not), and show a placeholder text instead.
* Remove sortable arrows.
This is a baseline patch that solves everything, except the
(i) icon is missing. This will be added in the next patch.
Bug: T220208
Change-Id: I58f3036bf4988d0ebe5716b0a54506446fca10c3
There are 3 types of links:
* Links with no class are links to other pages in the same wiki.
* Links with "extiw" are interlanguage as well as interwiki
links to other known wikis (e.g. from Wikipedia to Wikidata).
* Links with "external" point to somewhere else on the web.
Bug: T215419
Bug: T239230
Change-Id: Ia25db94d02670a919fc003f3e3562725de2e8eae
Notice how this actually reduces the size of the final, compiled index.js.
It's not much, but still.
One issue I noticed is that the coverage reports for the JS code stopped
working. I have no idea why.
Bug: T208951
Change-Id: I2fe92579574b3b1ba4d2dd064899eee944045a96
Logs events to the ReferencePreviewsPopups EventLogging schema, in
order to understand whether Reference Previews is helpful for
end-users.
This will be removed along with the older tracking, as soon as our analysis
phase is finished.
Incidentally disables a lint rule for the generated JS, it's about
readability so irrelevant to the minified code.
Bug: T214493
Change-Id: I2638611ba67b785338f7e98a1c4b08a5e829812d
Two big chunks of code (the "click" and "scroll" event handlers) have
not been covered with QUnit tests before. I found this was not that
complicated and worth the effort.
Note we already have browser tests in place for these features. These
are still required because the scroll feature can not fully be tested
when the popup is not actually rendered on screen.
Bug: T214971
Change-Id: I58111489fe6c4bed65efec59f9fc4184c828b2b3
With this I want to pull apart testing two things at one, checking if the
URL is escaped and if it is put to the right position.
So this adds an explicit test, that makes sure that urls in the popup are
escaped safely and lets the big test become more general in that regard.
Bug: T214971
Change-Id: I09b5225a8370e8b1337b2cf6ca03ccb79b3a64aa
When a thumbnail in portrait-mode is narrower than the 200px
expected width, the SVG clip-path should be shifted on the x-axis
in order to align with the thumbnail image.
Adds extra test-cases to validate this logic.
Bug: T204627
Change-Id: I9359c9fb335e5fad3f7d5ba33ee89d2a1f26b8b2
During story time on 2019-03-12 it was decided to consistently talk
about "References" in all messages. Main motivation is that this is
the term the community is most familiar with, and it is also the term
that is used in reference section headings most of the time.
Bug: T215063
Change-Id: Iaab8d2c0da1546a3c9d27bc8e2e1c784050ed135
These icons are currently unused because the gateway does not deliver
the necessary information. This will be used starting with I6223cbb.
This patch aims to introduce all resources needed by the later.
Bug: T214908
Change-Id: Ie0c3c059222700169f2605c3123554c74d974256
According to the standard.
Note: In a previous patch I removed the <?xml …?> line. This conflicts
with what https://www.mediawiki.org/wiki/Manual:Coding_conventions/SVG
suggests. However, I think the removal is ok in this particular case
because this file will never be shown as an image, and never be shown
standalone. Instead, it will be inserted in the documents DOM. The XML
header doesn't matter anyway then.
Change-Id: If23ad54985abb30f8c92500546bd04eeca44fab3
I decided to keep the comments because they are sooo helpful, but
tried to shorten them a bit. The biggest change is the indention with
tabs and the much more compact <path> elements. The shapes are the
exact same. I manually confirmed this for all four.
Change-Id: I2d1294c9ae7e398dcbe2d111c42848d17be8a67e
I tested this with all 16 possible combinations:
* The pointer can show up in all 4 corners.
* The popup can contain a thumbnail or not. The code for the pointer
is very different then, because the SVG masks are only relevant in
this scenario.
* The thumbnail can be tall or not.
* I even tested tall popups without a thumbnail. This is a combination
that is impossible in production scenarios.
I found 3 issues. This patch fixes 2 of them:
* The pointer is misplaced in the bottom-right corner when the popup
does not have a thumbnail (as reported in T215194).
* The pointer is misplaced in the upper-right corner when the popup
shows a thumbnail.
* The pointer in the upper-right corner is gray instead of white when
the popup is tall, but does not show a thumbnail. As this is not
relevant in production, I did not fixed it.
It seems both misplacements are because of the same reason: For some
reason, calculations are done based on the assumption the popup would
be 300px wide, but it is 320px wide.
Note I did not just added 20 everywhere, but manually alligned the
pointer triangles so they are placed exactly the same distance from
the corner as in the three other corners.
Note I did not tested this (yet) in RTL scenarios.
Bug: T215194
Change-Id: If0ca63d4d4b6e8083c7de1517fe32f49671a40e6
This is now possible since the render functions return jQuery objects.
All this code is exclusively used in the pagePreview.js file, and
doesn't need to make the already very big renderer.js file even
bigger.
Note the tests for all renderers have always been collected in a
single file. That's why the test case does not move.
Change-Id: I0c24638751c5f0e93d2bc0f3f4bb61fa0cf50d15
As discussed, the $( '<a>', { id: 'foo' } ) syntax is bogus because
plugins are able to *change* it. It's not just a list of attributes,
but whenever there is a method with the same name, that method will be
called instead. This means the result of this feature is unpredictable.
This patch also streamlines a few other jQuery calls that can be
shortened.
Bug: T214970
Change-Id: Ib58b8673c7ce41139f926c845c1b3adfbfde1b26
I do find these very confusing and would like to remove them:
* The test setup looks like these popup types are going to use
these properties. But they don't. They are not even trying to
access these properties.
* There are no assertions that make sure these properties are
*not* used. It would be possible to add something like this,
but I honestly think this is not worth it.
We might need to reflect this in the PreviewModel documentation
in src/preview/model.js. I would like to do this in a separate
patch.
Bug: T214970
Change-Id: I136112bfea7f732d2673bcb8c69aba9defe6ba85
Including tests for all situations.
I believe it is impossible or extremely hard to actually abuse any of
these places. All these data are not extracted from the current page, but
delivered either by MediaWiki's api.php or a RESTful endpoint, as
configured via $wgPopupsGateway and $wgPopupsRestGatewayEndpoint. A
possible attacker would need to write it's own endpoint (which must either
run on the same server or somehow ignore the CSRF token), and set the
value of mw.config.values.wgPopupsRestGatewayEndpoint on the client to
this endpoint – which requires just *another* attack vector to be able to
do this.
It's "the right thing"(tm) to escape all this anyway.
I found two possibly relevant security reviews of this extension, T88171
and T129177, resolved in 2015 and 2016.
Bug: T88171
Bug: T129177
Bug: T214754
Bug: T214971
Change-Id: I1d118c9ccaea434a253a772d18139b9b077118ab
Instead of maintaining a list of named constants (which must be updated
every time we want to add a new test with a new message), the mock now
behaves like MediaWiki's build-in qqx dummy language code and returns
the message key in brackets. The additional benefit of using the
HTML-like <…> characters is that this will automatically test if the
messages are properly HTML escaped.
Bug: T214970
Change-Id: Id7911036a7b582aff21acf911a826b5421a55938
I guess both is fine: either having the default in the gateway (as it
was before), or in the renderer (as this patch proposes). I, personally,
feel better with having it closer to where it is needed. This way it's
not possible to accidentially deliver a model object with an empty title.
The renderer will catch this.
At the moment we don't know exactly how we will fetch other titles (e.g.
"Book").
This change is split from I15611a4 where it was a little misplaced.
It also includes a test for the default fallback title.
Bug: T213907
Change-Id: I8ec3ddc21a417da7f95feff7b080cbd60d5472e7
Including tests. I also changed the title to include quotes as well,
even if not critical in that case.
Bug: T214754
Change-Id: I2f92a5714f7adc229a003f9167bcc9afdbc55583
I finally found the issue. It was an incomplete mock for the
mw.html.escape() function that would return the string unescaped.
Bug: T213415
Bug: T213908
Change-Id: I198393b3c72771e4018f79913ddb9f4cb2c0d4de
The following upgrade was made:
eslint-config-wikimedia | 0.8.1 | 0.9.0
The upgrade of eslint-config-wikimedia removes the need of
eslint-plugin-qunit as a peerDependency because it is now a hard
dependency [1] so it was removed in our package.json.
It appears the biggest change in the upgrade was the use of separate
profiles [2]. Given this, our root .eslintrc.json was updated to extend
from 'wikimedia/client'.
Several test files were flagged by the upgraded linter and were fixed in
this patch. Additionally, our build file was flagged for having too many
statements on one line. This rule was turned off in .eslintrc.es5.json
[1] https://github.com/wikimedia/eslint-config-wikimedia/blob/master/package.json#L48
[2] https://github.com/wikimedia/eslint-config-wikimedia/blob/master/CHANGELOG.md#090--2018-11-19
Bug: T209314
Change-Id: I29db72e77f04a327bc9c2b558c6d53849287bb80
jQuery.hidpi was deprecated by T127328
(https://gerrit.wikimedia.org/r/441614). This repo used the
"bracketedDevicePixelRatio" function from that plugin. Since browser
compatibility is good now for window.devicePixelRatio, this commit adds
a function which relies on that instead.
Bug: T198579
Change-Id: I56c234048d7741f12f35bfff5f7319c6e085c29f
