The 'mwSignature' command replaces the selected content with your
signature. So basically, if you double-click this node, it gets
deleted and an identical one is inserted. This is useless.
I think I added this when this class was inheriting from
ve.ui.MWTransclusionContextItem, to override the command that would
open the transclusion dialog, but even then this should have instead
been `null`.
Change-Id: Id4492e36e9d89001df655e48b528d07eb608289e
These constructors only take a single argument, so the api config was
being ignored and the input would fall back to the default `new
mw.Api()`.
The order is changed so that the "api" config is merely a default,
and can be changed by whatever comes later.
The UserInputWidget currently doesn't accept an "api" config. This
will be fixed in Ifb1dd9d. But this is not a blocker. Merging this
patch here before the other won't have any consequence. It will just
continue to ignore the "api" config. ;-)
Change-Id: I15c35216c717576c6767927cac06ef72198fc95a
EditAttemptStep requires an integer, and just getting the value of an
input is always a string.
Bug: T261664
Change-Id: I57e76857086474365124b5b016902211b0e63166
The input field becomes a title autocomplete, showing small preview
images and searching only the File namespace.
This is consistent with how TemplateWizard behaves when editing a
File parameter.
Bug: T260886
Change-Id: I7a114e279436ec1ff6f7b8ab66443138ab12637f
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
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
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
The MWParameterSearchWidget that shows a list of all available
template parameters displays the (human-readable) label and
description of each parameter (both given via <templatedata>), as
well as the parameter's internal name and aliases, if there are
any.
This turns out to be non-helpful in the majority of situations:
* When there is no <templatedata> yet, there are no labels.
Instead, the names are used as labels, which means they are
*all* identical and everything is shown twice.
* The same happens when manually adding an "unknown field". Simply
start typing, and you can add parameters with any name. What you
type is shown twice (actually 3 times, 1 time in the input
field, 2 times in the result widget).
* Many template parameters are already nice, human-readable. Even
if <templatedata> exists and specifies labels, these labels are
often identical to the names. There is no need to come up with
something else if the name is already good enough. (Exception:
Localizations, but these are rare.)
Furthermore, this is a *search* result widget. The pretty much
only reason the names and aliases are shown is because the user
can search for them, and needs to understand why a parameter was
found. This still works fine.
For comparison, when a parameter is required you will *never* see
it's name, because the parameter is always there, and never shows
up as a search result.
Change-Id: I6b1dca1c94b2c496930b5bfdfe1c6f76898faa2a
DOM attributes are not arrays, and so don't have Array#forEach.
Fixed regression introduced in 4545f53245.
Change-Id: I1f0f44747a0f8a376c1fb7cbb8862c096a9d1dc9
Items which are invalid titles will still get discarded if
the gallery is edited, but this is better than crashing.
Bug: T260584
Change-Id: I5dc20c233fd9ab41bdf48531829bddca2c5b25df
The interface has enough space for 2 or 3 lines of text.
(On mobile, the button has only an icon and no label.)
Bug: T260074
Change-Id: I50b08029f843e91d10b8c81985f6dfacbb96c8e7
The 'checkbox' part of the edit form is now allowed to contain
non-checkbox form widgets, but these are not yet supported
by VisualEditor. Until they are, this skips them entirely
in order that no broken form field be shown.
Bug: T259546
Change-Id: If62c11b174df235be611b9d32eb28e4759ba5f66
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
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
The mw:Placeholder attribute semantically means, "don't touch this,"
but french spacing should be freely editable. It's just a funny way
to write a plain wikitext space.
Bug: T254502
Depends-On: Ia164dd1318d45924aa965919e7939c6f817f5d0d
Change-Id: I56e0f0c6526649ea041e023698a48936176dec4b
We don't share much functionality, and we have to do a bunch
of hacks to disable functionality we don't want.
Change-Id: I9861123d8f1cbab1923f1aa5be713c2dadaed53d
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
The rendering is the same as before, but keeping the element around
makes it possible to override getDescription() to return some extra
text and have it appear as expected.
Change-Id: I1ef38abffbdb405121ea6b0b2ac368bbbb008cd7
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
<includeonly /> is not valid wikitext markup, which is distracting.
Let's use <includeonly>…</includeonly> instead.
Bug: T250937
Change-Id: I9eac8b265eca16118d390da2628e0da7ca409ed8
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
Calling the linter is very slow as the result is not
cached. Extensions needing this (DiscussionTools) should
just call the Linter extension API directly.
Bug: T253799
Change-Id: I994b52ca70c29a32900741a36087f10144396720
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
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
The difference is that metaitems are not visible on the editing
surface, and their exact position is not preserved when the paragraph
containing them is edited.
This behavior is desirable for e.g. categories, but not for
<noinclude> and related tags, which are intentionally placed in
specific places in the text.
Note that we don't really have any editing interface for these nodes
yet. But you can see them (and they come with descriptions and links
to documentation pages), and delete or copy-paste them.
Bug: T250937
Change-Id: I104e7abbd650567df0e59813653c46a66d955d58
By default, many browsers permit resizing the textarea in both
dimensions; however, the SaveDialog doesn’t handle horizontal resizing
very well (the textarea is no longer centered and the options don’t
adapt to the new width), so add some CSS to limit the resizing to
vertical only.
Change-Id: I91bf63357237ddc2e3ede8e661480ab0cb48d10e
In 92c3055628 I changed `sectionId > 0`
to `sectionId !== '0'`. That was actually a mistake, as Parsoid's
section IDs can be negative, which indicates pseudo-sections, which
may not have headings.
https://www.mediawiki.org/wiki/Specs/HTML/2.1.0#Headings_and_Sections
Bug: T252238
Change-Id: I9133d4365a71d6db1fa58b69ae3b970166d15c1e
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
Code in ve.dm.MWTransclusionNode (which ve.dm.MWSignatureNode extends)
expects the node data to have an 'attributes' property.
We could override a bunch of methods to fix this, or add checks in the
original code, but it seems more future-proof to instead ensure that
the property exists.
Bug: T248585
Change-Id: I5bd721ca73605a396509669145b740db7283afd3
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
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
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
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
Wrote code such that only redlinks and normal page urls
using the script path are treated as internal links.
Bug: T248076
Change-Id: Ie476bf7f4b389a659899eab4351c912fc6b24bee
While we pretend that the ConfirmEdit CAPTCHA support is added by
ve.init.mw.CaptchaSaveErrorHandler in the ConfirmEdit extension,
we still have a bunch of code here required for it to work.
This commit removes some of it, no longer needed after
I6605017fd31a4f96c529dd0beb69e9f4433cebc1.
Depends-On: I6605017fd31a4f96c529dd0beb69e9f4433cebc1
Change-Id: I41e032fd754927b7ea6cfb767eb9f21b522ccacd
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
Bring in ve.dm.MWInternalLinkAnnotation.static.getTargetDataFromHref
and ve.resolveUrl, so that the file has no dependencies on VE.
Change-Id: I03bc455d5484a6c51f3fa2397c64936b829fe7e3
This code path is triggered when saving a new section in NWE causes an
edit conflict, which should be impossible, but apparently does happen.
Add some TODOs for parameters being added to the API calls in weird
places, instead of the dedicated methods.
Bug: T248364
Change-Id: I0686671e86e35f9ba503d0dd84e9074dde72dc10
Adding the ability for screen reader to announce
the state of the Transclusion dialog
when the show/hide options button is clicked.
Bug: T248089
Change-Id: I89b86179bcb63376e480cb8df55e24b9d29df037
New changes:
cf72879d2 Show sum/average when selecting multiple numeric cells
Local changes:
Implement number parsing/formatting for table summing
Bug: T247877
Change-Id: I52af622dc8cfe7e77fd7ce88428be092d5b092a2
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
New changes:
8a3e25b98 build: Updating acorn to 7.1.1
032a2520d Localisation updates from https://translatewiki.net.
ff82c0966 [BREAKING CHANGE] Remove ve.init.target lookup from TargetWidget
Local changes:
* Pass toolbarGroups explicitly form Target to TargetWidget
Change-Id: I4ff6f432412ab958f2858879b2b857278866350a
This should be a no-op as the inherited switchToWikitext
implementation will always call switchToFallbackWikitext
if 'source' is not passed as a supported mode (which it
isn't currently in MobileFrontend).
Change-Id: I213e7d54d158127b5c42bc05ff9ea2dececc42fe
Various buttons have a label on desktop, but only an icon on mobile.
We should still use the label for accessibility.
Change-Id: I2b49a80e174dc30ae997a69662643b28b428263a
Once upon a time, we added code to filter <style> and <link> elements
from the rendering of templates in visual editor, because attempting
to cut them would crash Chrome (T52043).
There are at least three reasons why that is not needed here:
* The preview is not editable text, so you can't cut from it
* The Chrome bug was fixed 7 years ago anyway
* We now use TemplateStyles in articles and they work just fine
The code was added here in 9dd638a5ab
without explanation, I think it was just done for consistency.
Bug: T212085
Change-Id: I0712e3a081f04d0b74cda47652fa6eb118dfe7b2
The code for setting 'watchlist' in the EditAPI request
was completely broken as it always evaluated to 'unwatch'.
Instead pass through 'watchlist' directly from the client
where it must be set to 'watch' or 'unwatch'.
Bug: T245579
Change-Id: Ia5a2bb76ef35a685b39bcc0c4727796acd0f510d
When user navigate to the version number,
the screen reader only narrates the hexadecimal number
associated with the version label without providing context
about what this number represents
Bug: T245470
Change-Id: If9cccac0d71de2de5da96a3a053d21e3deb0d80c
Adding the ability to special aria-label for the link annotation widgets
in order to aid accessibility to visually impaired audience
Bug: T245294
Change-Id: I3e1fd4a3e3a951092b5212397acc38b2b89a23c2
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
When using TwoColConflict with VisualEditor, the autosave buffer wouldn't
be cleared after saving the successful merge. This would cause a user to
see a "restore changes?" prompt the next time they entered the editor,
with the potential to confuse them and cause them to do extra work,
repeating the conflict resolution unnecessarily.
This change purges the autosave buffer before submitting a merge.
Note that it is not transactional, so there is a chance we're losing the
autosaved content even if the submit will fail.
Bug: T245119
Change-Id: I150023f548c5565412769d644a828176f907bc25
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
Things I noticed while writing I37f8e89b6d92c419d1b6569891612256342f8139,
but which felt too messy to include in that commit.
* Use promise chaining
* Update documentation
* Remove redundant code
* Split a method that now handles two different errors
* Grumble about localisation messages
Change-Id: I81e28a03af4f6c3452679ef6bbcaa89bb1235122
When the user is saving their edit, we want to ensure that they
understand how it will be attributed. If the user gets logged out or
logs in in another tab, we want to display a message about it before
saving.
Instead of manually managing tokens and handling the 'badtoken' error
to detect this, use the 'assert'/'assertuser' parameters for the API
to detect it for us. Thanks to this we can rely on automatic retrying
for 'badtoken' errors in mw.Api#postWithToken.
It will be possible to share some of this code with other extensions
that already use ArticleTargetSaver, namely DiscussionTools, now that
it doesn't need to manage tokens for VisualEditor.
Bug: T245327
Depends-On: I485f99e1f5f493262b0c9af22370da01adf1e09c
Change-Id: I37f8e89b6d92c419d1b6569891612256342f8139
By removing this line, we fall back to the default behavior,
which is to copy the attribute from the original DOM element.
The gallery is supposed to have a class indicating the type (packed,
traditional, etc.). However, Parsoid doesn't care about that and
instead reads the type from 'data-mw'. Instead, changing the attribute
is causing dirty diffs.
Bug: T214649
Change-Id: I96b5a21777046b1caf07a3b1def9fad81bb15939
ve.dm.MWImageNode:
* Define sensible scalable properties for audio files. They are now
scalable to any width but have a fixed height. (Ideally they would
have no concept of height, but that would require many more changes.)
This prevents them from resetting to 0x0 when resized.
ve.ce.MWBlockImageNode:
* Remove override for #isResizable, audio files can be resized now.
* Move #updateMediaType to MWImageNode mixin so it applies to
MWInlineImageNode as well.
ve.ce.MWImageNode:
* Add #updateMediaType from MWBlockImageNode.
* Hide the real image 'src' using CSS rather than changing the
attribute. It seems the previous solution depended on the order in
which methods are called, because it stopped working when I moved
the code here. (This depends on VE/VE change If5b1b5b5d.)
audioPlayer.svg:
* Make the file nicely resizeable. The dimensions of the "play" icon
and time are fixed, the bar adjusts to the width of the container.
Bug: T206022
Change-Id: Ia0f38ca11e0d55a5b725fd9aeb6c79ec1345376d
The previous attempt to fix this didn't preserve any attributes
but removing data-parsoid can result in a loss of wikitext formatting.
This reverts commit bdfd4b6d8f.
Bug: T207325
Change-Id: I2a38e651d17262889eddb149c72c9e08b4e56ed0
It was broken on desktop and on mobile, but for different reasons:
Desktop: In change 5f1c68945d,
I removed some code from DesktopArticleTarget that was checking for
`typeof errorDetails === 'string'`. I thought it was unused, but it
was actually needed for this code.
Mobile: overlay.reportError() doesn't work here: that method displays
the error inside the save panel, which is not visible at this point.
This is now solved by treating those errors as if they were API errors,
which is something we were already doing in ArticleTargetSaver.
Change-Id: I5207836f56d65171b1240cef02fc17b9956036ef
Follow-up to 5f1c68945d, which renamed
these messages while moving them into MediaWiki core.
Also, parse HTML in them. This is consistent with real API error
messages, and with the behavior of mw.Api#getErrorMessage. (And also
fixes potential HTML escaping issues.)
Change-Id: I307ca9873e245169a0d4b43499317acbac69fb9b
It was already added for visual diffs inside the editor. This fixes
some minor styling issues, e.g. the arrow after external links is now
shown.
Bug: T244673
Change-Id: I3ea72930ee7822a7579ebe787654d716f5947224
When opening the old wikitext editor, 'wgRevisionId' is always set to
0, and remains that way even if we switch to visual editor.
Elsewhere in the code, we handle this case by reading the revision ID
from the old wikitext edit form, so do that here as well. (This still
works after switching to visual editor.)
Bug: T230133
Change-Id: I9d3a23beb6b1393633b94ac3c9c6c667d7560308
It turns out anonymous users can't apply change tags, so change
I2c1d0f8d69bc03e5c1877c790247e165f160e966 broke editing for them.
Bug: T242184
Change-Id: I7c27e4d9995428e213a980819810f235fdfe9435
* Changing the 'mode' did not clear the old class, only add a new one.
* Clearing the 'class' or 'style' did not really clear it if the field
was left empty.
Both of these could result in the action not taking effect visually.
* Setting a class unintentionally also removed internal VE classes.
This doesn't seem to have any negative effects at a glance, but it's
probably a bad idea.
Change-Id: I304c222a2c8bc9d35b1cfaee401ab1f815251fde
Explanation of what this code was for: T227628#5339392
As noted on that task, our behavior is actually unintuitive and
distracting, and iOS Safari limitations prevent us from doing it
better.
This reverts commit 600e369347.
Bug: T227628
Change-Id: Id1a5eebd06e4218e3e102165c60791999293d273
When a template does not have user-provided TemplateData documentation,
the TemplateData API falls back to extracting possible parameters from the raw wikitext
to generate an API response with a list of potential parameters. However, it also
sets the "notemplatedata" field in the response, causing the VisualEditor to think
the response contains no useful information and ignore it. This appears to have been
an unintended side-effect of I97a1bfc9f9ead082a673a91b9d2053630a90309c.
This patch ensures that the VisualEditor will correctly consider such responses from
TemplateData by modifying ve.dm.MWTransclusionModel to check if the response contains
a parameter map. Some unit tests were added for the class to verify this behavior.
Bug: T243868
Change-Id: I72005880d9301a53224473900efe2917379e8708
This opens up the API so that other tools can use it without being
forced to tag those edits as being from VE.
Also, document that tags is a working parameter that can be passed
through to the edit API.
Bug: T242184
Change-Id: I2c1d0f8d69bc03e5c1877c790247e165f160e966
When mw.libs.ve.diffLoader#fetchRevision was calling this method, we
were accidentally making no query at all if RESTBase wasn't in use.
Change-Id: Ia98343aa1ba7f4f3be0c1a8ee5864653c429fb82
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
When NWE is enabled but VE is supposed to be unavailable on the page
(e.g. in talk namespaces), do not show the option to switch to VE in
the welcome dialog.
This is relevant if new users use NWE, due to config like below
(we use this on WMF Office wiki):
$wgDefaultUserOptions['visualeditor-newwikitext'] = true;
Change-Id: Iee8c3d3604a13dcd20efa713e49461ba9b885749
This code works perfectly on mobile now, I believe change
4fb17205b6 fixed that.
Note that the dialog is currently never shown due to the override
in MobileArticleTarget, but I tested after removing it.
Change-Id: I305a01fc78366a3d2d13662e6d71711864e0dffc
It's supposed to be non-editable but deletable text, like mw:Entity.
We decided to handle them this way in 2015 but never implemented it
(T94509). Currently, accidentally editing text inside of
mw:DisplaySpace node causes the changes to be lost when saving.
Bug: T241906
Change-Id: I78a0cc7a75061a7eefb8b677898b5756326615d6
New changes:
479b50059 Localisation updates from https://translatewiki.net.
c595d8ab0 Metion task related to Firefox hack
0a160fac2 Don't trust selections from the server
d796f3db5 rebaser: Update dependencies
b097dfaad ve.dm.Transaction: Don't translate offsets inside annotate-only replacements
eadee0343 FragmentWindow: Replace previousSelection with initialFragment
561e88158 Use ve.dm.example.imgSrc everywhere
d1dceab31 DesktopContext: Remove onModelSelect event
85947ac55 Pause synchronizer while staging
9a4dd169d Catch various out-of-bounds exceptions
341114afc Remove CE HTML from DM html test fixture
5d3a673e0 ve.ce.Document test: Add src to test image
182ac338e Evalutate fragment selection after staging
e032fa161 rebaser: Drop document opacity while paused
Change-Id: Id551ee2e6510610b8f2e12cf77ce3c8429700872
New changes:
d4a21a7e7 Localisation updates from https://translatewiki.net.
0e99d907a Update OOUI to v0.36.0
c422b8313 Localisation updates from https://translatewiki.net.
b1617fdca Update OOUI to v0.36.1
Local changes:
* Rename onLookupMenuItemChoose → onLookupMenuChoose
(deprecated in OOUI v0.36.0)
Change-Id: If66f3f16c0e882e99b0d768a3cf4170d24e7093e
TypeError: Cannot read property 'onCacheKeyFail' of undefined
(found when working on Ice92fafb1f546510dab28e3f8aa7d2280668965a)
Change-Id: I2a731cb273401074e65f9283c1f629dbdb272002
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
We've just displayed an error message in it, so don't close it.
I'm not sure if this code matters at all though. Usually when
there's an error during loading, code in MobileFrontend will close
the overlay and display an error message in a different way, so our
message won't be visible to the user. But maybe there's some case
I'm missing, and it's harmless. Closing the overlay was messing with
the MobileFrontend code though.
(found when working on I5146b726c5ce213992febb23f24c5937db0b9bfe)
Change-Id: Id1ea44d7bf6ef0f4fc0285e9e606dd415ed0a947
Cancelling the loading of the editor should stop the network requests.
Broken in 0498c03191. Forwarding the
'abort' function manually is the worst.
(found when working on I5146b726c5ce213992febb23f24c5937db0b9bfe)
Change-Id: Ifa7c11a433cb5ed3545fa2f3d9fae2800bcae7d7
