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
