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
Visual Editor currently requests MediaWiki DOM version 2.0.0
when talking to Parsoid. Since Parsoid treats that as a request
for 2.4.0, its current version, and Parsoid doesn't have a
2.4.0->2.0.0 downgrade path, passing the latest Parsoid version
(2.4.0) should make no difference in practice -- but would better
match current reality.
Change-Id: Ia2bc0c1981db6f573a69fb1910cef4304c80ae00
Now that Parsoid's ServiceWorkers have been merged to core, this adds
support for "zero configuration Visual Editor" to the master branch.
Like earlier zero-conf work, this does not use RESTBase for stashing
or for reliable selective serialization. Future integration work
with ParserCache will reintroduce this functionality. Nevertheless,
this implementation should have feature parity with the "loopback interface"
zero conf VE we've been shipping since 1.35.
Bug: T305108
Change-Id: I7b5b4a6d16b07914f947cbaf498ad1d3cf2447a5
If links get pasted into VE and they lack a "//" in the `href`, they
are automatically considered to be "internal", thus being converted into
`[[...]]` wikitext links.
In case of pseudo protocols like `mailto:` this should not be the case.
This patch uses MediaWiki core settings to check if a `href` value is an
external protocol known to the application.
Bug: T297575
Depends-On: I2e584f6d5adc6b2d735e79cea64f2beeb5f2c36d
Change-Id: I2b383106450e02cc6bcc1b99d547ff2ed7832b4c
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
.test() is the dedicated syntax for a boolean "does match? yes/no?"
check. .match() returns an array of matches, or null. This is just not
needed in these situations.
Change-Id: Ibb996ab843d1a6c7d7af98d6a112990665d543b2
Once we determined a link is internal from the first regex, we don't to
check if it matches the wgScript path as well. This would cause
"/index.php/Article" style paths to be detected as external as they failed
this second check.
Change-Id: I560d8080c513c523c68f2750be332e9fd91de192
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
Our theory is that browser plugin spam shouldn't reach
the DM document unless we've made a coding error like
I194ff1d57. Log future errors so if there is more plugin
spam in the future, we can investigate the cause.
Bug: T298147
Depends-On: I705195bc5d0f76a38da5d2cc09fab184a2c32401
Change-Id: I3403859906ceaa51be63b0d79f474f0289ab4408
Same random finds while working on something else. I carefully
checked and made sure these methods are actually called without the
optional parameter.
Change-Id: Iab36fd130258322985b5d6e7f8e1f7b4ee235ba2
These are only needed when we need to access a specific `this` from
within another `function () {}` context. This is not the case in the
situations here.
This is split from Ibf25d7e to make it smaller and easier to argue
about.
Change-Id: Ide1476de91fc343aa992ad92a1321d3a38b06dd0
Passing the useskin parameter ensures that output hooks are run
on the new page HTML. This already happens because we request
the 'subtitle' and 'categorieshtml' props which also trigger
skin mode (along with the 'headhtml' which we don't request).
However it is better for us to be explicit that we want the rendering
for a specific skin, rather than relying on these props to trigger
the correct mode.
Also pass through mobileformat param, which is added by a hook
in MobileFrontend.
Change-Id: I1cd2c5c5c13ae0b90cc32e441b453532343a434a
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
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
This prevents an unwanted scroll when the main edit link is used
and the first section is below the viewport.
Change-Id: Ib99ebe2dc5c105c3fcbd687ef5740166267f5536
This doesn't change the position of the loading bar, but it keeps it
still if any scrolling happens. Previously we expected the user probably
wouldn't scroll while VE is loading, but in subsequent commits we
will trigger automatic scrolling in section editing mode.
Change-Id: I1404ccd77583d808ef79291c6cb4f561e76bd41c
* 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
This prevents your preference being changed if you just
followed a link with a diffmode parameter.
Change-Id: I755563bde285e95c0367119d49a40e1dd3c5e178
Prevents accidentally treating plain text or user input
as HTML, which could be an XSS vulnerability.
Change-Id: Id4af48447a0907962a57340cb60aca08df9cc505
It should be possible for extensions/skins to trigger the click event
It should be possible to do $('#ca-edit').trigger('click') so that
Vector's sticky header can trigger the VisualEditor.
Bug: T293159
Change-Id: I58625ffca982edfbc4cdcb14a666d79093e1b89d
Most block-level things that can be interacted with by clicking have a
highlight. Categories don't, and that makes it harder to discover that
you can edit them.
Change-Id: I6be3824c34b36bd09bbae8cab9a9f36b6bcdb767
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
E.g. avoid calling the rather expensive method multiple times
in a row, if only 1 of the results is needed.
Change-Id: Iff1d2c0892367e927303f6f45d3231e04c045cab
The history.replaceState call in onReviewModeButtonSelectSelect() (1)
ignores any changes to the document URL made by external tools such as
RevisionSlider, (2) replaces with an empty string the history entry
state object if it was set by external tools such as, again,
RevisionSlider. Both 1 and 2 result in a wrong URL ending up in the
address bar at some point. This patch addresses these problems, (1)
creating a new mw.Uri() object every time
onReviewModeButtonSelectSelect() is called, (2) keeping the current
history.state object.
The original variable storing the URI object is renamed to avoid
shadowing (optionally can be replaced with its value as it's used only
once).
Bug: T288636
Change-Id: Ieb97b561a6c076aa28aae231fe286ac4d1051bbd
They both want to handle the same URLs. If we detect that
DiscussionTools new topic tool will open, then do not open 2017
wikitext editor.
Bug: T282204
Change-Id: Ic7dd677ea219938969f60bab91387c2e03ebdbe6
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
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
This reflects better what the widget actually does.
However, the config option `value` as well as the method
`getValue` are not renamed. These intentionally mirror a OOUI
convention.
Change-Id: I26e733b760501e57b3314d5da2d65bfdd4b38346
We have two preferences used for enabling/disabling VE:
'visualeditor-enable' and 'visualeditor-betatempdisable'.
(And 'visualeditor-autodisable', which sometimes overrides
them both, but it's not relevant here.)
The user can only set 'visualeditor-enable' when VE is Beta Feature,
and they can only set 'visualeditor-betatempdisable' when it is not.
However, when deciding if VE should be loaded, we always checked both
of the preferences. This gives incorrect results when the preference
that is not supposed to be settable actually exists, due to being set
in GlobalPreferences on another wiki where it's settable.
A similar issue could occur if VE configuration is changed from Beta
Feature to a normal preference (or the other way around), and the
preference values for the previous configuration still persist.
Bug: T271434
Change-Id: I7399b3c516f762429050a662ac85d1d392392323
Support the `url-new` mechanism so we can distinguish between
new/existing sections in direct navigation.
Also, mechanism will now correctly be `new` when clicking the "create"
tab on a previously empty page.
Bug: T272544
Change-Id: I667a1c45c3948ec6dfed8f348a1327bffaba58a5
Depends-On: I3cee7a3a4c4b646692dce4a1180c4ba18a61f4bc
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
This provides a consistent entry point for registering plugins on both
desktop and mobile, without needing to do strange things if the right
ResourceLoader module hasn't loaded yet.
Without this, registering a plugin module in JS requires ugly code,
and on mobile it wasn't possible at all.
Bug: T267692
Change-Id: Ie2c320c33ec2b064fba4fb45ba62545b9211439a
Reference images are moved to Cite and used by Citoid.
Bug: T170919
Bug: T171292
Depends-On: I02041246dda1b3d3ad1bcc0b014fa022e8259b62
Change-Id: Id97659ed1fa64a1223a8957fefaf2a149edd0e9c
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
DOM attributes are not arrays, and so don't have Array#forEach.
Fixed regression introduced in 4545f53245.
Change-Id: I1f0f44747a0f8a376c1fb7cbb8862c096a9d1dc9
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
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
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
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
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
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
Wrote code such that only redlinks and normal page urls
using the script path are treated as internal links.
Bug: T248076
Change-Id: Ie476bf7f4b389a659899eab4351c912fc6b24bee
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
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
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
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
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 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
TypeError: Cannot read property 'onCacheKeyFail' of undefined
(found when working on Ice92fafb1f546510dab28e3f8aa7d2280668965a)
Change-Id: I2a731cb273401074e65f9283c1f629dbdb272002
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
The comment here seems to be wrong, as far as I can tell, this
case can only happen when viewing a diff with no changes
(`data.result === 'nochanges'`) or saving an edit and getting
a captcha (`data.result === 'error'`).
The handling here, added in the recent refactor
b0f4b4c94e, causes both of these
cases to behave wrong (displaying the error message, instead of
empty diff / captcha form).
Change-Id: I305e8ca9ff769c229a93d5fb3307e545a0227f2f
* 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
Something is causing the 'ETag' headers produced by the "public"
RESTBase (queried directly from the client) to be mangled or lost.
My theory is that some proxy or browser extension is doing that.
When we detect a bad etag when fetching the page contents, discard
the result and try querying the "private" RESTBase via the MediaWiki
API (similar to what we do on private wikis, except there we talk
directly to Parsoid instead of RESTBase). After I463a84de63, that
returns the etag as part of the payload rather than HTTP headers,
and should pass unharmed through whatever is mangling the data.
Also compare and log the two etags.
Bug: T233320
Change-Id: I2ef0ca872597566f74b650aea71bf3f15747a6d7
Previously, the ve-mw/init/ directory contained two kinds of files:
those that were used when initializing VE, and those that may be
loaded even if VE is not going to be initialized at all. The latter
kind must not use the `ve` global variable.
After moving those files to ve-mw/preinit/ we can enforce this with
.eslintrc.json in that directory. This would have prevented T228684.
(Technically they merely must not use `ve.init`, and may use `ve`,
but that's harder to enforce. We should instead move the few non-init
methods out of `ve`: now, track, trackSubscribe, trackSubscribeAll).
Also, group some files under ve-mw/init/: targets/ now (only)
contains ve.init.mw.Target and its subclasses, apiresponsecache/
now contains ve.init.mw.ApiResponseCache and its subclasses.
Bug: T228684
Change-Id: I945249a27f6a0fa10a432d5c5dc57bc7e0461fd8
