This reverts commit a6a65204c6.
to restore custom preview types.
-- Changes since revert
The previous patch accidentally removed the syncUserSettings
changeListener. This has now been restored with several modifications:
* We have a migrate script which rewrites existing localStorage settings
to the new system
* The existing save functions are generalized.
The changes since this patch are captured in
Ia73467799a9b535f7a3cf7268727c9fab7af0d7e
-- More information
A new REGISTER_SETTING action replaces the BOOT action for
registering settings. This allows custom preview types to be
associated with a setting. They do this by adding the enabled
property to the module they provide to mw.popups.register
Every time the new action is called, we refresh the settings
dialog UI with the new settings.
Previously the settings dialog was hardcoded, but now it is generated
from the registered preview types by deriving associated messages
and checking they exist, so by default custom types will not show
up in the settings.
Benefits:
* This change empowers us to add a setting for Math previews to allow
them to be enabled or disabled.
* Allows us to separate references as its own module
Additional notes:
* The syncUserSettings.js changeListener is no longer needed as the logic
for this is handled inside the "userSettings" change listener in response to
the "settings" reducer which is responding to
SETTINGS_CHANGE and REGISTER_SETTING actions.
Upon merging:
* https://www.mediawiki.org/wiki/Extension:Popups#Extensibility will be
updated to detail how a setting can be registered.
Bug: T334261
Bug: T326692
Change-Id: Ie17d622870511ac9730fc9fa525698fc3aa0d5b6
Changes to the use statements done automatically via script
Addition of missing use statement done manually
Change-Id: Ib30da35841aadb558709dbbe6e30be2241048c87
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
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: I0c66220b0ba9501e8ef20a172d21d7e75a19d6cc
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
Also restructure eslint config so that
* root files are linted with server rules
* src and tests share config
Change-Id: Ie4d0731ba9670af7f3e60cdfe3c4e331386b17c6
This reverts commit 6924a89b07.
Reason for revert: Breaks persistence of setting
for anonymous users.
Change-Id: I3efc20f44281c1c68c4162584388e33bb38c4848
A new REGISTER_SETTING action replaces the BOOT action for
registering settings. This allows custom preview types to be
associated with a setting. They do this by adding the enabled
property to the module they provide to mw.popups.register
Every time the new action is called, we refresh the settings
dialog UI with the new settings.
Previously the settings dialog was hardcoded, but now it is generated
from the registered preview types by deriving associated messages
and checking they exist, so by default custom types will not show
up in the settings.
Benefits:
* This change empowers us to add a setting for Math previews to allow
them to be enabled or disabled.
* Allows us to separate references as its own module
Additional notes:
* The syncUserSettings.js changeListener is no longer needed as the logic
for this is handled inside the "userSettings" change listener in response to
the "settings" reducer which is responding to
SETTINGS_CHANGE and REGISTER_SETTING actions.
Upon merging:
* https://www.mediawiki.org/wiki/Extension:Popups#Extensibility will be
updated to detail how a setting can be registered.
Bug: T334261
Bug: T326692
Change-Id: Ie11057052fb9035944f2b79a17fb486f97102994
The previous selector in the case of the first reference link
matches two elements - one in the "Reference links" section
and one in the "References" section.
My hunch is this leads to the test failures we have been seeing
Bug: T344072
Change-Id: Icda37b4f46add4049344f7a8c452082d7b0df5c8
- 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
TestUser is expensive and requires DB access because it creates the user
in the test database. That is not needed here. For these tests, a mock
is enough.
Also make PopupsGadgetsIntegrationTest an integration test, to fix a
local failure and in view of I0a04c82250582fed7a66c1e10868d9b4f3823a28.
If a test is testing the integration of X with Y, guess what, it's an
integration test ;-)
Change-Id: Ie8b3376ce97b9ddc67746f7754b92628c5ab9470
Dwell delay varies between popup type so should be part of the
definition. Since this is needed by reference tooltips we should
make this part of the Page preview model. This will allow us to
separate concerns of the architecture and reference tooltips
for better maintenance between WMDE and web team.
Bug: T326692
Change-Id: Ia021c8b90fd69d70c4b33744520bb963a65db036
I also removed the bool on the shouldUseReferencePopupsBetaFeature
method. It was always just used with `true`
Bug: T293072
Change-Id: I1a2d6f912fcac2ac77539581897e0feab489edf0
- check if the element has the function in it before using it
- implementing a native code to get the same result based on polyfill examples
- fix Coverage Block
Bug: T340081
Change-Id: I1c2ce46a88cde6323ab862964062dd722ff5edcb
Includes a bit untangling of the reference and page previews tests
and simplifies the setup.
Bug: T337862
Change-Id: Ia92cccb90fd79d10c5b33744520cb963a65db046
Types should not have spaces in them. In the current example this
results in a page preview element with an additional class "<"\'>"
I'm not sure what this is protecting against since we can trust types
to always be in a sensible class friendly form. It would be better
to throw an error in the mw.popups.register function than allow this.
Change-Id: If08c5162c1ca0fc3db4944092231061e22113263
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
As part of T310054, we moved article tabs into
the #content area on the beta cluster which caused
the daily tests to fail. As a result the page previews
test is currently expecting a page preview to show
on hovering "Article" which is not the case.
Update selector to target links in the parser
content
Bug: T310313
Change-Id: I0bbccbbfbae458d5c32eaea12f855b832b52491c
