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
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
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
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
$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 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
The edit tab should be active as soon as the editor starts loading
(to indicate it doesn't need to be clicked again, and that the read
tab can now be clicked).
Change-Id: I450c53eef64c25e9520d3868b4ecc95204644138
Previously we could log a warning if the user had the editor enabled,
but the page did not support being edited as wikitext.
Bug: T312632
Bug: T314171
Change-Id: I647cb057ed44c155b4eba1b728d6908f8a7abb69
This is send as an associative array. Instead of adding elements that
are null we can just not add them.
Bug: T291729
Change-Id: I28d847941eec865cb255779534eca14ec88f588f
Log a client error when VisualEditor cannot load because of an
incompatible skin (which is not supposed to happen in practice).
Bug: T312632
Change-Id: I2ccfaa584d7a05e10170a66d446bd4e476dcc775
Follow-up to Idae6755c90eacaab1a9daa88c6e28850d427810c. These styles
still used #content instead of the new way of specifying the target
container.
Extra cleanup:
* Don't apply custom styles to #firstHeading when it's outside of
the target container
* Remove unnecessary rule (it was added in 6d8fbd8221 to support
an absolutely-positioned loading toolbar, but it is no longer
positioned that way)
Bug: T310839
Depends-On: Idb2a743c93316786d6d36e1989cf6620a6092281
Change-Id: Ib5e8f98eacf763e360fae79337d3f2733b1a101b
This data attribute, used to give skins the ability to position VE on the
page, should be prefixed with `data-mw` to prevent it being inserted on
the page by user generated content.
Bug: T310197
Change-Id: Ia6f87535f11ccc7aadb26b7dd9e1ac8a867c377c
Defines an HTML attribute, `data-ve-target-container` that gives skins
the ability to choose which element they want to act as VE's target.
This attribute addresses a need in the Vector 2022 skin, where the
default selector, `#content` was no longer suitable to act as VE's
content container and more flexible approach was needed, so that the
skin itself could define which element VE should use.
This selector falls back to `#content` as was the case previously.
Additional change:
Update modules/ve-mw/preinit/styles/ve.init.mw.DesktopArticleTarget.init-vector.less
to account for the planned change to retain line between tabs and
toolbar in new layout.
Bug: T310197
Change-Id: Idae6755c90eacaab1a9daa88c6e28850d427810c
Following the MediaWiki changes from T301203, we should use
the messages 'skin-view-edit' and 'skin-view-create' instead
of 'edit' and 'create'.
(Also remove redundant definitions in extension.json, we load
all messages listed in 'VisualEditorTabMessages'.)
Bug: T310529
Change-Id: If055fa2a4dc009be869425e6c2262c9b62056179
The refactor in I0eaeb987 broke this feature by moving
the call that modifies the response object to after it
is passed to the target.
Change-Id: Id98c1ccabde478540af34ed3356f319ae336590a
This logic has been moved to the relevant extensions which can
now disable VE using a hook.
Depends-On: I47880be15b6ce1a93f389a32aff304cc3b798bcb
Depends-On: If188e8fcceb248738fc625ddd5afec351c01c484
Bug: T174180
Change-Id: I245295373af3caffb1d4cbc288e8d2bd008520b7
This ensures the full loading sequence is shown when the
user opens VE using history navigation.
Bug: T301843
Change-Id: Ia7a641c8bd5a036f23c9da94bc539d8cf66c5021
Previously we were adding an event listener every time the
target was opened, and not removing the old ones.
Change-Id: I0ce609f1d9e2d6fb00b605dcade6f27e7a887b9d
* Append the toolbar before starting the scroll
* If the toolbar is floating set the anchor to full height
immediately. This shouldn't cause the content to jump down
due to scroll anchoring:
(https://developer.mozilla.org/en-US/docs/Web/CSS/overflow-anchor/Guide_to_scroll_anchoring)
But add our own logic for it for browsers which don't support that.
* Now the browser only has to deal with the scroll animation,
and not the height animation of the toolbar anchor at the
same time, making it smoother and less buggy.
Bug: T301773
Change-Id: I61d533d40758d559b03c858e0006ef2e4f0fcd16
This prevents an unwanted scroll when the main edit link is used
and the first section is below the viewport.
Change-Id: Ib99ebe2dc5c105c3fcbd687ef5740166267f5536
This doesn't change the position of the loading bar, but it keeps it
still if any scrolling happens. Previously we expected the user probably
wouldn't scroll while VE is loading, but in subsequent commits we
will trigger automatic scrolling in section editing mode.
Change-Id: I1404ccd77583d808ef79291c6cb4f561e76bd41c
* Find the first section below the top of the viewport
(usually visible) and measure its offset.
* After loading the editor, ensure this heading is still
at the same position on the page.
Bug: T296910
Change-Id: I9a05ea74ba3c19a4a91ddc1bc0afe311851c53e6
It should be possible for extensions/skins to trigger the click event
It should be possible to do $('#ca-edit').trigger('click') so that
Vector's sticky header can trigger the VisualEditor.
Bug: T293159
Change-Id: I58625ffca982edfbc4cdcb14a666d79093e1b89d
They both want to handle the same URLs. If we detect that
DiscussionTools new topic tool will open, then do not open 2017
wikitext editor.
Bug: T282204
Change-Id: Ic7dd677ea219938969f60bab91387c2e03ebdbe6
These don't add any knowledge but make the code harder to read
and maintain, and are an additional source of errors.
Change-Id: Ied57741a3f985e355adfddb4e75378d5c497faa9
This reflects better what the widget actually does.
However, the config option `value` as well as the method
`getValue` are not renamed. These intentionally mirror a OOUI
convention.
Change-Id: I26e733b760501e57b3314d5da2d65bfdd4b38346
We have two preferences used for enabling/disabling VE:
'visualeditor-enable' and 'visualeditor-betatempdisable'.
(And 'visualeditor-autodisable', which sometimes overrides
them both, but it's not relevant here.)
The user can only set 'visualeditor-enable' when VE is Beta Feature,
and they can only set 'visualeditor-betatempdisable' when it is not.
However, when deciding if VE should be loaded, we always checked both
of the preferences. This gives incorrect results when the preference
that is not supposed to be settable actually exists, due to being set
in GlobalPreferences on another wiki where it's settable.
A similar issue could occur if VE configuration is changed from Beta
Feature to a normal preference (or the other way around), and the
preference values for the previous configuration still persist.
Bug: T271434
Change-Id: I7399b3c516f762429050a662ac85d1d392392323
Support the `url-new` mechanism so we can distinguish between
new/existing sections in direct navigation.
Also, mechanism will now correctly be `new` when clicking the "create"
tab on a previously empty page.
Bug: T272544
Change-Id: I667a1c45c3948ec6dfed8f348a1327bffaba58a5
Depends-On: I3cee7a3a4c4b646692dce4a1180c4ba18a61f4bc
Switching from visual editor to old wikitext editor results in a
page reload and loss of the mw.libs.ve.disableWelcomeDialog()
flag. Use an URL parameter to preserve the flag.
Bug: T235812
Change-Id: I3968e5b7ae536d45fd764a8b7c3ea1f6d616033f
Reference images are moved to Cite and used by Citoid.
Bug: T170919
Bug: T171292
Depends-On: I02041246dda1b3d3ad1bcc0b014fa022e8259b62
Change-Id: Id97659ed1fa64a1223a8957fefaf2a149edd0e9c
Remove angle bracket from the url. The closing character is breaking
the hyperlinking and is not necessary anyway. Also bypass redirect.
Bug: T261126
Change-Id: Id9839623f5f77766042a0df0dfdd5f93d6faf625
jquery.cookie is no longer maintained, and we're coming up on maybe
running into issues with sameSite which jquery.cookie doesn't support.
Moving to mw.cookie will let us centralize that fix.
Also, removed some dependencies on jquery.cookie in code that doesn't
seem to ever use it.
Bug: T252597
Change-Id: I8634cfd42c2a5ab3c9d712417a7d1a55508274fd
The first time we check, it's too early for any code that might have
wanted to call stopShowingWelcomeDialog() to have done so (because we
check synchronously after making that function available).
I'm not sure if checking twice like this is the best solution, or if it
would be better to defer the whole thing and only check once.
Change-Id: If5b88bb50c3becaa3d7931c8b8e4d0faed7b69d2
This is now consistent with all other events.
Needed for I9904e8af4a60b0f5e9a6e263cd4fd8e1e3fd1f98.
Change-Id: If52aa9d619eac08456874fc75c0f6e1adff01246
And factor out the common code for using a preference with a fallback to
localStorage or a cookie.
Bug: T235566
Change-Id: Ibb983319edcd2987225fe89677fd10e3ff8f9df6
This allows code in other extensions to suppress the welcome dialog
temporarily (just for that one page view), without touching the user's
preferences.
Bug: T235566
Change-Id: Ief6545289cf59fda851aa944b059994abd90253e
Move shouldShowWelcomeDialog() and stopShowingWelcomeDialog() from
DesktopArticleTarget to DesktopArticleTarget.init, and use them to
deduplicate code in init that manages the wikitext welcome dialog.
Look for both the vehidebetadialog and hidewelcomedialog URL params.
The code in DesktopArticleTarget used vehidebetadialog, but the code in
init for the wikitext welcome dialog used hidewelcomedialog.
Bug: T249954
Change-Id: I19f1a2da36bc65addb52811c3d3c73c1259bc8f5
This unbreaks the use of ?vehidebetadialog=1 on page views (i.e. without
action=edit) in single edit tab mode.
Bug: T249957
Change-Id: I0109f5d95cebbb3e585d25b7623764cc7350cda0
In MediaWiki, section numbers may be prefixed with 'T-' if they refer
to sections on a transcluded page, so they are not really numbers.
Change e2cb9ce93e caused us to treat them as strings most of the time,
but it looks like there are several places where we treated them as
integer numbers, which I missed when making that patch.
The first two changes in ArticleTarget#restoreEditSection fix T248795
and T248968/T249112, respectively. The other changes are cleanup.
Bug: T248795
Bug: T248968
Bug: T249112
Change-Id: I8373a7ab515595769ce6f3051a182c922415b643
Prevent JS from overwriting the contents of the "edit source" link
if the change is unnecessary as it can break third-party skins.
Bug: T248025
Change-Id: Ica1e45488813877583efadabc72526544e8943ac
When a page is preprocessed for transclusion, sections are numbered
differently, and the 'T-' prefix indicates this. It can't just be
removed.
It seems that all of our other code can handle section "numbers" like
"T-1" just fine.
Bug: T246164
Change-Id: If19a2d48f94411a89525fb605169c7f8dd4b1797
This line was added in 9eebfbcac5
and I can't tell what it was supposed to do (that commit's message
only says "Fix NWE-only edit tab", thanks a lot).
Since then the init code was refactored a lot, at some point this
line was moved to be a part of a completely different check (???),
and now it's causing visual mode to be disabled even though the
user only set their preferences to *prefer* wikitext mode.
Bug: T243723
Change-Id: I3c1f502c3cd079fc5eeb2e9587b22d854ae3a72c
This continues to take more effort than all other skins combined, but
still every time our overrides get less crazy. Maybe, and stay with me
here, maybe a year and five patches from now I'll remove the last one.
See 91f99ce78d for the last time.
Change-Id: Id880d1cd1ecef59635b347102dc2107204382fb2
In many places we check whether VE is available before doing things
(init.isVisualAvailable). This variable includes checks for whether
the page is wikitext, etc. Now it will also include checking whether
VE is enabled in user preferences.
In almost all places where init.isVisualAvailable is used, we were
already also checking if VE is enabled, so this doesn't affect the
behavior. But notably, we didn't do it when showing the option to
switch to VE in the welcome dialog and in the toolbar, causing T243723.
Changing init.isVisualAvailable this way makes it consistent with
init.isWikitextAvailable, which has always included a checking whether
NWE is enabled in user preferences.
Bug: T243723
Change-Id: Ie174bc3f16bceb29cb155b9223e0acef70167fd6
