Way back in 2c24efae in 2015 this got disconnected, which resulted in
saveComplete logging not having the expected updated revision_id.
Bug: T226847
Change-Id: I6dc14bb4b2dacedbe27493a97fa25c9b0542818c
Move fix for I92ffc19eab4e to getInsertionData as getTextFromAnnotation
is also used when populating internal link search field.
Bug: T226645
Change-Id: I60806932b00a742dae52651fb7931caf07413361
If the translations of save/publish button messages like
'visualeditor-savedialog-label-publish-short-start' contain spaces
(e.g. in Bengali 'bn'), the button on mobile would wrap over two
or more lines, due to weird styles we have for the mobile toolbar.
Change-Id: Ieb439ae489ab7110b81382ffdcf0d3d3ad2f84ac
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
The EventLogging extension no longer uses these internal modules.
They were phased out as part of last year's "lightweight EventLogging"
project (detailed at T187207). Migration notes at T205744.
VisualEditor has migrated already, mostly. It still depended
on the existence of these module names for some condition guards.
* The subscriber for 'mwTimingHandler' was guarded by 'schema.EditAttemptStep',
but did not emit events of that schema. What 'mwTimingHandler' really
needs is the '*SamplingRate' variable for its call to 'inSample()'.
This previously worked because the variable and the schema are both
provided by the WikimediaEvents extension.
* The subscriber for 'activityHandler' had a separate schema guard. This
might suggest an intent for the code to silently degrade if WikimediaEvents
were to be changed to no longer supply the second schema, or for the code
to work for third-parties without WikimediaEvents if they register only
the schema. However, this subscriber too calls 'inSample()' and needs those
variables.
I've assumed for now that it is okay for these to all be guarded together.
Even if the schemas were to be removed and we were to forget updating this
code, the new EventLogging client degrades gracefully from this (no errors).
Bug: T221281
Change-Id: I260c25752c3becfe6e499813197fbf7a3dba88c3
* Remove animation for toolbar sliding into place. It now happens on
the fake toolbar in MobileFrontend shown before the real toolbar
loads, and our toolbar just transparently replaces it.
Bug: T217784
Depends-On: If21aa0ea619ec2500ce5fca6fe81eb27f26bb047
Change-Id: Ib6ff7594e1982d1b46e9ca89d6b9722d025e8207
Abandon warnings are already handled by the code in MobileFrontend's
EditorOverlayBase. Using window.history.back() causes that code to run.
Having a duplicate way to trigger them only results in inconsistencies
because our dialogs animate in a different way.
Bug: T222315
Change-Id: I19c5616a6aeecf0ac63f37a564ef44f11df010b0
* Change the query in ve.init.mw.ArticleTargetLoader#requestParsoidData
so that in non-RESTBase mode with wikitext it still returns the
metadata required to initialize the editor, using the backend API
code added in I1b35b28e428a1f86d2e34d90ddbe73361ce14818. This fixes
the exception from T222312.
* Introduce new configuration option $wgVisualEditorAllowLossySwitching
to control this feature. It is enabled by default, fixing T214542.
We allow it to be disabled because switching in non-RESTBase mode may
cause "dirty diffs" (non-semantic changes to the wikitext), which are
undesirable on wikis where users carefully review all changes.
Bug: T214542
Bug: T222312
Change-Id: I58879cba5612002c70c24731306214d2577c2c52
Section=new behaves more like a form than a full
document editor, so allow focus to be fully moved
to the title input without leaving a deactivated
cursor behind.
Change-Id: I7e3835da925b27f5df79dcbdd4550445795cdc51
In general action=edit could be bound to a wikitext-specific
edit link, but in the case of redlinks we can use the
preferred editor instead.
Bug: T223793
Change-Id: Ib0851e9e2ce441ae93311153801e2c3de0a2063d
There are various circumstances where the wgIsProbablyEditable check
gives incorrect results (hence the 'probably'):
* User is blocked (T111217)
* Page is protected from creation (T173763)
* Page is transcluded on a cascade-protected page (T217217)
Bug: T111217
Bug: T173763
Bug: T217217
Change-Id: I7df8909c31f29d2e7521bef8612c27cb61146a4d
The likely case for this is: copying from within VE in one wiki, and pasting
into VE in another wiki. This change will notice this happening, and fall back
to treat it as an external link. (For the wiki-internal links, this will turn
them into interwiki links rather than raw external links.)
Bug: T223322
Change-Id: Ie0157fc3aee6e5fd9973a2889be7ebd287bc90a5
If a new namespace was added to $wgVisualEditorAvailableNamespaces,
but VE was loaded on a page with old cached HTML, the 'Edit' tab's
text would incorrectly be 'Edit source'.
If $wgVisualEditorTabMessages['edit'] or ...['create'] was changed
from non-null to null, but VE was loaded on a page with old cached
HTML, the tab would still use the old text.
Change-Id: I2d5c7b922ba480eb90fa0a6da7a1901f062c96df
Prior to 80bfbfc54b this worked by
accident, and with a number of bugs depending on your settings (see
T219457). It turns out that Wikipedia users have invented various
workflows that depended on this bug (mostly involving sandbox pages in
namespaces where VE is not enabled). Restore it as a supported
feature, and in a way that avoids the problems it previously caused.
Bug: T221892
Change-Id: I62714b6f2905efd1d1b34c7a13b9917cb6c609fc
Use an API 'parse' call with a sectionid to trigger
a full document expansion using replaceSectionAtRev.
Then send this off the RESTBase to convert to HTML
and statsh.
Ensure the etag is passed back to the API response.
Bug: T117716
Bug: T223023
Change-Id: I1b35b28e428a1f86d2e34d90ddbe73361ce14818
RESTBase is changing the way it is storing HTML/data-parsoid renders. In
order to still support VE (and other editors) with quick access to HTML
and matching data-parsoid (needed later for transforming the modified
HTML to wikitext), VE now needs to let RESTBase know it intends to
perform a transformation call later on. In that case, RESTBase will make
sure to keep the matching data-aprsoid around for long enough.
Bug: T222639
Change-Id: I02672e29bd0f331794fd77d9e56f9cc6822d9b9e
This does not fix the rendering of new
or modified interwiki links, which will
require an API request.
Bug: T185083
Change-Id: Icb72291e8662456e1a233392bf22d786c7eed1e5
This message was upstreamed to core and later renamed.
Use the upstreamed dialog itself when switching sections.
Bug: T222525
Change-Id: Ibd2d75ec503e92b5ddec2105f762b0c9f0dc96fb
Set this.loading to dataPromise before the done
handler is attached as that can run synchronously
and try to set this.loading back to false.
Change-Id: I4e5208b7bac9968951f30555dc56e054c38a3935
If the editor was opened via a section edit link, but visual section
editing was disabled (the editor contained the entire article),
generating visual diffs would fail.
Follow-up to ec6cbeaf5e.
Bug: T222489
Change-Id: I74d589bb9f7ee09312ef816148c581440beb65e5
If in an appropriate namespace, automatically add the name of the current page
to the beginning of internal links that start with a /. Same behavior as
wikitext link-parsing, essentially, just made explicit in the UI.
Bug: T110413
Change-Id: Idf9dc3fafab0e9c809eaf6c523c80da57577bb61
* 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
I think mostly the incompatible changes were made in commit
I5a7d73b20617cb3c6d6379084ac4bea23ec3bc74, but I didn't try
to track them down.
Also fix an issue where hrefs in section edit links generated
by this code were wrong.
Bug: T208102
Change-Id: Ibf6564bc0dcb7fcb420739a897b54346a01add02
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
Same thing as Ifb49ede450cabdcd8303b298b62f2ac632809b53, for
a slightly different case that we missed.
Bug: T221289
Change-Id: I0ca287af87e1058620fbed75a50d40f01513a567
Incorrect order of operations caused all metadata to be removed before
we looked for the 'mw:PageProp/redirect' metadata item.
Bug: T221686
Change-Id: Ifcf210ad772babe1019fd0cfbaa7bd60d0e7e5fe
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
New changes:
9b162a5da Localisation updates from https://translatewiki.net.
10dbdabf4 Remove valid-jsdoc exceptions for @chainable
a424f804d Make blockquote a non-content branch node
Local changes:
* Update stuff for making blockquote a non-content branch node
Bug: T76426
Change-Id: I95ae25f20d3d102da69bf5ffdff55335f6c07635
These do not vary by user or page, and can thus be loaded asynchronously
via the startup module, rather than blocking rendering and fetching
of modules on all pages.
In a future change, it might be better to go a step further and bundle
these with a module so that they only load as-needed instead of still
on all page views, but this should be an improvement nonetheless.
Change-Id: Icae3712ac5546a90bc7ffd787b0f3285dff6a26f
If a page can't be edited in the requested mode (e.g. veaction=edit on
talk pages), the parameter will now do nothing (the editor won't
load), instead of trying to load the editor in another available mode.
Bug: T219457
Change-Id: I2cd78ea13ba13ff622f5e4b7db033f82dfa7875e
Currently, the selection is not updated, so we end up keeping the
first two characters selected. Same code as ve.ui.MWLinkNodeInspector,
see cb72eea2041bb35e02eb756be3f2c7e8e6c3b43c.
Change-Id: I2204643c41025ad69fa9e232edfc5a896f1b8bdf
No idea what causes it, but I've seen a similar issue when working on
Ic35f084d019afd1782292c831765ceb1444fb14a (in OOUI) and this hack
worked there too.
Bug: T219680
Change-Id: Ifb49ede450cabdcd8303b298b62f2ac632809b53
In case we get confused and try to load the wrong kind of content for
a given mode, it will now fail with an error message rather than e.g.
display a source editor full of HTML.
Bug: T219457
Change-Id: Ic23c2bbda2931da8ca015b4ea3673dbce4e2d994
New changes:
f039957f3 [BREAKING CHANGE] Use keyed objects for importRules blacklists
Local changes: Use extendObject to set importRules
This allows us to inherit the ruleset from the parent
so we don't have to worry about keeping it up to date.
(For example alienTableCell from upstream was missing
in MW).
Media/Gallery dialogs: Add missing mwTable types.
Change-Id: I366a091ff4def66cc25200b3d1b2c23ba6b716f7
Depends-On: I8ff7e8242c8db235a0f9e11e2e52f90d62d368a0
Animation shows breifly on every keystroke, even though
only one server request is made, as the promises always yield
to a browser animation frame.
A pending animation isn't really required for autocomplete
as the results are only optional suggestions.
Change-Id: Ifa257592b10d84dccfa3e0c819c1edf1f7ef9cfa
This code is supposed to check if we have scrolled past the end of the
page, and if we did, scroll back up to a more reasonable position.
However, it seems to incorrectly trigger in other cases, and scroll
the page back to the top, because getBoundingClientRect() occasionally
still returns bogus values (even though we try to avoid that). This
happens inconsistently when focussing the surface or closing a dialog.
We can't correctly display the toolbar while scrolled past the end of
the page. Removing this code causes it to go into an endless animation
loop in that case. But that may be preferable…
Bug: T219200
Change-Id: I152f2b39351ffd3c9799eea33cce95e05d2f9ab9
Parsoid does not use relative links anywhere anymore (T72743). There
is no reason for us to support this. And previous code allowed
"hrefPrefix" to be empty '' sometimes, which is scary, as it could
lead to XSS vulnerabilities if titles starting with 'JavaScript:' are
not handled correctly elsewhere.
Bug: T206357
Depends-On: I8728f63084902c76d1c61193be4367939b069f1a
Change-Id: I99be18877aae2b505cf261bd7cdef6cf0d7a8670
The EditAttemptStep schema doesn't have some of the fields we attempt to
submit, because we're generalizing and it only wants specific ones. Be more
selective about what we submit, so validation messages in the console will be
quiet.
Bug: T218163
Change-Id: Iaf9f47b61c138bb0106b2dfc4be2caec02a10d1d
We need to set 'padding-top' matching the height of the toolbar
somewhere, so that the toolbar doesn't cover the top of the editing
surface. Apparently moving it from the current place (the top-level
wrapper for the MF overlay) to the document node (the node with the
'contenteditable' attribute) allows Safari to properly scroll the
cursor into view when focussing, rather than scrolling it offscreen.
Bug: T219066
Change-Id: Iee1e03bce24c2f149a0aa0f393a37b9db43eaca6
The edit might have changed the section title, which will change the
section-hash, which will make the redirect break. The only way to avoid this
is to use the HTML provided to saveComplete to check for the new hash.
Bug: T213120
Change-Id: I5adfdb44a8304ed4f30def74400e4512e9e8c0ae
It appears that I did a Ctrl+X in one file, but forgot to Ctrl+V in
the other. And no one noticed that 100 lines of code went missing.
Follow-up to 73561f7aba.
Bug: T218946
Bug: T219041
Bug: T219043
Change-Id: Ib1fd85d121083239397698ff1a30a7908deca25f
ve.init.Target#isToolbarOverSurface has been removed in VE/VE in 2016:
8b1208cb976278bd44025e6d2c86a3ea6ed8c177. Nothing calls this method.
Change-Id: I9640978b45e568412db4b1c5aa80631a68d847b2
On iOS Safari, when the keyboard is open, the editor toolbar could
previously be scrolled out of view, due to how the keyboard affects
the viewport (or rather how it doesn't).
Detect when this happens and bring it back in, with a similar slide-in
animation as when the editor loads. Technical restrictions prevent us
from really keeping it in view at all times, and I think this is the
best we can do (and it looks almost intentional).
Bug: T218414
Change-Id: I5eed360d4644815bc9829fbc6b0ffd79b205d10b
It will be easier for us to maintain this way. The code I'm moving had
a lot of comments saying that it should be moved here.
See MobileFrontend change Ibe192360bdecab86519de1781f66f90a3441c551.
Bug: T218946
Change-Id: I908e035ec245a9b190f05e64c35dbb29936434de
It was here because our old hacks prevented the viewport from being
scrolled, so the keyboard would always cover the last few lines of
the surface. But it is no longer necessary after we ditched the iOS
scrolling hacks in MobileFrontend.
Bug: T217769
Change-Id: Iaf3f86c0fc43f75d11a43462721f44d62abc6eb3
This is no longer necessary and doesn't work after we ditched the iOS
scrolling hacks in MobileFrontend. And the default implementation works!
Bug: T218429
Change-Id: I5fba78a3877901dac5afda46d3004c07cad383d0
This enables mobile section editing if the user is logged
in and has an odd user ID. Otherwise it is disabled.
Bug: T218851
Change-Id: I2c22d7636ae11d2db7780ae5adb3abe9df532b7c
When this code was written in 2013 (1a5bdd5bd2),
the langlinks API did not have a way to return the language names (autonyms).
This has been added in 2014 (4ba3a9aea96ee21c035c69999be23580e23f4e0a).
Change-Id: I70edb846d94b1108b079caf5915532234190da8f
Passing section=undefined resulted in no <section> tags being
unwrapped, which broke the historical diff. Ensure 'null' is
used instead for whole documents.
Bug: T217752
Change-Id: Iec33e6ab83bfbd011df9dc05f4daccc26b1df8b5
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
