The popup contains three buttons, one of which already exists
in core as a tool. By converting them all to tools we can reduce
some duplication, and better integrate with other features
that use the tool factory, such as HelpCompletionAction.
Bug: T339153
Change-Id: I81d217bc1ab9a1a6a9bf7c7ad588c2a3216b10db
New changes:
18b02fdc2 Remove deprecated ve-ce-surface-enabled class
669699d6b Rename generated distribution file to desktop-dist-wikimediaui.html
Bug: T340124
Change-Id: I5b173a96817f4217824d8b132c96c8082c568b17
New changes:
c46173a95 Localisation updates from https://translatewiki.net.
7cf3264b3 Localisation updates from https://translatewiki.net.
64a30dd23 Update language lists
eaf8355e0 Localisation updates from https://translatewiki.net.
4d3a8104a Make better use of toolbar groups
Bug: T340751
Change-Id: Iddab40b928944cfb43846e5d0b22b01c2df2d213
Especially useful to reduce the job runtime here because the VE
tests are executed in a couple of CI selenium jobs of other
extensions.
Bug: T226869
Change-Id: I8a8eae8cf2d548b7c905f00e748974bc5a88d337
Setting `$wgVisualEditorUnifiedPreference = true` makes the VE enable
preference appear consistently on the preferences page, while still
being backed internally by the old 'visualeditor-enable' and
'visualeditor-betatempdisable' preferences.
(It effectively overrides `$wgVisualEditorEnableBetaFeature`, which
needs to remain unchanged to use the values from the right preference.)
Bug: T335056
Change-Id: Iad710a769c7176c4673c475d540dff2b7782e159
Previously, this code relied on 'visualeditor-enable' being set to '1'
when VE was opt-out (so not using that preference). That default does
not make sense for a beta feature (which uses that preference), so WMF
config was overriding it to 0 when the beta feature mode was wanted.
Instead of making assumptions about the default values of preferences
that depend on whether beta feature mode is enabled, just check the
beta feature config.
I also added and updated comments documenting this preference.
Previously I never really understood what it was for, and I think
I figured it out now.
Bug: T340696
Change-Id: I45eef42939149ff5be63bf299c48ef70ee535e76
This reverts a change from 5a792b6558. The hook only requires
a PageIdentity, and we only used toPageRecord() because it takes
a parameter to read latest data, and toPageIdentity() does not.
Instead call another method to update the internal data within the
Title instance. Maybe it's not great to rely on this side-effect…
Bug: T340568
Change-Id: If9cbd95eb84b6c39bf50af4564710839628a9bc3
Using the OOUI class name is an established pattern outside of
OOUI widgets, so it's easier to stick with it for the diff page
hiding and showing (switching to and from inline/table diffs, etc.).
Depends-On: I805b6b71d8e137eaa3e000b15455557df42af838
Bug: T324759
Change-Id: I0300b40d4e79319592bfc1f57912460f65c7051c
React to hooks fired by core when the inline diff type switch is
present. VE needs to be able to disable the inline switch
when 'visual' mode is selected and enable the switch when 'wikitext'
mode is selected. When the 'wikitext' mode is selected and there is an
inline switch, the interface needs to show the diff type format previously
selected.
Toggle using new `mw-diff-element-hidden` class that is used by core so
that there's no clashes when hidding and showing the diffs.
Bug: T331589
Depends-On: Ie6a48e495f2bb299d8b984e7c40363d534c7915b
Change-Id: I4f790370dbfeb521f3b61c4d604245f77094abe9
After the demise of RESTBase we are always able to switch from
wikitext to visual mode with changes, and we no longer need to
support these two poor experiences.
Bug: T339871
Bug: T339872
Change-Id: I2be4068447b21e16c87db0e56d6422ea64ba4708
No longer used since 1.33
Automatically removed message keys with "doc-apihelp-description" in qqq
Bug: T340253
Change-Id: Ic3d031da376b78d3ccfec27517ec9a288c54fdc4
Sometimes we call this API and then reload the page (or navigate to
another URL), without using the page content it returns. Save some
work and some data transfer and don't generate it in those cases.
Change-Id: Ic5fac61f3ef9b2dfce6ff757f1d414a9f41f217d
Undo some changes from 95454e710f1b619f7c538bc1dc88f238409719ca,
as this functionality is now provided by the core code.
Depends-On: I1c9020b2efb2785279f5c09539a49208a310ccf7
Depends-On: Ifeffcf214719f0d5c1371dc7d51a410fb313c978
Bug: T338003
Change-Id: I90a618897699c844f9c558bbeb4d1563f8050fe3
The user has already seen the notices, and getting hit with yet
another popup doesn't feel nice.
Bug: T169179
Change-Id: I421e42d32cb67ea210644b705e9c6e5af74e75ee
Before this change DesktopArticleTarget's history management was not
working correctly because .currentUrl was not being updated on every
activation, and we worked around this problem by activating it in a
different way on subsequent loads in DesktopArticleTarget.init.
Fix the first bug by updating .currentUrl whenever we activate it,
and remove the guards around the normal way of activating it, which
fixes the parsing of 'editintro' parameter.
Bug: T56029
Change-Id: Ifd6af60cdf1d2c87536017b316ab8da1f5133400
The edit intro message is now shown again when closing/opening
the editor using the back/forward browser navigation,
and it is preserved when switching between VE and NWE.
Bug: T56029
Change-Id: I12083926341a6d3ba4c7a9f84736cddc7f2ac0fa
In Vector the edit tab links have an extra <span> inside, and so
we couldn't find the parameters in the <a> href, because we were
actually looking at the <span>.
It worked in cases where we override the edit tab labels, since
we trample over the spans, e.g. in multi-tab mode.
Bug: T56029
Change-Id: I96935490418d7c3be4d417aaa71cb6e9608fd77f
This code was identical to what happens if you just call
reloadSurface(), except for some half-hearted error handling.
We already do it this way when switching from NWE to VE.
Change-Id: I8027680b7ca272930b951d0403594679ef308083
The 4th parameter is a boolean 'modified', not a node. I'm not sure
what this was supposed to do. It looks like the parameter was being
ignored in all cases anyway.
Change-Id: I559ab2bdb02c4a3e39b44487cf36122332d61fd1
Having per-wiki statistics is neat but expensive. Now that VE has been
switched to not use RESTbase on all wikis, Go back to collecting
all stats under a single key. The relevant dashboards have already been
adjusted accordingly.
Change-Id: I9666bfa3fed547f3f619a9e0c9c24b9240edc359
