Remove the ext.popups.images module, replacing it with
references to the SVG image.
- The footer image is the same in dark and light mode so use
background image
- Use mask image for sad face to make it work correctly in dark mode.
- Rely on CSS Janus for the ltr to rtl swap out
Change-Id: Idf041730549b834126d9631ac95611526ae5daa3
Commit a75ddc41 and 33f9e9d3 effectively changed the default user
option value of popups-reference-previews for users created before
2017/08/16 without any justification.
Please see the task description for full analysis.
This partially reverts commit a75ddc41.
Bug: T366419
Change-Id: I68d6114384af6d259dbc4541522d52ae9a289e49
The keys belong to the Cite extension where they are used already.
Bug: T363156
Depends-On: I788c16c5bddc0df7f00dbbc39625b9adaa5bf184
Change-Id: I1205af0539d6b2693f0e96d70393e7ecb005b7ba
Implement conditional defaults for user preferences in the Popups
component.
This patch aims to simplify the preference management system by
leveraging conditional logic directly within the component rather
than relying on multiple hooks
Changes:
- Updated `extension.json` to reflect the removal of outdated hooks.
- Updated `extension.json` to reflect the conditional user defaults.
- Removed unused user option `popupsreferencepreviews` from
`extension.json`
- Modified `PopupsHooks` to streamline the preferences management,
and depend on conditional user defaults, and removing `onUserGetDefaultOptions` and `onLocalUserCreated` hooks.
- Removed unneeded test cases in `PopupsHooksTest`.
Bug: T364347
Change-Id: Iae454e4b4704a0289ca0a2b0794730562fda0dd1
As a precursor to moving this code to the Cite extension move it off
of webpack and switch to using require rather than import
Bug: T355194
Change-Id: Ib6486ad38b79a3b67a9744b716b1a2f5d3779795
This is a precursor to moving the code out to the Cite extension.
This can be squashed into parent commit or merged at same time.
I've kept the two patches separate to make them easier to review.
Bug: T326692
Change-Id: I50dbf28a1078df6c73fd0fbf77480488dd82c7b3
* Adds a new webpack entry point for references previews
* Reference related code in src/index.js is moved to new
file resources/ext.popups.referencePreviews/index.js
The changes:
* References previews now in its own module ext.popups.referencePreviews
* Loaded via getCustomPopupTypes
* OWNERS.md files make clear which team owns which part of the code.
Bug: T326692
Change-Id: Iea8a5b9221c0b1fd41e40bff2cbe01e42124d53f
User-options related classes are being moved to
the MediaWiki\User\Options namespace in MediaWiki Core;
reflect that change here.
Bug: T352284
Depends-On: I9822eb1553870b876d0b8a927e4e86c27d83bd52
Change-Id: Icb39d3f73e120fd0d9dad5ae362787cd19d47bfb
The extension is out of beta and will be enabled by default now.
Leaving some hints if we decide to also remove the feature flag.
Bug: T282999
Bug: T351708
Change-Id: I1556b2f3592294d094770ede2c276eddeef8bbe9
The …AFTER_BETA constant is the one we want to keep after we removed
all BetaFeature code. The naming scheme is just confusing.
Safe to rename. Not used anywhere else:
https://codesearch.wmcloud.org/search/?q=REFERENCE_PREVIEWS_PREFERENCE_NAME
We also decided to keep the $wgPopupsReferencePreviews feature flag.
Update the documentation accordingly.
This is split from I1556b2f to make it easier to review.
Bug: T351708
Change-Id: Ifbb41156f2a5a4d8a81e79f613754869c5c89690
This reverts commit af90386c67.
Reason for revert: The codex-styles module is now only loaded when
the settings cog is clicked.
Bug: T348069
Change-Id: I1d3c3a7b5c74c3e2d64765274468e48c014a4047
This reverts commit 85d9a7b0ed.
Reason for revert: Unexpected visual change flagged by Pixel.
We're now loading BOTH codex search and Codex
styles on page load (the latter via JavaScript). This results in
a visual regression in the sidebar as the message box for
languages switches from MediaWiki UI to Codex. I am not 100% sure
what the right approach is here, but we should pause to assess
given this new learning.
Possible options
1) Add checkbox styles to codex-search bundle
2) Load codex-styles on page load instead of codex-search
3) Delay the loading of the codex-styles until the overlay is
rendering
4) Wait until Codex has code splitting.
Change-Id: I633364fea54b048492c6bde10b4c4cc8ab99b9ae
- Removes .mw-ui-icon and .mw-ui-icon-element
- Aligns markup/styles between generic and disambiguation previews
- Update padding for generic and disambiguation previews to be the same as other popups, results in minor visual changes
Bug: T341899
Change-Id: I9a58fc6a93160d07452ea6f903e1797dd9421d92
For fetch and AbortController we provide native polyfills (see
resources/src/skip-web2017-polyfills.js) so safe to use this here.
This will be empty for modern browsers.
Change-Id: Ic0f55eb0a0276be3587a4b866834bddff1124ad2
Replacing 'mediawiki.ui/variables.less' @import with
new skin-aware 'mediawiki.skin.variables.less' standard.
Also
- replacing several static values with new Codex design token featuring
skin variables of `background-color`, `color`, `border-` and
`opacity` category
- renaming three Less variables to variable naming standard
Please note, that this patch is not replacing all values with
possible Codex tokens. It's just applying them on selected
categories for consistency for now to keep the patch easier reviewable.
Further replacements will be done in follow-up patches.
Bump MediaWiki core required version to >= v1.41.0.
Bug: T332541
Co-Authored-by: Volker E. <volker.e@wikimedia.org>
Change-Id: If35605e8336c8619c6230bc892b360edbfd16f62
I noticed that page previews is currently not working for ES5 users
as ext.maths.popups is an ES6 module which causes the
mw.loader call inside ext.popups/index.js to reject meaning the
feature never gets activated. This was broken in
Iefe98c1f0422dbf034e385b1a41a859d030a2cf4.
I talked to Olga about whether we should restore ES6
support for page previews, and given the recent trend away
from IE11, we decided it made sense to drop page previews
support for ES6 users.
Bug: T328497
Bug: T329901
Change-Id: Icbd683b12c47491eba4de6b5a14afce4465553b9
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 new soft auto-enroll logic of BetaFeatures requires user options
default to null or no default values since it needs to save opt-out
values.
Unfortunately, BetaFeatures can't maintain default options itself, since
the GetBetaFeaturePreferences hook is coupled with User, can't be run
in the handler of UserGetDefaultOptions hook.
All the user options will be handled by BetaFeatures carefully, no
unnecessary values will be saved (no regression of T291748).
Needed by change I93af61153ec3c2cd3ec7686fe88067eed6766b5a, and they
should be merged in the same deploy train.
Bug: T260870
Change-Id: I1e9a91eed2e2eb22ce42f8d79b7183c505f1df7d
Without the default the preference is never deleted from the database,
even it was disabled by the user.
Bug: T291748
Change-Id: I63ef1bad22acc4581e7c6aecb7dcc3d54422af18
We started logging VirtualPageView events to the Event Platform in
I645a81a4 but I640ab367c overwrote that change.
Change-Id: I3fcb9b79931da2ce0fa39ffc3be03e141d0d4152
This schema has been fully migrated to Event Platform. Setting
this as the default lets us remove the mediawiki-config override
of this that is currently being used.
Bug: T238138
Change-Id: I645a81a4a22130ed6a442c055d6bf4e78160705f
This does not fully solve the ticket, as these are not the
actual OOUI styles. But it's already much better than the
unstyled checkboxes before.
Bug: T281227
Change-Id: I9a5023482774c09aa73845ca6dfd1c4926f088e1
We changed the handling of the popup settings. They now contain popup types (pages and references).
To not get confused with the old setting options (simple, advanced and off),
we would like to rename the local for the simple setting to page.
It should already contain the correct string.
Bug: T277639
Change-Id: I8847b890e9e31602277a92d82a188fcdd3eea855
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
An "advanced" option was first introduced in 2014 via patch I374805e
(originally named "monitor-or-edit", renamed via patch I7b4f6d2).
The isNavPopupsEnabled() function was added in 2016 via patch
Ic660f48.
The code that disables the extension entirely the moment the NavPopups
gadget is enabled was added in 2017 via patch Ia474b1b (T151058) and
patch Ia837816 (T160081).
As of now, the "advanced" option can only be seen in an extreme edge
case:
* Only for anonymous users.
* Only if NavPopups is enabled by default for anonymous users.
* Only if the $wgPopupsConflictingNavPopupsGadgetName setting is
misconfigured.
* … or if NavPopups is not a gadget in the first place, but e.g.
loaded via Common.js.
In this situation the settings dialog opens with all *3* options. This
is broken for several reasons:
* The "simple" option enables the extension, but doesn't disable
NavPopups. Both trigger, resulting in both popups being displayed
the same time.
* Since "simple" is the default, this bogus behavior is the default
for anonymous users.
* The "off" option doesn't stick. Every time the settings dialog opens
"advanced" is checked instead.
* "Off" can't work anyway. There is no code to disable the gadget.
* Only the "advanced" option "works", but more by accident.
It's unclear how to fix this:
* There is no code that does anything with the "advanced" option. It's
not even stored. The behavior of the option is identical to "off".
* The code appears as if "advanced" was meant to be shown instead of
"off". I.e. anonymous users can only choose one of the popups, but
not disable both. But there is no code to hide the "off" option.
* The bug when both popups are displayed was fixed in 2017 via an
entirely different mechanism. Re-introducing "advanced" does not
only mean duplication, it's unclear how the 2 mechanisms are meant
to work together.
It really, really feels like this was just forgotten.
Bug: T278949
Change-Id: Iab21f3a649a5b2f19ebb0d0dbb45ce1450c65678
