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
User::getBoolOption() is deprecated and should be replaced with
UserOptionsLookup::getBoolOption()
Bug: T277600
Change-Id: I9a2118a6342bd5f145174428dcfb518cba4e439b
User::setOption() is deprecated and should be replaced with UserOptionsManager::setOption()
Bug: T277818
Change-Id: I5698b4422755a921c9c9c01ce29084ebfe5f5385
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
As well as make some more test code more readable without
changing what the test does.
Bug: T281698
Change-Id: Ia153981d9196b47099ef3880ac334718895fb0fc
I was not able to reproduce the issue locally, but I believe
this might be the reason for the failure we see. It can't hurt
and needs to change anyway, with or without the failure.
Bug: T281324
Change-Id: I0002f952438d7afe2fb6c2100bf25760f7dda10d
Use mw.track instead of dedicated tracker for VirtualPageViews.
This way we can migrate it to the new Event Platform client.
The new client does not observe DNT, which was the reason this
instrument was moved to a dedicated tracker on the first place.
Bug: T279382
Change-Id: I8bb515eab337ffed686ba7522bc6153cfdd8ca8d
JUnit reporter configuration changed since WebdriverIO v6. Before this
patch, the reporter was outputing to terminal, instead of outputing to
file.
Bug: T214686
Change-Id: Ib315b0261b3724cded17c85519ac28842d7ab071
This is the smallest possible patch for a backport.
While it seems there is zero technical reason to limit user
option keys to lowercase with dashes, it's best-practice.
Same as message keys.
Bug: T281235
Change-Id: Ia4a45cf4459543c81b23b757ae9c2cfaf9676894
* 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
We still have 2 different mechanisms in place, maybe even 3:
* We simplify the CSS selector when we know a popup type is
disabled, and it's impossible an anonymous user can enable it
at run-time.
* We create that "initiallyEnabled" map that allows anonymous
users to toggle the individual popup types at run-time.
* This map is also used to check if the footer link should be
shown.
* There is also a wgPopupsReferencePreviews global that acts as
a "kill switch". However, this is not a pure feature flag,
but incorporates the user setting for registered users. This
is currently partly redundant (checking
`mw.user.options.get( 'popupsreferencepreviews' )` does the
same) and can be removed later when the feature flag is not
needed any more.
The footer link currently acts odd because anonymous users are
unable to enable ReferencePreviews, but get the footer link.
This patch introduces a 3-state model:
* `true` acts as before.
* `false` means a popup type is disabled, but anonymous users
can enable it (i.e. this is the opt-out behavior for anonymous
users).
* `null` means a popup type is not available at run-time, for
nobody. Anonymous users can't do anything about this.
Registered users must leave the page and change a setting.
Bug: T277640
Change-Id: Id8d1396c09cf0f706034a66f9cd3c880a8b33df8
* That `this.user` is unused.
* Some tests missed a module name. This means they are reported
as part of the previous module. While this is purely cosmetic,
it's confusing to see the wrong module name in the report.
Change-Id: I73915d3c4fd9a03bda1ddc8dff6dd5539113c3cd
… as well as in one place in production code. The motivation
for this change is to make the code easier and faster to read.
There is a little bit of duplication in the test setup now.
But I would like to argue this is a good thing. The values are
rather trivial. The difference (or absense of a difference) is
much easier to see now.
Change-Id: I9aa95b59f0c45ea7c9257970e2fcdba3a000d234
This patch does nothing but rename a pair of variables:
"prevState/state" becomes "oldState/newState". Reasoning:
1. The abbreviated "prev" is confusing, especially because we
are in a codebase that is all about "previews".
2. We are in a context that is all about a state **change**.
Change listeners get notified about the change from one state
to another. While it would be possible to stick to the already
mentioned "previous/current" terminology, I find the word
"current" confusing. What is "current" in this context? Did
the state already change? Am I notified about a change that is
**going** to happen or already happened? Is this even relevant?
I don't think it is. Therefor "old/new".
Another possibility is "previous/next".
Change-Id: Id886e1a095967fe86fb9021f59e335c62da8994e
The nextState() function was not able to understand updates that
are deeper than a single level. Example:
nextState( state, { pagePreviews: { enabled: true } } )
Before, this would replace whatever was in the "pagePreviews"
property with { enabled: true }, but not merge it. In some places
a single level of recursion was done manually because of this.
This can be removed now.
This is done in preparation for splitting the "enabled" flag into
separate ones for each popup type.
Bug: T277639
Change-Id: I35911c18018ba7cd1633a4c882b978656c3fee36
Note how getIsEnabled() is documented: "if the user hasn't
previously enabled or disabled Page Previews […] then they
are treated as if they have enabled them."
In other words: The idea that the default should be true is
encoded twice in this code. This is just not necessary. We can
remove one without loosing anything.
Motivtion: Simplifying the code and reducing the package size.
Since the code fundamentally depends on this default value
anyway, we can clear the users localStorage when they decide
to go back to the default – instead of storing a "1" which
does the same as the default.
Change-Id: I2814a1e9269979918609162a508eeee6944d9e52
The main motivation here is to dramatically reduce the number
of places that use the same property name "enabled" for values
on different objects (e.g. "state", "actions", and "updates"
are all different things) with slightly different meanings. I
tried hard to come up with names that reflect better what each
meaning is.
Bug: T277639
Change-Id: Ie766259793f716262e3d4622ca55156d11f4842c
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
To reduce size of code added to the <head> and increase performance.
The increased bundlesize is still less than the size spared bytes in
ResourceLoaderGetConfigVars. - But nevertheless the main gain is loading
less in the <head> anyways.
To avoid further complexity in the code, the bitmask is converted to
the according config setting early on instead of adding checks on the
bitmask all over the place.
Tests will be added in follow ups.
Bug: T276716
Change-Id: Ib4f82bed58295b25f0a41cb37e36244e45f16317
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
* When there are multiple <cite> elements, the first that contains a
known class is used. We assume the earlier one must be the relevant
one.
* When there are multiple known classes in e.g. <cite class="web news">,
the last one is used. This follows how CSS works.
* There is extra validation if the corresponding message exists, just
to be sure. This is cheap.
Bug: T274979
Change-Id: Iee3481ea16af96b40faf978e254718e5a48917f3
I added the common styling for the setting icon to the popup.less
and removed the now empty pagePreview.less.
Bug: T234205
Change-Id: I2a82831bc71a4208c4b66c18e2a4613127c43e1f
It turns out the TextExtracts extension is build in a way so
that the parameter plaintext=1 alone is not enough. It does
not really mean "please return plain text" but "please don't
return HTML". It can still return one of three formats:
* Wikitext.
* An intermediate parser format where headlines are not
`== this ==` but `��2��this`.
* Actual flat plain text.
The default is wikitext. That's why we see `== wikitext
syntax ==` in certain edge-case situations. Forcing it to
"plain" fixes this.
Bug: T271439
Change-Id: I3035fb3df99680af8bbd10c4513aed730013c344
