This creates a message called `editcheck-config.json` which will be
loaded and sent to the `modules/editcheck/config.json` packageFile.
Bug: T330112
Change-Id: Idc58ddf1045fcc0491701a739f3778c8cf4dd955
VisualEditorFeatureUse as feature: notices, action: show.
This doesn't distinguish between the automatic on-load show and manually
showing them from the toolbar.
Bug: T344465
Change-Id: I5a0d7e87592c286afe51e02ae8436f7d2ce71021
I apparently forgot to pass the parameter to fireHookOnPageReload()
that I introduced exactly for this purpose. As a result, the basic
post-edit popup appeared, but the temp user popup did not.
Also rearrange code so that fireHookOnPageReload() is still called if
we need to redirect to complete creation of the temp user.
Bug: T344879
Change-Id: I36c64f27d2b8866ca88642621a135e7e25a91ce1
Abortable promises are definitely among my least favorite things.
It takes all of this bookkeeping to make .abort() work consistently
(so that it always aborts a request if one is in flight, and always
causes the final promise to be rejected even if we didn't start a
request yet or it has already finished). But, if you squint and ignore
every line with the word "abort", it's like a normal promise chain.
Depends-On: Iec8a15dadd595bed0f7e54f907fbb8e192b45cf3
Bug: T331397
Change-Id: I67309c79e6d211d69630fe89cbf5402f8fbd350c
A new hook `ve.preSaveProcess` is triggered to give other code the
chance to add steps to the process. The save dialog won't show until
the process completes. A step can be failed to return to normal
editing.
Change-Id: Id0740ff58ba9d9519c81174100ef1b8f8740870b
When the document store has no entries (e.g. an empty page)
we don't initialise completeHistory with a retain transaction.
Bug: T333710
Change-Id: I5cc4ab3ea5f63a7eab804831df62d5c7ce2447e9
This method was only called, and the message was only shown, when
retrying after the first 'badtoken' error and refreshing the token
fails again.
If this happens, it usually indicates some terrible problem with
the wiki, and it is not something that can be fixed by logging in
again (or anything else the user can do).
Let the default API error message appear ("Invalid CSRF token.").
While not very helpful to the user, it should be more helpful to
the site administrator trying to unbreak their wiki.
Remove the "visualeditor-savedialog-identify-trylogin" message.
Keep "visualeditor-savedialog-error-badtoken", which is re-used
in another error message. I'll fix that separately.
Change-Id: Ib680218bce5ae38aa52d7d941218a6410ab7e09e
This has not been used for many, many years, since we started using
mw.Api#postWithToken, which automatically retries on 'badtoken' errors.
Most of our code for it was removed (e.g. save() is never called
with three parameters), but some comments and parameters remained.
Change-Id: Ibca2a222f808e6e2796ed6a61e9587a646afcf31
Occasionally we end up logging error codes like
"abusefilter-disallowed,abusefilter-disallowed,abusefilter-warning"
when someone hits a bunch of different filtes.
Change-Id: I967d374d13473ca684412b380d732653a3ceaff3
TODO comments suggested using the VE helper util, but
that is no longer necessary since all our browsers
support passive events.
Change-Id: Idb7e702d58931208d555a3f994cd0b73abec2e20
This makes it easier for 3rd parties to insert extra tools
in sensible places.
Change-Id: I6c8d0c96f53655d8f9ae9f01e5d0e1a1678d29a1
Depends-On: Ib8882fa6319915d291b345a69ab95f362739ad7b
This affects logging behavior -- notifying WikiEditor lets its logging
clean up after itself before the init event for VE fires. This was only
an issue when switching *with* changes, because that path resulted in
the timings being cleared, making future events whose timing depended
on the init event have NaN timings.
(This wasn't an issue before we centralized the logging code into
WikimediaEvents, as before that WikiEditor and VE were maintaining
separate timing registries.)
Bug: T237063
Change-Id: Icdb307fa0ce0d1dac3744e4bab41b3588f14777f
Instead of passing a "teardown callback" to a specific dialog,
run the command as usual and clear the loading message once
the dialog has successfully opened.
Change-Id: Icacabb298f1a0d7a587ab8b992759b04ff59c5c3
* Be more specific about the type of context which a
context item belongs to.
* Make grammar clearer.
Change-Id: Ic480411cead80a1651c61ce9841dfbdc24a7b915
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
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
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
Rename wgFlaggedRevsEditLatestRevision to wgEditLatestRevision (not use 'VisualEditor' - this config may be used by other editors)
Bug: T338312
Change-Id: I6c9c46774fe197ca7775b65f12e62bb3bcbe53b4
* Make it always work when there is only a single template anyway, no
matter if the template is selected or not.
* Auto-expand the widget and focus the input field when it receives
focus. The only way it can receive focus is via the hotkey. It can
not be selected from the sidebar.
Bug: T338108
Change-Id: I567a0b99a8ad2e837993437e47f07d62e8b003d2
Some wikis customize the 'pagetitle' in ways that are not compatible
with the client-side message parser.
Depends-On: If1979da12777e4ee4e97937640fc5e6176f9b5fe
Bug: T317600
Change-Id: Ie7c1813552582e10de9e57cd8d772c2134146289
This will ensure that media have the mw-file-element classes so that the
styling changes in I70c61493fe492445702f036e5b24ef87fc3bdf43 apply.
Older 2.7.0 content still in storage is missing the classes and doesn't
render correctly.
Note that I545ed75ed3c87e88b5e776696754e23c05645f81 made sure that
editing of both versions was always compatible.
Bug: T337596
Depends-On: Ia70f819df79fbb12a5b1dd6a98bfe0b968808d18
Change-Id: I40ed887e03f983e0737e1ee7cba5a4012fea31db
Use the new hook to add the diff-mode selector to the area directly before
the diff table.
Also toggles the new inline-diff legend, when the initial diff-type is 'inline'.
Depends-On: I2a3c67bcfa47313dee597e602a62073e4e298cd2
Bug: T324759
Change-Id: I1584a84b3caea9eb142afba976c6ff47650c3832
Support gadgets adding '&editintro=…' to the default edit link.
It was already supported when opening the link in a new window, or
following an external link, or when clicking a section edit link.
Also, clean up these parameters when leaving the editor. This also
applies to 'preload', 'preloadparams', 'preloadtitle', 'summary'.
KNOWN BUG: Only works the first time the editor is loaded on the page.
Afterwards, DesktopArticleTarget.init lets DesktopArticleTarget handle
initialization, and it ignores extra parameters. I made a few attempts
at fixing this, but I only broke it further. I don't understand why
the history handling code even works. Maybe I'll come back to this.
Bug: T56029
Change-Id: I38fcde573f728250aaa125b391815e7fac7df362
I prefer not having to think what type `link` is.
Just pass `linkUrl` everywhere.
Add and correct some related doc comments.
Change-Id: I5aa03149d7e1b32cd9ec19c589b16d03a9981857
Due to changes in StackLayout in OOUI v0.47.0 it is no longer able to
show a panel that was hidden using `.toggle( false )`.
Hiding it in this way seems to not have been needed anyway.
Bug: T337638
Change-Id: I81ed015986ed03fab1e65a7f3a826ac4296077b7
Also supporting changes to support the new HelpCompletionAction,
including adding a preference to disable it if required.
New changes:
985b553cc Localisation updates from https://translatewiki.net.
aa26e27dc Localisation updates from https://translatewiki.net.
4cdc753ab Update OOUI to v0.47.0
bfc96a7ee Completions: always abandon if the first input is a space
616a6458f Fuzzy command bar
92b6525a2 Tweak the fuzzy command bar's behavior
fd2f048e4 Fuzzy bar: change how command groups are generated
Change-Id: Ic77b8822baecf5ad1ab466d94df29bb945172b55
Use MediaWiki core helpers to provide intro messages (including edit
notices), initial page content, and CSS classes for the edit area.
The following intro messages were previously unimplemented,
and will be shown now:
* 'sharedupload-desc-create'
* 'sharedupload-desc-edit'
The following intro messages were previously unimplemented,
but they only apply to pages where VE should never be available,
and will be shown now when editing those pages with 2017WTE:
* 'code-editing-intro'
* 'talkpagetext'
The following intro messages were previously unimplemented,
and are now explicitly skipped:
* 'editpage-head-copy-warn'
The following intro messages were previously unimplemented,
but they only apply to pages where neither VE nor 2017WTE should
ever be available:
* 'userinvalidconfigtitle'
* 'usercssyoucanpreview'
* 'userjsonyoucanpreview'
* 'userjsyoucanpreview'
Depends-On: If0b05710cb52a977bf4e85947d72d68683a0a29e
Bug: T201613
Change-Id: If26e39e383b983f7ee834ed6dd73b80e0545b068
The diff mode selector is now also being returned in the HTML
from the VisualEditorEdit API, but is already implemented
separately. This change just removes the element from the API's
HTML; it is perhaps not the cleanest, but it's not too far off
what is already being done for action=diff, and we want to get
a fix out for this bug as soon as we can.
Bug: T324759
Change-Id: I830b623963111f430640dd4d9a94639f753e4cda
As temporary users will not have access to user preferences (T330815),
use cookies or localStorage to save them, like we already do for
logged-out users.
Also add some comments to point out where we intentionally distinguish
logged-out and temp users.
Bug: T332435
Change-Id: Ic83dd8bc8bc107f603a9b0340bd9e2bcaad8ff5a
Target#actionsToolbar and Target#toolbar refer to the same object
since change dfaed62d3632d381db9682c603b3ddbeed182292 in VE/VE
(barring bugs like T335469). Once we no longer use the old name,
we'll be able to remove this backwards-compatibility alias.
Bug: T335469
Change-Id: I577e8ae6a857519eb0e8181543ca0a96b515e019
It appears like this was never tested.
Now that it is covered it's much easier to play around with the
implementation and compact it a bit.
Change-Id: Ie9cc14082f69e7240380d352fb362d0a3fa4d341
Since this was written, the specificity of the selector it was
overriding has increased, so isn't required any more.
Bug: T335292
Change-Id: Ib3494524f6ddfc2ea59d6d3d13a1a90138cd84af
Use the new hook to add the diff-mode selector to the area directly before
the diff table.
Also toggles the new inline-diff legend, when the initial diff-type is 'inline'.
Depends-On: I6de30bf79eb5ac262285951792782b870d075e00
Bug: T324759
Change-Id: Ifc133856dd793693c3a2722a7b1319dfe74555a2
Reported as happening when a gadget was triggering some calls early in
initialization, presumably before the surface had reached the point
where it had been focused.
Bug: T334930
Change-Id: Idebc31ef042d45acf59d8dceaa7566744233f426
It's possible to specify a parameter with no name via TemplateData.
This confuses the template dialog because the empty string is a
reserved, internal value for parameters that are in the process of
being named.
Fixing TemplateData is not so easy. Therefor this workaround here.
See T333826 for a detailed description.
Bug: T333826
Change-Id: I5f4efd7069e71ba51138a23f3c3cb40e1b50d339
* Use the new mw.track() handlers from WikimediaEvents
* Ensure that 'integration' and 'mode' are set on init
events, since they're not guessed in the handler any more
* Remove the setting of 'editingStatsId' tracking parameter,
now happens in WikimediaEvents by setting an API AJAX option
* Replace ve.track with mw.track in VE-MW, so that we don't have
to copy the events manually here and in other extensions
This must be merged together with WikimediaEvents change
Iace4d53a972396ca5b8713000570cc47c9986034 (but we can't use
Depends-On, because CI requires code here to be removed first).
Bug: T332438
Change-Id: I0ef0a96aafdf89a4ebe32131a85b18c25744bb2c
Peel off some layers, remove some unused computation,
remove code from ve.init.mw.trackSubscriber.js (which
is to be removed in T332438).
Change-Id: I4073b9a2a4b2af06f30e603a9d2a1968203f3b6d
New changes:
1b912ce6b ve.ui.DiffElement: Don't override margin on added/removed block elements
a43720b34 [BREAKING CHANGE] Move ve.dm.MetaList to ve.dm.Document
e7d6d2317 ve.dm.VisualDiff: Include metadata in diff
Local changes:
* Use new ve.dm.MetaList API
Bug: T331925
Change-Id: Id21c122d48519013a5c3325cc4bc316cedcb63f6
Discussed in todays story time. The blue "active" color is mostly a
"reminder with which parameter I interacted last". It's more a
secondary, passive information. In contrast, the gray
highlighting/hover effect that appears when navigating the sidebar
with keyboard or mouse is an active, primary information ("this is
where you are right now"). It's really confusing when the keyboard
navigation indicator disappears behind the blue box.
This patch changes this for both top-level elements as well as
template parameters. The blue text color "shines through" the gray
highlight so we can still see both information.
Bug: T289043
Bug: T311204
Change-Id: Ief6a023d8fde4f6ca0c4b2ea2e831b66e1ea8c83
disableForAnons is used to present a single wikitext tab on
dual-edit-tab wikis, and/or default-wikitext red links.
Users who open the editor and then switch to VE should still
have that preference stored in a cookie when that happens.
Bug: T331462
Change-Id: If2a866cff7e54d2832f6aa22eb268eb125f2d1c2
These haven't been used for a while, and we usually enable experimental
features via BetaFeatures these days.
Change-Id: Iec3a7da3cc962d8ac9416b508780fcdc3ca58d3e
When checking for the presence of edit buttons, we should include
the VE edit button and the MinervaNeue page action link, but not
the "view source" button (which means the opposite: the user can't
edit).
Bug: T312632
Change-Id: I2eb6e833a0489c17cf8360aca61bd8b615e30461
Parsoid will start populating the link content with the alt text if it's
available before falling back to the filename. Preserving what's there
is needed to avoid dirty diffs during the transition and for cached
content. In the future, we can remove errorText and replicate Parsoid's
new behaviour..
Bug: T273014
Needed-By: Iddf3e204d6e489cc8a33034da0d9e540efe65553
Change-Id: I7ab3d141b1df92d4447f7e3d6164082844d5bd10
Going through onEditSectionLinkClick() is not needed, and it confused
some code that actually expected a section edit link.
Bug: T328094
Change-Id: I8975ade38d9dd064272781fb9d4bd22bab4d65ce
This allows VE to support even more skins with minimal or no changes to the skins themselves.
Partially reverts 75ff121b29.
Change-Id: I7536610459b7401015d4a033cc516c5d9a0ca5f1
onWatchToggle didn't cope with the case where there was already an event
in the hook-queue when it was registered during setup
Bug: T328955
Change-Id: Ic80f707e86ba3c9f88097cac8aec8c6b3cc32cee
New changes:
0cf02db3a [BREAKING CHANGE] Pass Target to UI Surface and use instead of ve.init.target
Local changes:
* Pass target to surface
Bug: T305762
Change-Id: I3412c53cc70346c8ba4b8b76976ba9c7535e945f
This reverts commit a92dce4999.
A workaround for the previous problem was added in ContentTranslation
in I945897a27db479986855002b389034a745bf9bef.
Bug: T325249
Bug: T325566
Bug: T327779
Change-Id: I2d9c330dc4328468a65315ec6bed1d0f53ebd1f6
We could do something more complex and compute the height of the
available space, but a fixed height is a reasonable solution with
a fraction of the complexity.
Bug: T328048
Change-Id: I0b7bfa55f23afc16be43b85270666ec6a480ca32
Accounts for the use of CSS Grid in Vector 2022, in
the 2017 Wikitext editor preview, by placing the heading and
content in named grid areas (`titlebar` and `content`).
Bug: T327778
Change-Id: I66a30e282e808559b4f375f5924ae0d945c058a9
At first I was going for a more minimal replacement of mw.Uri with URL,
until I discovered that this code depends on a mw.Uri bug that would be
difficult to replicate:
// Expected: Relative URLs are accepted
new mw.Uri( '/foo' ).toString() // => 'https://localhost/foo'
// Expected: Protocol is optional
new mw.Uri( 'example.com/foo' ).toString() // => 'https://example.com/foo'
// Unexpected: Treated as empty domain with no protocol rather than relative URL
new mw.Uri( './foo' ).toString() // => 'https://./foo'
So I went for a bigger rewrite to preserve the intent rather than the
exact logic.
I had to change some test cases to use more realistic fake data. They
previously relied on bugs in our URL handling to pass despite the base
URLs being incorrect, particularly for non-short URLs (see T270219).
In my testing non-short URLs behave the same as before in practice.
Depends-On: I07a8c097dba0f5572c0aedf4febdf1434063ea6f
Bug: T325249
Change-Id: I232361266c1dda795b88018c3aaa3d9ecbe42b93
New changes:
2201b350c Localisation updates from https://translatewiki.net.
da74736c1 Remove unused test code
d1b016e90 Minor test tweaks
551de4f0c Specify document base URLs in more test cases
Local changes:
* Specify document base URLs in more test cases
Change-Id: I0e301bef38d97fa2234aa901c787360d9fbde8a3
New changes:
4355d697a Replace ListStorage with ConflictableStorage
978061f86 Update SafeStorage and ConflictableStorage with expiry functionality
79019ed88 ve.dm.Surface: Support storage expiry
Local changes:
* Pull through conflictable storage
Bug: T218663
Change-Id: I36e49c01e9f2ddb7d362d539b72a4beca925bcb7
Before the `height: 2.5em` was applied to _both_ the visible
<textarea> and the $clone. While this shouldn't make a difference –
one of the first things .adjustSize() does is setting the $clones
height to 0 – it somehow triggered that Firefox bug.
With this patch we remove the `height: 2.5em` before handing over to
OOUI's .adjustSize(). It looks like this fixes the issue. We might
be able to revert I7560ceb then.
Bug: T317369
Change-Id: I96c2d7d7bf359ff0373d478b2b7e97c8833ba5b6
Persistent global-ish properties in ArticleTarget and friends. A lot
of our own code re-uses them, and code elsewhere could refer to them
as well (although I didn't find any uses).
In one case we need to keep using mediawiki.Uri, to handle building
an array from query parameters exactly like PHP would handle it.
Bug: T325249
Change-Id: I57699ff9dd39179ca29a87b6e2d9b12c2b86eb7d
Our encoding for the hrefs like "./Foo" that we send to Parsoid
differed slightly from how Parsoid outputs them, so to avoid dirty
diffs, we had to store the original ones we received from Parsoid
and send them back if they were unchanged.
Change the encoding to match Parsoid's exactly (by referring to the
Parsoid source code), and then remove 'rawTitle'/'origTitle'.
On a historical note, 'rawTitle'/'origTitle' were originally added to
fix other issues with links, which I hope are long behind us:
* bb45d984ca (T145978)
* fda2e6c1b5 (T44140)
Follow-up to 362df66b47, which removed
some other old stuff from the handling of Parsoid links.
Bug: T325766
Change-Id: I0ad0a655380eb2fb29b5ac01e2e399ac550ce34a
Replacing one-off uses in various auxiliary features: only used
in function scope (or narrower), nothing else depends on them.
Some of them didn't even need to do any URL parsing or formatting.
Bug: T325249
Change-Id: Ia9a18656f67cb0a204c87605459abb9f5bbdc347
Adding the polyfill as dependency to everything using mediawiki.Uri,
so that we can change the code in separate commits without thinking
about this.
Bug: T325249
Change-Id: I8a7d2e6c7f98ed6187a85a88f2b4a0a4a5ecfc56
I've never liked how this looked, it feels so 1995. Let's just use
multiple paragraphs instead of a <hr> to separate the text, similar to
what we do in ve.ui.MWParameterPage. The second paragraph is already
emphasized with italics.
Change-Id: I324cd1d81e61cf8a23095b4f8aed68040eb1bd8d
By using OOUI 'label' instead of 'help', the label is associated with
the input using <label for=...> in HTML.
The result looks almost the same, except for font size. I like the
change, and I don't think it was intentional to make the font smaller
here.
Bug: T277028
Change-Id: If178ca8feb9970c9287ab6dfe51fdf0a81df1c45
Use distinct messages for section heading, button label and input
aria-label, to allow a potentially better localization.
Bug: T304121
Change-Id: I3e3b06a035e2f11f5f32face789b934e22916e49
The ARIA label was added via Ieeb29de. It was reusing an existing
message.
Later we added a placeholder to the same input field via I07c6e60.
Since then screenreaders possibly read two texts: "Find template" and
"Add template".
Bug: T296465
Change-Id: Icb8d5419b4a4e34a224744873c557cb873e17c40
While at it, also fix a few broken uses of `@see` where `@link` was
intended or for full names, there is no syntax needed, as JSDuck
already links those.
Change-Id: Iaeb46b05c6f2e6f00198bc2ae773c895935b4cea
For external links, `.title` and `.rawTitle` properties previously
contained the external link corrupted with some normalization intended
for MediaWiki titles.
This was useless, and in fact no caller actually uses this value:
they all check `.isInternal` first before accessing `.title` or
`.rawTitle`.
Also, correct other parameter documentation.
Change-Id: Ieeab56548f0a3b2f81a90f0d3ae0f81d744aa67b
An incorrectly-encoded fragment is allowed-in-wikitext but will make
mw.Uri throw an error. e.g. `[[foo#1%bar]]`
Bug: T324976
Change-Id: I97cb85507d9ae3d648300245dd7e48cc239c4d90
Redlinks now come down with a `mw:LocalizedAttrs` typeof, and have the
display URL parameters rather than being bare titles.
Bug: T324352
Change-Id: Ia1776e6e1f171d227c7c402b39ca96d17fb56cdb
There are some known bugs that we probably will not investigate
(T313809, T317455). Do something better than an infinite loading bar.
Follow-up to ee7c5d9d1a.
Change-Id: I339de7662ff68c2ea9bb1a738bb4207d1c399e59
Hiding '.ve-init-mw-desktopArticleTarget-editableContent #toc' is not needed
when we already hide '.ve-init-mw-desktopArticleTarget-editableContent'.
Change-Id: I9f7dc5f64be1f392e846da5bcfcd0a5d17a65014
The "uneditable content" styles should not be applied if the page
title is outside of the editor, like on Vector 2022 since T310839.
Bug: T322725
Change-Id: I212e41e3770807d43b4c58377ce77f4521e6b489
When using DirectParsoidClient, switching should be lossless.
Depends-On: I86c611fa0b717ef619e5ffe550b6c2be49a28c99
Change-Id: Ie30ccbc8c12ce48f481b9f727f28e60d21ee37b9
I discovered recently that I had 64 KB of text stored in the
'visualeditor-findAndReplace-findText' preference.
I must have accidentally copy-pasted a whole page into the "Find"
field, the JSON that VisualEditor tried to save became invalid after
MySQL chopped off the string after 64 KB, and since then VisualEditor
was unable to update the find-and-replace dialog preferences.
Change-Id: Ib1d853263d873d969c7b015b3842524e1f7fc351
Follow-up to 8101b6511e.
$toolbarPlaceholder.outerHeight() only needs to be added when not
using visual section editing.
Change-Id: Idc7d9d59dea9eacbb8ee584c69e6bc4798562ea1
There's nothing we can do about missing edit buttons - they are likely
being scrubbed by some script or gadget, so let's not report the error.
Bug: T314952
Change-Id: Icf778074026a24561c228cbf11e583062571d0cb
Follow up to Icd227fc54f3bc16d5ce84c419b69344ca0d21f28
Currently showing up in logs as "NaN" but logged elsewhere
so not needed.
Bug: T314952
Change-Id: I0bf0d428384aa35bd43be026d451d62a2c237267
We need to strip the protocol on both sides. This might have been broken
by Ic00b38b04ce78178c64c13bab7f1b2e4b6c5b803 in MediaWiki core.
Bug: T321437
Change-Id: I11903b767aebfdb189a8d54fbf6fb7f8ce9ffb6a
The VisualEditorFeatureUsage instrument is a candidate for migration to
the Metrics Platform [0]. The first step of the migration is to log
events both using the Event Platform directly (i.e. via
mw.eventLog.submit()) and using the Metrics Platform client (i.e. via
mw.eventLog.dispatch()).
The Metrics Platform Client can mix in additional information -
so-called context attributes [1] - based on the stream configuration.
The majority of the default values mixed into each event are already
known to the Metrics Platform Client.
Note well that the Metrics Platform client will not log an event without
one or more streams being configured to receive that event. Therefore,
this change is a NOP.
An example stream configuration is given in [2].
[0] https://wikitech.wikimedia.org/wiki/Metrics_Platform
[1] https://gerrit.wikimedia.org/g/mediawiki/libs/metrics-platform/
+/aed6738b845/js/src/StreamConfig.d.ts#31
[2] https://phabricator.wikimedia.org/T309602#7973206
Bug: T309602
Change-Id: If40fcc6cae371788b98365953218300a5c0b3ca1
... for the sampling rate for the VisualEditorFeatureUse schema.
Bug: T312016
Depends-On: I259757db0c4441a3fcfce505d5bc82dcf2acf58c
Change-Id: I4e03b442568ed695a14d280b0e8dd92e22616426
The previous implementation tried to do this, but looked
at the query string which can be set to action=edit by VE.
Bug: T318772
Change-Id: I4f0f8d52488a6b259033232afb8ea616458275de
Setting the config var then loading mediawiki.action.view.postEdit
will already trigger the notification code, so we can remove this
duplicated code now.
Bug: T240041
Change-Id: If0d1aa4e734dab7cca168e78216f229b9924bab7
This makes the "direct" client and the VRS based client
implement the same interface, so the caller doesn't have to know
which one it is using.
It looks like ParsoidHelper will not be needed if we use this approach.
Change-Id: Ib1c1d7355951fc0765227dd01a9edfc554fc448d
A lot of this just repeats what is already set by some other rule,
e.g. because it is the OOUI default anyway. Warning. This patch is a
little more agressive. I tested it on desktop and mobile, even with
MonoBook, and could not spot a different. Please do some more tests.
Change-Id: I0ee6e70f4f14c20d431643c53031d6d5b8df1aa2
$targetContainer was calculated at the top of the file,
but it's only guaranteed to be available after jQuery ready event.
Bug: T314952
Change-Id: Id5d0c71433bfc51cb7193ee1b931a7dd8a4324d9
Factor out getAvailableEditPageEditor from getEditModeFromUri
and use instead of getEditPageEditor everywhere.
Bug: T316776
Change-Id: I34bab092b829124c52f8bc0e262a9c3aa17f2c52
This means if you load the editor on a single edit tab wiki,
then press back then forward, the editor will re-open.
Bug: T316869
Change-Id: I1ea33de7d7324a53399be9155c474a14ae21dfe8
This code is supposed to be similar to the code in activatePageTarget()
however it was checking if the *link* URL looked like a veaction link,
not the view URL. It also then tried to push this.href as the new state
which was always undefined. This meant:
* If the section edit link was veaction= then nothing happened. The URL
in the address bar would get updated *after* the editor loaded by code
in DesktopArticleTarget.
* If the section edit link was edit= (single edit tab wikis) then the
view URL would get replaced with and edit URL, meaning if you browser-
backed out of the editor, the URL was stay as the edit URL.
Bug: T316771
Change-Id: Idb5e3c51a22361e0d9916d3c31444daeff310ed2
This fixes two issues:
1. .initializeAllStickyHeaderHeights() is now executed after the
.ve-ui-mwTransclusionDialog-single-transclusion CSS class is set.
This is critical because in this mode the sticky header does
have a different height.
2. We get rid of 2 references to .sidebar that should not have been
in this class in the first place.
Also bring some more calls in an order that makes sense. This does
not make a difference and is only for readability.
Bug: T315292
Change-Id: I22f6c11de8f693edb03485adcaa186bd4b283b2f
I'm pretty sure this extra call is just pointless. This "choose"
event is triggered every time a new parameter is added to the list of
parameters. But there is another code path that is triggered in the
exact same situations: the onReplacePart event handler.
As far as I remember this "choose" handler was added very early when
the other events haven't been implemented yet.
This should be fairly easy to test. The only situation where this
could make a difference is:
1. When you have a template with 3 parameters and you add a 4th
parameter.
2. When you edit an existing multi-part transclusion that contains a
lot of parameters, but the parameters are initially hidden. The
widgets are only created when you click "show all" or start
searching.
Change-Id: I59e3873a4fe6fa5a01d681fce89fbe00756ae815
This was missing when you:
* Insert a new template and select a template with a lot of
parameters.
* Same when you edit an existing multi-part template and add a new
part (Ctrl+D) with many parameters.
Bug: T315292
Change-Id: Icd281c21a1b40d8e29343fa4975e27e8d927cd15
This is only an issue when a long parameter description is collapsed.
The float is a left over from a time when there was a delete button
on the right side of each parameter label. This is gone.
Bug: T310137
Change-Id: I249f0592de9c73a07af22bd7f86241caf0207770
This makes it possible to click on "(undocumented parameter)"
to focus the input field – the same effect as when clicking the
parameter name.
This also lower-cases the initual "(U…". This is not the beginning of
a sentence.
Change-Id: Ibfa5bbaee39c2b3a4fefbcee33102b85ca3ba9c0
On mobile, tapping anything in the sidebar should only scroll the
corresponding element into view, but not focus the input field. The
reasoning is that an on-screen keyboard should only pop up when the
input field is actually tapped.
By the way, the "jump" issue in T312768 was because of the same
reason. In that case an onFocus happens before we have a chance to
scroll. Unfortunately there is no way to reverse the execution order
of these. Which is why we disabled the animation there.
Bug: T289043
Change-Id: I1c18802b8ff776fa8d9c17e3df8020354690d29f
This patch follows the audit made on the extensions to check the usage
of the "rel" attribute and check that it's compatible with multi-values.
Bug: T315209
Change-Id: Ib323736d93ea96c86f9d56599e515c9e6d72a76e
