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
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 message was upstreamed to core and later renamed.
Use the upstreamed dialog itself when switching sections.
Bug: T222525
Change-Id: Ibd2d75ec503e92b5ddec2105f762b0c9f0dc96fb
