I actually tried to bring the animation for the "bottom" property back.
When finished, I realized this animation is done on *top* of the
horizontal scrollbar. This looks fancy, but is not what we want. We
need to keep animating the opacity.
This patch here contains a bit of refactoring that was left after I
went back animating the opacity.
Bug: T220200
Change-Id: Icf613f72f3baa3de86f8aa319667c8e8f16593fd
The changes in the patch check if a horizontal scrollbar is present
and move the absolute positioned fade overlay above that scrollbar.
Since we cannot change the CSS of the :after element via JS a new div
element was introduced.
Bug: T220200
Change-Id: Ia69c9be0facaf3ecebdb9f76d36f7cb3412c0816
The last line in all popups ends with a fade-out gradient to white.
The text in this last line can currently not be selected because it is
covered by this partially transparent container, and the container
consumes all mouse events.
This patch here moves the existing solution from "reference previews
only" (where this was a much more serious problem that on page
previews) to the top-level .less file that is for all popup types.
This is not strictly required, but I feel the code belongs there.
Bug: T220200
Change-Id: Iedf667ead453c9e72025d5fdc7af34756456e68a
This does not solve all two acceptance criteria mentioned in T220200:
* This will allow *interacting* with the scrollbar, no matter if it
is partly covered by the fade-out effect.
* This still does not place the scrollbar in front of the fade-out
effect. Very thin scrollbars are still very hard to see.
Bug: T220200
Change-Id: I394aea6a25c4b3923ad01e18328d42a5e50081f3
Removing obsolete vendor property specifically for old subversion
of Opera < 12.1, desktop and mobile.
Change-Id: Ia5f1e4d00dfd80c261b4c0e0e443c02b606e4109
* web.svg was deprecated in favour of browser.svg.
* Update sad-face.svg based on OOUI speechBubble-ltr/rtl
* Apply preview-generic/disambiguation grey colour using CSS.
Change-Id: I8feea1b526ff85c4ffdee21ef42c616e72881e76
I had to disable ESLint to be allowed to upload this patch. It starts
complaining about something in code I did not even touched. The error
message does not make any sense to me (something about globals being
forbidden in code where I can not spot anything that would be remotely
global).
Change-Id: I6d4b178a65126c4b81b87d99142a6cdc845ae5ee
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
We run into this issue already one time, see Ifb5fe89 (T214710). The
exact same applies here.
The effect of this bug is that for certain references (typically ones
with a colon character in their name) the "jump down" link will be
broken.
Change-Id: Ic6723bd910cb5e5e1e1872ce39f2e271012245de
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
For popup types other than references this particular margin is calculated
as "2 lines + 7", which results in 47px.
The calculation implemented with this patch results in 55px. That's 8 more.
This also increases the total height of reference popups by the same amount.
Bug: T214169
Change-Id: Ie7870717d2fd2ce78268d1fc1b79d87eff059318
See the discussion at I6bd7acc. In this codebase it was decided to not
use "classic" JavaScript, but document it with the benefits TypeScript
comes with. Since I27b5cb0 a dev dependency is in place that makes the
upper case JQuery type work.
All the lower-case jQuery this patch happens to touch have been placed
by me, not knowing better at this point.
Change-Id: I76ef8eabaf4850f07b140dac6f489df37422263e
We run into some confusion with the previous patch Ifcc355f, and
decided to talk about the max-height for reference previews later. The
result of this conversation is this patch here.
The mocks and discussions in T214169 mention several numbers that all
conflict a little bit. In detail:
* We ignore the mentioned "4 lines", but go with 5. We assume the 4 is
a mistake. Using 5 is consistent with all mocks and all given pixel
measurements.
* The mock ask for a max-height of 106px for the container. With this
patch it's 100px, which is exactly 5 lines. The extra 6px don't do
anything as far as we can tell, but make the code confusing.
* The mock asks for 215px for the whole popup. With this patch it's
203px. Note this number is (intentionally) not hard-coded anywhere but a
result from all line heights, line counts, paddings and margins combined.
Bug: T214169
Change-Id: I18f61ed02ed506d48e3834e2ebc48b3392f7d732
These are annotations for ESLint as described at:
https://eslint.org/docs/user-guide/configuring#specifying-globals
I'm not sure where the `…: false` comes from. I assume it is a mistake
and does not have an effect.
I tried to move these annotations closer to the line they are about in
case there is only one line. And move it to the top when there is more
than one line using the global.
Change-Id: I4bd112c5fddd8a97d829a9b91707b8eb7cd7a332
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
This patch also removes misplaced empty lines at the beginning of a
scope. In PHP code we even have a sniff for these. In JavaScript we
don't, but I suggest to be consistent about this.
Change-Id: Ic104ae8fe176da1dafa9bc783402adecb71de1f0
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 patch mainly adjusts the min-height and paddings for the reference
popups according to the mocks. It also enables scrolling inside of these
popups if the content exceeds the max sizes.
For now the scrollbars don't get specific styling. Also not, that the
fade out effect seen in the mocks is not part of this task.
Bug: T214169
Change-Id: Ifcc355fbcb6410778e7d4c569eb4cab09ed5dbf5
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
To make sure that we enable the link highlighting in the Cite extension we want
to trigger the click handler on the original footnote link. This is done by
passing the id of the source element to the model and the renderer.
Bug: T213905
Change-Id: I0bd59ac326269f3c0850946851fb79b611dc2a57
This CSS class is used by the regular wikitext content area, and used
by certain CSS selectors (e.g. the external web link arrow).
The DOM structure for each popup is (intentionally) created outside
of this scope, at the end of the current page's body. This works
great for page previews because the do *not* want to share any styles
with the rest of the page. But reference previews want to do this.
In this patch I also remove the inner <span>. It was misplaced (note
the name) and resulted in block elements nested in an inline element.
Bug: T214463
Change-Id: I740e37a2ed929edf971b348fbf20e5fb12012d37
This gets rid of a little bit of code duplication, and makes the
interfaces all conform to one standard again after I05ed4b8 left them
in a little inconsistent (but properly documented) state.
Bug: T214970
Change-Id: If8407c1a48aff1cb31fc2e74b3c2b846e79a3cb5
As discussed in Iaadcce9. This does have a few benefits:
* Less code in the already pretty big render.js file.
* The code setting the target attribute is much closer to where it
belongs: in the file that specifies how the content of a reference
popup should look and behave.
* The class name "mwe-popups-extract" is not mentioned in two different
files, but in the same.
Note this changes the signature of this src/ui/templates/… file to not
return an HTML string any more, but a jQuery object. The other templates
still return strings. I believe this is fine, and not that much of a
difference anyway. The signatures don't need to be identical. And the
jQuery object still represents the exact same HTML as before.
If it helps we could change all templates/… signatures accordingly.
Could be done in this or a separate patch.
Bug: T213908
Bug: T214970
Change-Id: I05ed4b886f79c5ae748f53ab9fed965dfd217620
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
I tried hard to keep the CSS as small and robust as possible. The
icon will be align with the text by adding a negativ margin. With
that we also decided against using RTL and LTR specific icons that
are positioned at the edge of the canvas for now.
Bug: T213907
Change-Id: I98888114e1c50e249cf31e71749323bd4f69da3f
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
The need for this is more a sign for a broken specification than an
actual issue with this code. But better be sure than sorry. More
details at
https://mathiasbynens.github.io/rel-noopener/
Bug: T214776
Change-Id: Idbcfae6d146fbbe3bff730239329beeb3455e18c
Excluding tests for the renderer which keeps failing. This will be
readded in a later patch.
Bug: T213415
Bug: T213908
Change-Id: If79fa3d0a7a20f121b1ceda6e0e33ad691b1ad30
This adds support for preview popups on reference/footnotes from
the Cite extension. For that a new preview type was introduced and
integrated into the existing structures.
The essential starting points were this code comes into action are
added behind the feature flag introduced in the previous patches.
Bug: T213415
Change-Id: Ie0ccb03117bd654373d0f458b62cc52018361c67
Most of the code is exported because is is tested separately. But
these are all tested via createPreviewWithType(). I think it's just a
minor mistake to have these exported.
Change-Id: Ic4f4dc40fd95a60aba45cb5aa3fcbb6e3bc8c386
This is split from the current draft patch Ie0ccb03. This is part of a
series of very small patches that prepare the code for new types of popups.
Bug: T213415
Change-Id: I4f4392057f6d3eff78409c8b6f49898c8be45d3e
The following upgrade was made:
stylelint-config-wikimedia | 0.4.3 | 0.5.0
The upgraded version stylelint-config-wikimedia includes stylelint as a
dependency (no longer a peer dependency) [1] so our stylelint dependency was
removed.
As a result of this upgrade, several of our .less files were flagged by
the linter and corrected in this patch.
[1] https://github.com/wikimedia/stylelint-config-wikimedia/blob/v0.5.0/package.json#L36
Bug: T209314
Change-Id: Ic6d4b1caf60f4e03fa60076a2ae74d6639117f25
