* Explain the difference between the two hooks that both set config vars.
* Remove by-ref & that are not needed. This is a non-breaking change.
Even if the code calling a hook handler provides a variable by reference,
the hook handler being called does not need to require a reference.
Removing these & makes the code less confusing and easier to read.
* Replace an OutputPage type hint with a more narrow IContextSource.
That's all this code actually needs to know. It doesn't need access to
the entire OutputPage, so it doesn't need to require it.
* Update the signature of the ResourceLoaderGetConfigVars handler to
match the caller.
Bug: T215896
Change-Id: Ie1e4b50cd954812f71dd628003b8e9d40fdf5fe8
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
-> Objects by default as passed by reference so removed & in front
method header.
In addition, updated the PHPDoc comments to reflect the changes.
Change-Id: I69ad2090205f6bd694744779d2c46a3506c85378
As suggested in I69ad209.
As far as I can tell the idea was to be able to pass logger-specific
configuration to the logger factory, e.g. to be able to toggle certain
things the loggers would do. But this is not used at the moment. There
is not much value in keeping unused code around. It can esaily be
introduced again later when it turns out it is needed.
Furthermore, I'm told most of the logging functionality should be
removed anyway. See T193051.
Change-Id: I6b1ddb2a65eacc0e096f2ba44922d63e63212a65
Our documentation generator Doxygen is not able to understand @var tags
on constants. A constant is neither a "variable", nor is it possibly to
specify an allowed type for a constant. The type of a constant is strictly
derived from it's value. There is no way to change it, other than changing
the constant itself. There is not much value in repeating the type either.
If it's critical to know the type of a constant (which is a very rare
situation), that should be better explained in the comment.
Doxygen strips all @… tags it does not understand, and renders everything
else as a plain string. This makes it possible to use something like:
/**
* @const Description…
*/
But this is not different from:
/**
* Description…
*/
Change-Id: I4531d4f6b2ab2aca7a62f13f10a655f31c4d6a7a
Rename selectInitialGateway() to selectGatewayType() in
gateway/index.test.js. This test's import name was out of sync with the
declaration which made it more difficult to grep and reduced
consistency.
Change-Id: I60ae359043fdf76015d75b6438992ef6061a4d72
This happened one time before and was fixed via T212419. It now came
back after I2670331, a patch for T214861 that made the title parser
accept more links than before.
This patch implements a decision tree that goes as follows:
1. If it's a link to another page, it can't be anything but a page
preview, as having a peek into another page is effectively the
definition of a page preview.
2. Otherwise it's probably a reference preview, but only if:
* It's a link with a jump mark.
* The link is actually marked as being a "reference".
* Reference previews are enabled.
3. If neither of these definitions fit, do nothing. Note this is not
"hiding errors" we would be able to fix in this code. There are many
ways to manually arrange wikitext in a way that it looks like one or
the other, without fulfilling all requirements. Unfortunately the
user who would see error message or dysfunctional popups would not
be the same as the user who wrote such wikitext.
Bug: T216683
Change-Id: I8d021f19ddc73a261e6a0c62959ddd0cb1d3182d
- Drop unused moment, Redux, and ReduxThunk globals.
- Instead of using a confusing and deprecated boolean, specify that
globals are "readable" / "writable"
https://eslint.org/docs/user-guide/configuring#specifying-globals
Change-Id: I711a4ea7c51c9a560f20fc28bc99bd932c7e1e25
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
An id="…" can potentially be used to target elements individually, manipulate
them, or show them in another context. This is done with the elements in the
file pointer-mask.svg. But not with any other image.
The file-rule="…" only has an effect on shapes that intersect with itself.
This is not the case for this basic "L" shape.
If you think this is fine, I might look at the original OOUI icons as well
and apply the same optimizations on them. But there are 800+ of them to be
looked at, and I want to invest the time only if you think it's worth it.
Change-Id: Ifa4bd60a436e58d3a7c1536f8201fe76fbdac57c
While reviewing the code of the reference endpoint I found it encodes
two CSS class names, "mw-reference-text" and "reference-text". So far
our scraping gateway only implemented one.
https://phabricator.wikimedia.org/diffusion/GMOA/repository/master/
This patch also extracts a piece of code to a named function. This makes
it much easier to read, I feel.
Bug: T214908
Change-Id: I9d1bb1f4c21eb9d57a6b763ca1f756e6cf7049e0
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
The definition of "self-link" in this context is an <a href="…">
element that points to the exact same URL as the current document's
location, excluding a possibly different #… fragment. This is typically
the case when the <a> element does not contain a full URL, but something
like href="#fragment". JavaScript's HTMLAnchorElement.href getter
automatically expands this to be a full URL.
Example:
var a = document.createElement( 'A' );
a.href = '#test';
console.log( a.href );
Notes:
* This new code assumes the wgPageName setting properly reflects the
page name requested via the current document's location. Core does
give us this guarantee.
* The only URL element that is intentionally not compared is the
protocol.
* This accidentially fixes T215899 as well, because the namespace check
is now bypassed for self-links (as it should).
Bug: T214861
Bug: T215899
Change-Id: I2670331cbbdebf7dc9fc70d7342724534f9f54ec
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
As well as:
* Simplify the selectGatewayType() function a bit. Or was this
intentional?
* Remove a TODO we don't need any more, at least not in this file.
Change-Id: I5528f0012cbaf8b4e88e22c7e2a8d87bf027e8f1
We discovered a bunch of possible solutions (see previous patch sets),
including replacing the `$( document )` selector with a more specific
one. That idea does not pass the linter.
Very late I realized the original selector starts with
`#mw-content-text`. This heavily limits where popups are allowed to
appear: really only in the main text content area.
We should limit reference popups to the exact same scope.
This fixes the issue described in T215195. Before, the content of the
popup was covered by the selector. Reference links *inside* the popup
would trigger another popup, which makes the current popup disappear.
Now the popup itself is not covered by these event handlers any more.
Bug: T215195
Change-Id: I142aee68abbd57ca321873855fef9209e0db0bbf
Make targets consistent with Mobile Frontend's .babelrc
and put them into a .browserslistrc file.
This did not change the build files.
Change-Id: Ic4fe13c9e4423d4bb5e6da5fce9039d04a9a215f
Add jQuery types. The JSDocs use TypeScript-compatible typing but tools
such as Visual Studio Code and WebStorm requires the definitions be
supplied. Popups will require these definitions to enable any future
automated type checking too.
Change-Id: I27b5cb052c5ad353322181b0f0ffa4fa56ac1d9f
