Allows users to know when the widget has been constructed,
and access it (e.g. to set an initial selection)
Bug: T185279
Change-Id: I3678996bcf644cc889dd168ac3ce48b5c3633ec1
This line isn't solely for supporting FF52, that is the order
in which it is called (move after attach, not before),
but that matches all our other widgets, so not sure
it needs commenting.
Change-Id: I6f3cc5687f1e4b995dff700d0765d14de1927d51
mw.storage catches errors, so we won't crash horribly when the user has
localStorage disabled / full.
Bug: T181822
Change-Id: I212994eb535b9a8fb5f6c09deaa10b16c3d7f10e
Tell browsers we explicitly want spellchecking on the section title. If
unspecified this is browser-dependent, so it was inconsistent.
This won't actually have an effect until the next OOjs-UI release (v0.24.3),
as this was a new feature added to TextInputWidget.
Bug: T179654
Depends-On: Ifdd44ead7d782288aaef0979322f0943f7304835
Change-Id: I588874efcff91c5be03da2fc03c268f883b718e2
We were reimplementing (incompletely) the setup from the .init version. Just
call the original, modified slightly so it doesn't over-setup on repeated
calls.
Bug: T151021
Change-Id: I65bd7c5ecf75c478d6babeb13e7fb2a76a9842c8
The whitelist isn't checked for blacklisted browsers,
so if all non-blacklisted browsers are whitelisted,
set the whitelist definition to all (null).
Change-Id: I8ee3569d9d5be2eda9153f1b087c1be385f93d9c
* Rename 'deactivate' to 'tryDeactivate' as it may prompts
the user to deactivate.
* Merge 'cancel' and 'teardownSurface' in to 'teardown',
extending the parent method.
* Rename elementsThatHadOurAccessKey to $saveAccessKeyElements
and move teardown to parent class where it is setup.
* Move toolbarSaveButton teardown to parent class where it is setup.
* Cleanup changeDocumentTitle
Depends-On: I9d97614695272dca6936ef6f3461178fcf0368a8
Change-Id: Ie998a04c21f6615b4415edf471310db5edca3b5a
This code is meant to fix up the tabs if wgVisualEditorTabPosition
was changed and we're seeing cached HTML with the tabs in wrong order.
But it seems it has never worked. `$caEdit[ 0 ].nextSibling` is a text
node and obviously not equal to `$caVeEdit[ 0 ]`, and vice versa for
the other case. The logic is actually correct, so let's fix it to skip
over text nodes.
Also, remove a stray 'eslint-enable' comment left over in
a0f934ed26.
Bug: T50017
Change-Id: I23663a9bfcfdbf52918452c878a128e6960b1191
Vector no longer does the silly thing where the tabs are reversed in
the HTML in RTL languages, so we must remove our hack to do the same,
since otherwise it reintroduces the issue it was intended to prevent.
This essentially reverts 2efd4f0061.
Bug: T50017
Change-Id: Ibeaa55bc34899bffab849ea8ad8b127fb5184d43
The default value of target#pageName is wgRelevantPageName
but other targets my override this, or change it dynamically
(e.g. ContentTranslation).
Also remove duplicate setter of pageName in mw.ArticleTarget,
already set in mw.Target.
Change-Id: Iebd1def1d4142978a673afec584a0b663644d176
* Tiny fix to 33dc60838c for PHP variable name
* Bigger fix to properly pass preloadparams in and split them up
Change-Id: I844db115f2563cb9ee1629c30d5f49d1ce58f5bd
This allows the use of the preload and preloadparams query parameters. They
should behave as they do in the old editor, loading substituted content in
visual and source modes.
Bug: T51622
Change-Id: I522fb5b480d17912f6d6116be6aa043ead855b52
Other page state is read directly, rather than passed in.
If we come up with a use case for passing this in at a later
date we can reconsider the best way to do this.
Change-Id: Iee7e608c969776b89dbb38b3b56a5177e48344af
This stops the welcome dialog from being displayed repeatedly if the user
edits the article multiple times in the same pageload.
Bug: T170983
Change-Id: I8cc5990e9acb1ac09a2d6dd95eef8042c70088c7
"Welcome to wikipedia, anyone can edit, we welcome all improvements. Start
editing!" is a bit out of place when what you'll see after clicking "start
editing" is "you can't edit this page".
Bug: T138715
Change-Id: I9f655a5f12d4e45644bd01631c2d3131375d8e8f
Add 'require' to eslint global whitelist for this extension,
since ResourceLoader provides this in all contexts now.
Bug: T166254
Depends-On: I0e6a95bd4fbaba06eae5137ac7af84f62bebf6f0
Change-Id: I6b2fe57317dcff18ec6d9ea0cd9e4eb9c894c169
Follow-up to fefb76eebc. Prior to that
change, the condition for this looked like this:
// … if on a ?veaction=edit/editsource page
(
isViewPage &&
uri.query.veaction in editModes &&
(
uri.query.veaction === 'editsource' ||
init.isVisualAvailable
)
)
In the refactor, the `uri.query.veaction === 'editsource'` check was
lost.
Since that code is pretty messy (probably predating the source editor
and hastily adjusted), instead change the check for `isVisualAvailable`
to just `isAvailable`. If the requested mode turns out to not be
available later, the editor will not load.
Bug: T165146
Change-Id: Idfaf9115dd20cec8f8e044a704b93b07984cdcee
Ideally we could use the preferred editor, but this breaks
tab switching to the old editor.
Bug: T165238
Change-Id: I5f5ee5566cdd2080ba7c89d43cf127b457537768
We added support loading NWE from action=edit in I35208cce069
but missed this check in the front-end.
Bug: T165238
Change-Id: I2732eaa81a3f968b34c4e878b2ad36de981dd567
Using the forthcoming wgRelevantPageIsProbablyEditable.
Bug: T165010
Depends-On: I6c6ca1cfd93e7be917952980f1e1d57aec3a1292
Change-Id: I6c6ca1cfd93e7be917952980f1e1d57aec3a1229
* Do not try to load the editor on protected pages, or if the user
doesn't have permission to edit pages.
* Move the check for required DOM elements after the check for
pages without the editor (T162411) and after DOM ready (T163307).
Bug: T162411
Bug: T163307
Change-Id: I8149694ba8155682701f2cda6ca212d60f446caa
Expanding from a single if-expression lets us make the
code much more readable, and reveals some minor bugs.
Change-Id: I49e57bfc093e019c837a73eab5c25fdbd14de0af
Previously we completely disabled the loading of notices
when switching, instead of just not showing them (so they
don't clash with the "switched" popup).
Bug: T162812
Change-Id: I3f8e787630e196cee1dbb1aa449b3558b74fcd04
This is run after the targetPromise completes (via the platform-agnostic
setDefaultMode proxy), which is the correct time to do so. We should not
do this twice, and we definitely shouldn't do this before the target has
successfully loaded, lest a user ends up with us setting their option to
"prefer" an editor that they actually can't load. Whoops.
Bug: T156316
Change-Id: Icf4b5ddd9c8265ade55f43328f807344b41db350
New changes:
dc0cad28c tests: Factor out ve.dm.TestRebaseClient/Server into their own files
98061108b Convert RebaseServer tests to data provider
3e746a51b Update OOjs to v2.0.0
16231a812 [BREAKING CHANGE] Drop support for Internet Explorer 9
64daeb4b5 Localisation updates from https://translatewiki.net.
3310e876c Update DOMPurify to 0.8.5
579033a83 Follow-up 16231a81: Drop IE9 support in createDocumentFromHtmlUsingIframe
Bug: T162277
Change-Id: If17c6a3fac0920db29f80069f344ffd6be46c3c9
The bare minimum of elements that must be present on the page for
VisualEditor to start and mostly work is:
* '#content' to attach our interface (toolbar etc.)
* '#mw-content-text' to replace with the editing surface
* '#ca-edit' to start up the editor
When those elements are missing (and we expect them to be present,
e.g. we're not on a special page), we print a console warning.
For example, VisualEditor now launches on Timeless and CologneBlue.
It does not launch and prints a warning on Modern and Erudite.
(It is actually possible to edit and save pages on CologneBlue,
although various pieces of the interface look funny.)
This does not change which skins we claim to support: these are still
currently only Vector, MonoBook and Apex. But it allows third-party
skin developers to more easily test the editor and fiddle with their
CSS to make it look right.
Bug: T161373
Change-Id: I97c786f3c8c795c238b10bef332a129ea26f86c2
The element has both the class and the id set to 'catlinks'. This is
just for consistency, I have no preference on which to use.
Change-Id: Ic96b0f21fe790d0aa03bfd6366ba246e8493a038
Redirect pages have two extra things not present on normal pages:
* Redirect subtitle: the "Redirect page" shown under the page heading.
* Redirect page content header: the "↳ Foo" at the beginning of content.
Our handling was pretty messy and had some bugs (T161614).
Notable behavior changes:
* Update 'wgIsRedirect' in mw.config after saving the page.
* Use #mw-content-text rather than .mw-jump for inserting the fake .redirectMsg.
.mw-jump is not guaranteed to exist on the page (it's a skin feature).
* Never replace the real .redirectMsg existing on the page, except by the
new HTML after a page is saved. Our fake is separate now.
Bug: T161614
Change-Id: I96a5e45a71bf10bf6a2b501dc0cf81e6c37060ec
To reproduce: start editing a page, turn it into a redirect,
cancel editing and go back to view mode. The "Redirect page"
subtitle under the page title should disappear.
Note that #redirectsub is correctly spelled all lowercase,
unlike #contentSub.
This reverts commit 0e1bc7309b
and fixes the code instead.
Change-Id: Ibacd73122dfec63268a77794bc77c4b88876d3ee
As it happens, #redirectsub is correctly spelled all lowercase,
unlike #contentSub. This line does nothing. We remove #redirectsub
correctly elsewhere; I don't think this was ever meant to be here.
Follows-up 96421b283c.
Change-Id: I3e4c6eb2ff94f363b488477b3ddd248e571e723a
Running setNotices( [] ) makes MWNoticesTool run this.destroy() to avoid taking
up extra space in the toolbar when not needed.
Also, make setNotices() bail earlier.
Change-Id: I492fd59a1e15e8f296bf7f03d9b0035c40dafa59
This avoids an OOui deprecation warning for trying to toggle a popup which
isn't connected to anything.
Bug: T160161
Change-Id: I9ad97785f0de4ecf81d189985459689644e25923
Distinguish between the initial summary state, and a value stored from the
summary when switching modes. This lets us avoid overwriting a stored value
when section-editing, or assuming a stored value after a switch was never
edited.
Bug: T159686
Change-Id: Ie7640538140a14bbafd539b3a45928f5c55cf804
Switching from visual to source reruns setupUnloadHandlers, which caused an
infinite loop where it thought it was its own fallback pre-existing handler.
Bug: T153346
Change-Id: I8df55a5395ede02fc34ec47a94f2c780dc08595f
Since December, the handler now expects to be passed the mode we're switching
to. Since we're filtering for just the edit link and not edit source, we can
hardcode 'visual' here.
Bug: T159374
Change-Id: I160045dd59ff1b4c2d180dbbe37280a1839886df
Pencil is the icon we use for 'edit' elsewhere in the UI.
Use the eye icon for the VE tool to specify 'visual'.
Bug: T116417
Change-Id: I12b6bab2a52758685abde04579b274a32d651174
This will make it easier for third parties to load the required
modules for an article-like target.
Also cleanup mobileArticleTarget to better match desktopArticleTarget.
Change-Id: Idb75e2bd99d8cf2c298e101cf92e8af4f85f5ad5
These are now computed upstream based on position of toolbar.
The menu tool now needs its indicator explicitly hidden.
Change-Id: Id2280f70553e1e45f3a42af45684c5808797925c
As for the Translate extension this will read a global set by the
TwoColConflict extension to disable the VisualEditor and its hooks
on the modified edit conflict page there.
Bug: T156251
Change-Id: I164d1546c9d98d8715650e13c63a01d06c76315d
When switching from the old wikitext editor to VE, we stored "editing..." as
the original page title. Then restored that when saving / switching to "read".
Instead, detect if we're on top of the classic editor, and use the pagename
message to make a plausibly-correct title.
Bug: T126077
Change-Id: Ib0289de71c3ae947ca0a3e45fe1e620378689c35
