Factor out the logic for whether the WelcomeDialog should be shown into
its own method, and write it in a less confusing way. Do the same thing
with the logic for setting the preference/storage/cookie for hiding the
WelcomeDialog.
This makes maybeShowWelcomeDialog() much simpler, and removes duplicated
code in DesktopArticleTarget.
There is one minor change in behavior: if the WelcomeDialog is
suppressed using the URL parameter, that no longer causes the preference
to be updated as if the dialog had been shown.
Change-Id: I1d4f912c5f6bd7a2bbad2b209b97c3ec1f250a07
The .statusText and .status properties belong to the XMLHttpRequest
object, and are not present on the API response data object. I think
these checks were left over "just in case" when this code was ported
to use mw.Api instead of XMLHttpRequest directly.
MediaWiki API should never return just 'error' as the error code.
Change-Id: Iac6f721881b9405919d3397df6606e54f182bc59
loadFail can result in a retry, in which case it isn't
approraite to reject this promise. Also many of the code
paths call 'tryTeardown' which itself will reject the promise.
Bug: T238332
Change-Id: I366662847304d8ecf79d5899b2804dded67ee999
* Add a postWikitext method and split out postContent
from postHtml
* Move saveSuccess handling into postContent promise
* Connect promise directly to saveComplete instead
* Pass whole response.visualeditoredit object, instead
of splitting into variadic arguments for saveComplete.
* [DEPRECATION] Make serialize return the postHtml promise
and deprecate passing a callback.
Change-Id: I905737515578000b2b87214c92e8b9fe9e82f6b7
A @method annotation is only necessary when the docblock is not
directly followed by a function declaration (in which case JSDuck
assumes it documents a property), e.g. when defining an abstract
function or referencing a function from another library.
I verified that JSDuck generates exactly the same output before and
after this change (docs/data-<hash>.js files are identical).
Change-Id: I7edf51a8560ab9978b42800ab1026f0b5555c3bf
We were incorrectly always adding action=edit to the URL in that case.
The condition was always passing because `this.section` is `null` when
unset, but `this.currentUri.query.section` is `undefined` when unset.
This is a similar fix/bug to a68cc38b22.
Bug: T209163
Change-Id: Ic80ac377b763aea53678c4209ba6b3a6ba2996c9
Since we're inside the Target instance, `ve.init.target` refers to
this object. Some of the code I'm changing even uses `this` instead
of `ve.init.target` on the next or previous line.
Most of the mistakes are a result of mass search-and-replace changes
(478b0bcb, e1a887cc), or moving the code from other classes (d294006d).
But I can't explain the "ve.init.target.getSurface().getDom()" line,
it would be good to figure out why it was this way before we change it.
Change-Id: I0d7c6a48369242d4c99620fcd775ab537420d84a
Depends lightly on a patch to WikiEditor, which will hook up the logging there
for the case where the switch is happening from WikiEditor to VisualEditor on
the same pageload.
Bug: T221191
Change-Id: Ibafec77b2eabd3b3b3767472b7b5a40e3312bf18
mw.Uri requires undefined rather than null to unset a parameter;
null instead generates a parameter with no value (and no equals sign).
Our own code in ve.init.mw.DesktopArticleTarget.init.js parseSection()
can't parse that and causes an exception.
Change-Id: I783ea6b91c115b79bbd9deac6669bea0661139af
This message was upstreamed to core and later renamed.
Use the upstreamed dialog itself when switching sections.
Bug: T222525
Change-Id: Ibd2d75ec503e92b5ddec2105f762b0c9f0dc96fb
* Remove 'discardChanges' from switchToWikitext. This was
intended to discard changes even when the document was
modified, but it is no longer used as we always keep
changes if we can.
* Remove 'leaveVE' param, it was only used once and has
been replaced with a direct call to switchToFallbackWikitextEditor.
* Don't reset 'section' if there are no changes.
Bug: T221981
Change-Id: Ia39345da44d203ba67ae331917c8d5ece7d42ef7
When this was introduced in 7b2cacbe57
(2013), the confimation dialog was a generic confirm() popup. Now that
it is a OOUI dialog, the dialog overlay serves the same function.
Change-Id: I9812ab55c7a8179524865d93a6d269e388d4c4ab
This is a clean up after collecting the necessary data related to
blocks and how often users see the block notices
See: https://phabricator.wikimedia.org/T189724
Bug: T214214
Change-Id: I532a0cd95009109ba25caa8dd31badd5c1900da7
Catlinks is hidden via a class when there are no non-hidden categories on the
page. We thus need to toggle that class depending on the categories
added/removed from the page.
Bug: T213528
Change-Id: I4067c5721c28041542b9ef2dbc796fbc41b1afe8
This code, added in 703b2c2ed0 (2015),
is no longer necessary.
// Disconnect the tool factory listeners so the toolbar
// doesn't start showing new tools as they load, too
// much flickering
this.getToolbar().getToolFactory().off( 'register' );
Introduction of targetLoader (d371014e5d)
resulted in all tools already being loaded before a Target is
constructed, so this is definitely not needed.
// Disable all the tools
this.getToolbar().updateToolState();
The tools are already disabled because we set the surface to read-only
above, so this does nothing.
Change-Id: Idb162b60891cd1b961e29d2b9f62b74908f17957
Previously, we tried to keep the list of category members and the file
thumbnail, history and metadata visible while the editor was open.
I am removing it because:
* It is not very useful, as you can't interact with them (e.g. links
are unclickable).
* It is inconsistent with the wikitext editor (except for non-existent
category pages, and I'm proposing to change that behavior in T139191).
* It causes issues when other code doesn't expect the special setup
for those pages (T194068).
This introduces a minor change to the handling of normal pages: after
the save, instead of replacing all contents of #mw-content-text with
the new page content, we only replace the .mw-parser-output child.
Normally the effect is the same (it's the only child), but this could
theoretically affect interactions with other extensions or gadgets.
Bug: T194068
Change-Id: I26cc82d3e0f0d64e3f18a80d232005fc7ab3b374
* Move (de)activationComplete up to ArticleTarget
* Mark (de)activate to be deprecated in the future
* Fix some properties to ensure target.edited is boolean
Change-Id: Ie34139cb68f90f34eb243f1bb964ef578e90dfb2
* Also make sure block notices have type 'block'.
* Remove old flag for tracking since we'll be using one
from core
Change-Id: I4b66e73c8a4c4dd7bffd7c0239b1d5ec06eed12f
Depends-On: I6bd1c95548616677e1f72ba6bcfc6f2b551c1ca6
When an edit notice is passed through from the API, allow
a type to be specified, and specify type 'block' if the
notice is a block notice.
If VisualEditorTrackBlockNotices config is true, track
when a message with type 'block' is shown.
Bug: T209633
Change-Id: If5fecc2c2c1c39f4b7245b9a215e1120c93b2b22
