Previously, a toolbar with the extra tool could be shown for a moment
while the editor was loading.
Bug: T301626
Change-Id: I7f5d01ef6e64ef85141a38a236fe2a1d1ada00e8
When the editor is loading, and the browser window is narrow enough
that we should use the narrow toolbar, the wide toolbar would appear
for a moment. It was particularly jarring when it caused it to wrap
over two lines.
Bug: T301626
Change-Id: I551a66edab40235c4a26751eed163b5b30ef698f
* Pass 'noPrompt' to #tryTeardown
* #loadFail gets triggered by the data promise being aborted,
so if 'activating' has been cleared at this point, don't
prompt about there being load error.
* Retry/cancel dialog assumed you were coming from a wikitext
editor. Rewrite the logic to handle teardown the target if
the user is coming from read mode.
Change-Id: If9e5d1fbf00f8359f4d06fe7fc3064cc7e349bc9
Previous attempt in 005a8d24ef,
reverted in 3c1d167b33.
The deduplicateStyles() function lacked a check for fosterable
positions, which caused T299767. This is now fixed.
Also added tests.
Bug: T287675
Bug: T299251
Change-Id: I0d22be9b66d26d09373cee63dd6ce52c1659e62d
We introduced these methods in Idc0cccbe but didn't update this
logic in MW.
This prevents focus being put inside an image caption if the section
starts with a block image.
Change-Id: I4cc1a116c1dcc8e1c642359ea768b6f5265a061b
Parsing it in the RL module caused the module cache key to depend
on the parse, which is slow and makes ResourceLoader sad. The usual
approach for solving this (I206bb05d28) can't be used, because of
how EditPage generates this message.
Bonus #1:
Generate the message for the correct page title. MediaWiki allows
customizing it per-namespace or even per-title, which we haven't
supported before.
Bonus #2:
Pass the context for message localisation (depends on I5f7c77970d).
EditPage::getCopyrightWarning() was parsing messages without the
interface flag, causing some needless processing elsewhere.
Depends-On: I5f7c77970d0525c0ff394f8bd72c69dcb5d00623
Bug: T298822
Change-Id: Iaa626f0e6379a5a370f9c465cea8528bb5bde7f7
* 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
* Use this.getElementWindow
* Use this.surface.padding to avoid race condition
when the toolbar hasn't fully rendered yet.
Change-Id: I055b1d9458d73e435ede6096941a3e72c9c1ce74
In case the save is triggered without the save dialog (for example, when a null edit is made during suggested edits task in GrowthExperiments)
Bug: T298552
Change-Id: Id49b967cfa52d33848e9c911086000fa4501fa7f
Prevents accidentally treating plain text or user input
as HTML, which could be an XSS vulnerability.
Change-Id: Id4af48447a0907962a57340cb60aca08df9cc505
* Make ve.ce.MWBlockImageNode autofocus=false, remove
unused transition property
* Remove ignoreChildren from ve.dm.MWBlockImageNode
based on new definition
* Remove tests which assert that deleting in a list next
to a block image always de-indents. If this is desired
behaviour it should be fixed without reference to
ignoreChildren.
Bug: T295905
Depends-On: Idc0cccbe73d1b49d07b60c14a192a40f47d64608
Change-Id: Ib79a070f5d36dbe7742fa0760f8cdf55fe3046ed
Load errors are already handled in the MobileFrontend part of the
mobile visual editor, by this code:
66c55573e5/src/mobile.init/editor.js (L375-L387)
// Wait for the data to load before we show the editor overlay
overlay.getLoadingPromise().then( function () {
...
}, function ( error, apiResponse ) {
// Could not load the editor.
(1) overlayManager.router.back();
if ( error.show ) {
// Probably a blockMessageDrawer returned because the user is blocked.
document.body.appendChild( error.$el[ 0 ] );
error.show();
} else if ( apiResponse ) {
(2) mw.notify( editorOptions.api.getErrorMessage( apiResponse ) );
} else {
mw.notify( mw.msg( 'mobile-frontend-editor-error-loading' ) );
}
} );
Compared to our code:
ve.init.mw.MobileArticleTarget.prototype.loadFail = function ( code, errorDetails ) {
...
(1) this.overlay.onExitClick( $.Event() );
(2) mw.notify( this.extractErrorMessages( errorDetails ) );
};
The lines marked with (1) and (2) do basically the same thing. And
the function parameters "error, apiResponse" and "code, errorDetails"
are actually the same objects, just with confusingly different names.
This causes the popup with error message to appears twice (although it
isn't too obvious, since the two popups appear in the same place, so
only one is visible), and also causes bogus data to be sent in event
logging (T237063).
Bug: T237063
Change-Id: I7fe7a944707fe585251ce9e16bbb78ccd123a7ed
I tried to review all of them. Some of the changes I did:
* Make sure the `config` parameter is not marked as optional
when it is not.
* Make sure default values are mentioned.
* List individual `@cfg` options when it makes sense.
Note I don't list all options a class could accept (e.g. via all
its parent classes and mixins). That's too much. Instead I checked
how a class is actually used and list only these options.
Even then I don't list everything, e.g. unspecific options
like "classes" that can be used pretty much everywhere.
Change-Id: Idf4fbe1dc3608ace277df9e385f2f140df3a2f50
If editor loading was aborted while the surface was already being set up,
this code would cause the following exception:
Uncaught TypeError: Cannot read property 'tools' of null
Introduced in c02c529537 (2017) because
our coding conventions at the time demanded that all `var` statements
must appear at the beginning of a function.
Bug: T287487
Change-Id: Id657d6f1e1189c17ede25362f145bb7b10f441db
Reasoning:
* format=json must be the default. Nothing else makes sense in
the context of this code. This should not be a surprise.
* formatversion=2 is only a default when the custom
getContentApi() is used, but not when mw.Api is used. One
might argue that it's safer to always specify formatversion=2.
However, this is not done in other places in this codebase.
It should never be done or always.
* I find it confusing when the action=… is missing. Let's not
rely on this default.
Change-Id: I6ca29f76bffc0849103c5bcff4aaf28fcaaa4c52
Cloning the #catlinks node loses all native event handlers registered
on it. jQuery's `.clone( true )` method can only copy jQuery event
handlers, so it does not help. As a result, when the node is
reattached to the page after cancelling visual editing, HotCat's
interface is still visible, but not functional.
To fix this problem, keep a reference to the original node rather than
a clone.
https://developer.mozilla.org/en-US/docs/Web/API/Node/cloneNode#noteshttps://api.jquery.com/clone/
Change-Id: I2c0b3d1a919b67053a17dd11fd2b7dc7556267ef
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
* Create getSurfaceClasses method.
* Pass surfaceClasses to target widgets.
This ensures that the 'content' class is passed to mobile
target widgets, and the 'mw-body-content' class is added
in a less hacky way.
Change-Id: Ibce6d1a1d0fda63cca354761f1b91f808858e95b
VisualEditor recreates the mw-body-content element. The element
with mw-parser-output already exists as a child. All skins now
consistently follow this pattern.
To limit the impact to the editor, we use ArticleTarget and add the class
to the surface, which corresponds to the mw-body-content element of a skin.
This avoids unrelated regressions in experiences such as DiscussionTools.
Bug: T283014
Change-Id: I4833d1ca9fda4fc0bd433760e47fe7010f00db05
Ib957eac2d checked to see if actionTools.notices existed before
destroying it, but assumed it always existed if editNotices was
set. This patch adds a check before attempting to show editNotices.
The error occurs because Ibc7fa48df unregisters the 'notices' tool
(along with many others) for AddLinkArticleTarget.js in
GrowthExperiments. I92a3162ef in GrowthExperiments will empty out
any notices to work around this problem.
Bug: T281960
Change-Id: Idacd365efa82ecd5c0074ead035eda0cb9444b1f
The regex that removes the wikilinks to create the initial edit summary
should have the global flag since it was taken from preg_replace which
replaces globally implicitly.
Bug: T276722
Change-Id: I21e3cdfe752657ad37d9a6bd473a7e7dbb6e4cd6
We need the whole DM doc to show reference diffs
correctly. We can filter down to the active section
after the conversion like we do with the editor.
Bug: T272813
Change-Id: I2081dd520ff414caadaed2efda955d600953c957
New changes:
c17816c5f Diff sidebar: Make font size slightly smaller
f8439f4cc Deep-freeze linear data
a8919f78e Deep-freeze linear data added by transactions
Local changes:
Fixes for deep-frozen linear model
Bug: T119236
Change-Id: Iae4362c8dab0f2bd335e24498f3e0522b8b1d4fc
This was used when we used to pass API errors to showMessage, but
is now unused by the two remaining users (missing edit summary, and
"press ctrl+enter to submit").
Change-Id: I8a6b4db78d4e451cf3ec85fcdfd8293328aaaa3c
* Remove custom internal events in ArticleTarget for every error type.
The indirection was just making it harder to figure out what data
goes where.
* Centralize the actual logging in ArticleTarget, instead of doing it
in a dozen methods.
* Directly use the error code from the API for 'save_failure_message'.
Previously we'd lose the original error code and generate a new one
in the event indirection stuff, except for 'responseUnknown'.
* Update 'save_failure_type' map. Remove unused error codes, update
the ones that changed, and sort in the order in which the types are
listed on the schema page.
Bug: T272162
Change-Id: Ied602c456f4b0e7e9bb135e3200bec5ce65641ba
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
originalDmDocPromise is dervied from target.doc, so if that changes
ensure the promise is cleared.
Change-Id: I51219e06109b0ccf1a17c920131b764862be85e1
If a teardown has started, there should be a teardownPromise,
otherwise return a rejected promise.
Bug: T268358
Change-Id: Ia5cbd6b409a38f97243234ea7c87d24f71bdf3d6
MediaWiki doesn't have such a limitation. This might have been copied
from the edit summary code, which used to be limited to 255 bytes.
Change-Id: I4afe9b1cde0663c47c0c2502b6e32116b912208b
This patch starts using watchlist related values from ApiEditPage
results instead of updating the "watch link" based on whether the
checkbox was selected or not at the time of saving the article.
This change does not depend on T261030 and can be merged without it
but T261030 needs to be fixed or temporarily watched items will not
display the right tooltip when hovering the "watch link" or star icon.
Bug: T260434
Change-Id: I2c844223620d7d28f36a0cd8ae3dee4b0c8ae5bf
If we call getBoundingClientRect() while the 'transform' animation is
still ongoing, it's going to return values reflecting the transform
- that is, the rect will be partially offscreen - which will trigger
our code that runs the animation again.
I don't know why this wasn't a problem on iOS 13.3 and earlier. Either
the timing was slightly different and the 'transform' animation was
able to finish earlier, or getBoundingClientRect() was buggy and
returned wrong values that conveniently worked right for us.
Bug: T259321
Change-Id: I6be0ddaeb6df54295fb14c45ba15fee41d61e33f
Rebuild the category list from the data we got from the API. This makes
it work regardless of whether we came here from activating on an
existing page, switching from source mode, or loading via an edit URL.
Because Parsoid doesn't include redlink status on the <link>s it
represents the categories as, we do have to manually update those
styles.
Bug: T251398
Change-Id: Iaaef3223816269bba1371fbb07956119a120c1ca
Change $originalContent to $editableContent, as counter-intuitively
the editing surface is attached inside $originalContent, while
$editableContent contains only the hidden existing page content.
It was not a problem previously because of the order.
Bug: T254518
Change-Id: I68f7ddb45f09dff475b183ccfeaf98e67b83066e
It's supposed to be a string or null. The parent class sets
`this.section = null` for us by default.
Bug: T257355
Change-Id: I375a3f6724235f22888bb7f0cb77a7081153768e
Translate itself will show an warning dialog when user tries to edit
a translatable page in visual mode. Editing in the source mode is
allowed.
Bug: T192052
Depends-On: I03ea64353b2d5b28d684f90936cab75ea4fd40d2
Change-Id: Ie4f3a6003c27773c6d0c5086c876fe424befe25a
There used to be similar code here, but it was removed in 2015 in
85b745666f because it wasn't correct in
some cases. Restore it and instead separately check for those cases.
Bug: T257124
Change-Id: Id4a17266111d064805aa0ca865182bb2f4b019eb
This reverts commit e5c1ef651b.
This change caused an error where templates failed to be inserted
into wikitext in the 2017 wikitext editor.
Bug: T255785
Change-Id: Ie57c49e68e594be22af2b1b479840f29e46131db
mw.Target doesn't know about revid and etag, so move that logic
to ArticleTarget, where the param can still just be a boolean.
Change-Id: Idf4632cd28554aaf5bbf5f2b44ded047c0c4b182
This handles the minor edit and watch checkboxes, as well as any added
by extensions (e.g. FlaggedRevs).
Switching in the other direction already works fine, that is
implemented in ArticleTarget#getSaveFields.
It doesn't seem ideal to put this code into the constructor of
ve.init.mw.DesktopArticleTarget, but that's where we already have
similar logic for the edit summary. I filed T253696 about this.
Bug: T250388
Change-Id: Ia6a9c0465ed215e8f74b9fff4590593383e9a1e6
Previously we didn't deactivate them, so if you opened VE, then
switched to NWE, then exited the editor, all three tabs would appear
active.
Change-Id: I904d6daf2896ceadf004f5e57a88c2359f33fd44
Use hasContent to
1. Catch cases where the document is empty, e.g. <p></p>
2. Avoid having to use the converter
Change-Id: Ib1bb36824ca871e535bef38cef8137fdfb81b53e
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
The base class doesn't use it, it only defines it, and
DesktopArticleTarget is the only subclass that uses it.
MobileArticleTarget calls it, but also overrides it to be a no-op.
Change-Id: Ib3feea94844f4e1ed71dccece7657450516cac89
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
