Going through onEditSectionLinkClick() is not needed, and it confused
some code that actually expected a section edit link.
Bug: T328094
Change-Id: I8975ade38d9dd064272781fb9d4bd22bab4d65ce
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
