Why:
- After migrating to the regular build of Vue 3, the compatConfig
settings in component definitions will be ignored.
What:
- Remove compatConfig declarations from all Vue components in this extension.
Bug: T289105
Bug: T363351
Change-Id: I0f4aefd767145dbba8801c6f4111c64918756e8a
https://docs.phpunit.de/en/11.4/annotations.html#covers recommends:
Please note that this annotation requires a fully-qualified class name
(FQCN). To make this more obvious to the reader, it is recommended to
use a leading backslash (even if this not required for the annotation
to work correctly).
Change-Id: I58d381d8a5b378d0086bdce0717f42e885ea5b87
Fixes the separator bar used in the sticky navbar being a light gray
color on dark mode to be a dark gray instead. The light gray is changed
from #c8c8c8 to #c8ccd1 to match an existing Codex color.
Change-Id: I1638fb268dc7a1bbbe80d46b1f2678aa69ba7679
It is always provided by web2017-polyfills in core.
Also remove checks for requestAnimationFrame, which core now
assumes to exist.
Change-Id: Ia9dd0330b45c945cf4aca1ea0d4edadc7308e1fc
In situations where anon account creation is disabled or when
combined login link would be used, the usermenu array contains
single element (for 'login' or 'login/create') instead of two
elements ('login' and 'create account' items separately)
If $wgWikimediaMessagesAnonDonateLink is enabled through the
WikimediaMessages extension, the third element 'sitesupport'
exists, making the number of anon items either 1 or 2 or 3.
This patch fixes $isDefaultAnonUserLinks variable to account
for all the cases
Additionally, if even login is disabled, the element count can be
zero and in such case we need to hide the dropdown in all cases
(not only on large viewports) because it would always be empty.
This patch passes the userlinks count to ::getDropdown() and adds
CSS class when appropriate to hide the drowpdown completely.
Bug: T332743
Change-Id: I1ce5e1ea30917a6e80ef00f3c1703cbd0ecb6968
* Stop monitoring bundles which contain Codex elements that are
not render blocking resources (e.g. skins.vector.search.codex.scripts)
- going forward we should limit monitoring to only code in the codebase
and render blocking CSS. These will now be monitored in core.
Follow up to Ib2a9ee811f9672b5bffaf2263fbc6fc37d806d59
Bug: T378635
Change-Id: Ia12385329973c2bdbe914d243c0a9c7805511c68
Move CdxTypeaheadSearch out of render blocking module - it is not
needed - only CdxSearchInput is rendered by default.
Bug: T378636
Change-Id: Id4feb26f73413826cf04ec200d0d501c6b057bfc
To make sure this is code-ified I have added the rule selector-max-specificity
to check specificity and error if we ever attempt to change this and to also
prevent us from writing overly complicated selectors (for now the default is
based on the status quo)
Additional change is required to skinStyle file to accomodate the new rule.
Bug: T373989
Change-Id: I3921d1fb3a098faae8f5a8bdc895783f1b298daa
