Depends on MediaWiki change I48d4bb3f, which adds the 'arrayParams'
option to handle explicitly indexed array parameters like
`&preloadparams[0]=a&preloadparams[1]=b`. Previously we only handled
implicit indexes like `&preloadparams[]=a&preloadparams[]=b`.
Bug: T231382
Depends-On: I48d4bb3fdf0ea7f5eb133c59bf63651ba356fc42
Change-Id: I8c899bce1b19fa286bd385f89e102a4b87db4db3
New changes:
77076f828 LinkAnnotationInspector: add a "label" field on mobile
Local changes:
* Updates for mobile link label editing
Bug: T229431
Change-Id: Ib0489f6f59b228ebc4a20f7a0a515be938a8f6d3
When saving fails for a reason we don't handle explicitly, the error
message will have HTML formatting and will respect any on-wiki
overridden messages, rather than being plain text generic message.
Extensions providing custom SaveErrorHandlers may need to be updated.
The only one in Gerrit that requires a fix is TitleBlacklist:
Ibeae79c95557a7af699716c9d921f34c310bee6d.
* Remove handling for errors returned in .visualeditoredit.edit.info
rather than .errors (.error in old format). AFAIK this is only used
by some extensions, it is probably incorrect to do (T229539) and all
extensions I know of that do this (AbuseFilter, SpamBlacklist,
ConfirmEdit) have custom SaveErrorHandlers.
* Remove custom error messages for 'readonly' (identical to API
response) and for 'hookaborted' (very unhelpful and there is a
chance that the API response is better, if the extension causing
this error generates any error message).
* Add a silly shim for MobileFrontend integration, because we allow it
to handle error responses, and it expects them in the old format.
This is probably subtly wrong in many ways, but MobileFrontend code
only uses this for logging, so it shouldn't explode. In the future
we will hopefully change it to use errorformat=html (T228897#5366960).
Bug: T229532
Change-Id: I3b9c4fefc0869ef7999c21cef754434febd852ec
A @method annotation is only necessary when the docblock is not
directly followed by a function declaration (in which case JSDuck
assumes it documents a property), e.g. when defining an abstract
function or referencing a function from another library.
I verified that JSDuck generates exactly the same output before and
after this change (docs/data-<hash>.js files are identical).
Change-Id: I7edf51a8560ab9978b42800ab1026f0b5555c3bf
The .oo-ui-popupToolGroup-handle styles only need to apply to the
editTools toolbar, where they override OOUI styles so that our
"stretched" toolbar works; they don't need to apply to the pageTools
toolbar, which contains just the editor switcher, and where they make
it look different from the MF wikitext editor toolbar for no reason.
Change-Id: I21315b34be0a7c3938f84ada720ff5754d953879
We were incorrectly always adding action=edit to the URL in that case.
The condition was always passing because `this.section` is `null` when
unset, but `this.currentUri.query.section` is `undefined` when unset.
This is a similar fix/bug to a68cc38b22.
Bug: T209163
Change-Id: Ic80ac377b763aea53678c4209ba6b3a6ba2996c9
New changes:
854a1fa2c Distinguish active link styling
Local changes:
* Pull through active link styling
Bug: T228220
Change-Id: I925f88d32a514a749b96f501a211003bc4c924f0
Since we're inside the Target instance, `ve.init.target` refers to
this object. Some of the code I'm changing even uses `this` instead
of `ve.init.target` on the next or previous line.
Most of the mistakes are a result of mass search-and-replace changes
(478b0bcb, e1a887cc), or moving the code from other classes (d294006d).
But I can't explain the "ve.init.target.getSurface().getDom()" line,
it would be good to figure out why it was this way before we change it.
Change-Id: I0d7c6a48369242d4c99620fcd775ab537420d84a
New changes:
a06204317 Fix TableNode unit test getOffsetFromCoords failure on Firefox
dfe0eb025 Refactor mobile context logic into ve.ui.MobileContext
Local changes:
* Pull through for edit cards refactor
Bug: T227532
Bug: T228767
Change-Id: I6c043e039fbef62a56f475b0dc365e171ab7bf59
New changes:
1a7460058 Remove ve.newMobileContext feature flag
Local changes:
* Remove ve.newMobileContext feature flag
Change-Id: Ia8def997b7cba4623866080752b06068d2118cc3
We also show this dialog on the old wikitext editor, where
ve.init.target is not set, because the relevant code is not loaded.
Follow-up to 478b0bcbb9.
Similar to e88cd81f94, which fixed the
same issue in a different file.
I checked all uses of ve.init.target in files under ve-mw/init/ and I
think this was the only remaining mistake.
Bug: T228684
Change-Id: I15551870cdb01d570e24ba9668e67330b8072e01
Our overlay could be higher than the viewport, allowing the viewport
to scroll again.
Bug: T212159
Change-Id: I1e97d1963b214fc7673c33ae6c14ab7b0b80f31d
Depends lightly on a patch to WikiEditor, which will hook up the logging there
for the case where the switch is happening from WikiEditor to VisualEditor on
the same pageload.
Bug: T221191
Change-Id: Ibafec77b2eabd3b3b3767472b7b5a40e3312bf18
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
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
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
* 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
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
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
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
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
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
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
Generating the templatesUsed list is relative slow, and is only
used in an obscure part of the editor, so only generate it when
needed.
Bug: T209078
Change-Id: I1cecdad65b80c4c9b1746e752ea4b41bc0fc0037
This code, added in 703b2c2ed0 (2015),
is no longer necessary.
// Disconnect the tool factory listeners so the toolbar
// doesn't start showing new tools as they load, too
// much flickering
this.getToolbar().getToolFactory().off( 'register' );
Introduction of targetLoader (d371014e5d)
resulted in all tools already being loaded before a Target is
constructed, so this is definitely not needed.
// Disable all the tools
this.getToolbar().updateToolState();
The tools are already disabled because we set the surface to read-only
above, so this does nothing.
Change-Id: Idb162b60891cd1b961e29d2b9f62b74908f17957
Previously, we tried to keep the list of category members and the file
thumbnail, history and metadata visible while the editor was open.
I am removing it because:
* It is not very useful, as you can't interact with them (e.g. links
are unclickable).
* It is inconsistent with the wikitext editor (except for non-existent
category pages, and I'm proposing to change that behavior in T139191).
* It causes issues when other code doesn't expect the special setup
for those pages (T194068).
This introduces a minor change to the handling of normal pages: after
the save, instead of replacing all contents of #mw-content-text with
the new page content, we only replace the .mw-parser-output child.
Normally the effect is the same (it's the only child), but this could
theoretically affect interactions with other extensions or gadgets.
Bug: T194068
Change-Id: I26cc82d3e0f0d64e3f18a80d232005fc7ab3b374
Red-link metadata was added to Parsoid 18 months ago.
On long pages evaluating this information is very slow
(hundreds of milliseconds) and completely redundant.
Bug: T64803
Bug: T209078
Change-Id: I5b6c6da588301ed59fb21e1ce930f5b72db48e67
Per I7c083ff57db2fce9a06688d5801149253af6f6da this was only needed
for IE 8 & 9, which we don't support now.
Change-Id: I6e093b8ea6f8304ff296bb74297a465dd7334e07
Using margin instead of padding allows the surface margins to collapse
with the margins of first/last paragraph inside the surface, like they
do in read mode. This fixes the slight jump seen in T210630#4949865.
Bug: T210630
Change-Id: I69d4d4bd9390a1007bc40cda9e78a6b3e7a1bd1d
Icon name changed from 'previous' to 'close'.
This matches MobileFrontend's wikitext editor and other overlays.
Bug: T210630
Change-Id: I5f588c65887dd2247d3f816959807f943215e0c3
New changes:
6515e03e1 ve.ce.Surface: Rearrange #findBlockSlug test to check other cases
cbfdc8570 Localisation updates from https://translatewiki.net.
708ba0557 Prevent block slugs from overlapping floated elements
3703fd66d Separate the concept of a document node and a root node in CSS
Bug: T211844
Change-Id: Ia86cf9b23e561d3c32601d41c1bc5a9824e9953c
Previously we passed either data.visualeditoredit.edit or data.error,
which was mostly okay since they are mutually exclusive, but it could
still theoretically conflict if both objects had identical properties
(and receiving different things could make debugging errors harder).
Change-Id: I818d916275b8451af6910ddaa7cd4d7c653085ee
This has been moved to the TitleBlacklist extension.
Bug: T211242
Change-Id: Ia15c2619e6c642b3ceb567c28f77b50ccf41731a
Depends-On: Ibaf8a37f1aaef510923bde5ed9114f1f00fff461
* Move (de)activationComplete up to ArticleTarget
* Mark (de)activate to be deprecated in the future
* Fix some properties to ensure target.edited is boolean
Change-Id: Ie34139cb68f90f34eb243f1bb964ef578e90dfb2
The timing variable is a private closure variable containing an object
that tracks the timestamps of different events in the current cycle. The
duration variable is the result of using that information to compute the
difference between the current timestamp and the relevant anchor
timestamp. For the '_timing' property in the EventLogging data, duration
is the correct value, not timing.
(This is confusing and we should probably rename the timing variable.)
Change-Id: Iff78eb0ab83c84b73ad5c8f3eb85b1c7f120ebef
Follows-Up: Ifc2135d99f4bec917dac60992098958b72c37fc6
Moved to their respective extensions
Change-Id: If463068a862cfde15ab4d250a1424c88a5229176
Depends-On: Ib1354f0404209a15194895026ff9d179d16b1900
Depends-On: I1807a5d3d99ecab2bf4545a1bab3aa3f2ae64da8
This early return in loadSuccess() has been incorrectly removed in
b2718b186a.
As a very unexpected result of loading the editor twice in case
loading metadata is retried, the "Publish" button was staying
disabled. See the task for investigation.
Bug: T209542
Change-Id: If528afe1ca052062005937f03fe822c5c8d0958b
* Also make sure block notices have type 'block'.
* Remove old flag for tracking since we'll be using one
from core
Change-Id: I4b66e73c8a4c4dd7bffd7c0239b1d5ec06eed12f
Depends-On: I6bd1c95548616677e1f72ba6bcfc6f2b551c1ca6
These aren't supported by VE-MW, so must just be
garbage from a browser plugin, possibly Citavi.
Bug: T200971
Change-Id: I9f34e9890e7f59d76cd464778481c415cc3c5dbd
* Use ve.getProp
* Use .abusefilter key instead of string search (the key
didn't exist when we first implemented AF support)
* Move AF handler next to captcha handler, and comment
both as should-be-moved-to-plugin.
Change-Id: I171d63844b84b5a12396b6d6746f92110fc06c6c
When an edit notice is passed through from the API, allow
a type to be specified, and specify type 'block' if the
notice is a block notice.
If VisualEditorTrackBlockNotices config is true, track
when a message with type 'block' is shown.
Bug: T209633
Change-Id: If5fecc2c2c1c39f4b7245b9a215e1120c93b2b22
For now this is just moving code. In the future we will
be able to make the handling of edit metadata async.
Change-Id: I7b442dfbdd890154de0e7faab1f6b0346caa8de0
* Make inserting secondary tab work with Minerva's non-standard structure
of navigation menus
* Distinguish primary and secondary tabs with tiny icons, since Minerva
hides their text
* Hide section edit link dividers (unnecessary when we use icons)
Bug: T208102
Change-Id: Ieaec60165617e3b423ec58857d6f0a0406e22b1d
New changes:
3d2ffae4e [BREAKING CHANGE] Have ve.htmlMsg return a node array instead of jQuery collection
Local changes:
* Have ve.init.mw.Platform#getHtmlMessage return a node array
Change-Id: Iabd823c851f94356f1902918278f88068dfe4d25
The schema itself is being renamed, many of the field names are
different, and two new fields were added (page_token and session_token).
Bug: T207803
Depends-On: I2949c9782669b75cf17978698c8cef21fdee6dea
Change-Id: I3ec11d74d71207acac130689bac93d5bf0c70715
Respect the config var exported by WikimediaEvents that, if set to true,
forces oversampling. When oversampling, all events are logged even if
they would have been sampled out. The isOversample property is set to
true if the event was oversampled and would not otherwise have been
logged.
Bug: T206543
Depends-On: I5fdf5fdd2dc0d99a0a0d7eb7ab2e3dce4798009b
Change-Id: I314da47d7d250672f1a9b34edeeeb720850f8fac
Instead of hard-coding the 6.25% sampling rate, allow it to be
controlled by the config variable in the WikimediaEvents extension
(which also defines the RL module for the Edit schema).
Also use sampling code from EventLogging so we can configure the
sampling rate as a number, rather than using a hex-digit based strategy.
Bug: T206543
Depends-On: I00383cec62f6c2a0137b329565b0ca84bfbb223f
Change-Id: Ia3e9a0f93d5d3001f222a64f31e82a63db36d7ab
Rather than computing all the data then throwing it away 93.75% of the
time. Also use .charAt() for consistency with WikiEditor.
Change-Id: I6360b5c636e94db3483f542791d158f240c542f8
This won't really do anything until the patches to ve-core for the activity
events, and WikimediaEvents for the schema land.
Bug: T202148
Change-Id: Ie462a24f66240a1accfd0185c46273e60effbd64
I ran Closure Compiler over the codebase just to see what would happen,
and it printed some useful warnings.
Change-Id: I56d40b11e6d1dd7ce68a5e59da511f66e928647f
I suppose technically you don't need it if you're already on an
?action=edit page, since that will cause the editor to load as well.
At a glance nothing seems to break if it is missing (other than the
fact that there is no way to launch the editor, obviously).
Bug: T179427
Change-Id: I3c221ded302702b881857930da5dc41630680c02
Requires I28278449512ed1e5e8c4ac6ae390334a26d1bad6 in
mediawiki/skins/MinervaNeue to be merged at the same time.
There should be no visual change if both are merged.
Change-Id: Ia13f758a6870be2e6c89fd11f2ee3544ac61a1d7
In WikimediaUI theme, the height of the toolbar is defined with
'padding-top', but in Apex theme, it is defined with 'height'.
Set both properties to make this work with both themes.
Remove unused styles for the dropdown. It is now positioned by OOUI
(since T192505). This should have been done at the same time as
e1635fdc52.
Bug: T194120
Change-Id: I9cac0c9458ae8cc26c5f056bb26686f8ad50c493
New changes:
a273ba69c [BREAKING CHANGE] Implement a SourceConverter
Local changes:
* Use SourceConverter
* Handle `this.doc` being a string in source mode now
Bug: T203114
Bug: T203156
Change-Id: I7bce7b57668e0c1dd511803a54178ae69694a86d
ve.track tries to guess the platform, but it needs a loaded Target to do so,
and init happens before that.
Also, log a warning when this happens, in case it comes up again.
Bug: T203618
Change-Id: I35fa58a42cd247e01f3717c9ab3a10d8ea93a484
New changes:
3b62827b8 Remove negative margin from mobile context action buttons
694705894 Implement a simple notification system to fill in for mw.notify
461283560 Validate history start when applying/unapplying change
Bug: T202514
Change-Id: I203dc5101bc31988df2d3986da4300a318e5e889
Just call the method after surface init.
Also move all the post-dm building code into
an #addSurface override.
Change-Id: Ie40baadfa6cd826a92f8fb7d928f4d995286f69f
MWTransclusionNode will preserve TemplateData <style> in its generated content.
Disable TemplateStyles stylesheets in the original page content, and reenable
them when the surface deactivates.
Remaining TODO: if multiple copies of a template with deduplicated styles are
on the page, and the one containing the actual <style> is removed, all will
lose their styling.
Bug: T197563
Change-Id: Ibd8939eef7d8eb532719f4ee0ce200600449ef81
Depends-On: Ia9f2afcdba5456238e3ef444c202c9b0c78838bf
This padding needs to come out to an exact integer pixel value (14px),
otherwise things are off by less than a pixel and look ugly: F24664180
1em = 16px
0.875em = (14/16)em = 14px
Bug: T190596
Change-Id: Ieb292ed14e0b9205d15254667e97613fbf339260
Refactoring in 92c4e23 didn't account for the case where there are multiple
tabs and source mode isn't NWE, which caused the "edit source" tab to just be
a page- navigation that always discarded changes. onEditTabClick handles this
case fine, so just always bind the handler.
Bug: T199655
Change-Id: I3dca87a7a3b0ea88ef0008be89cd1f6007167916
The #getReadyProcess method should be used pretty much only to focus
a field inside the dialog after it is opened. It runs after the window
opening animation finishes, so if you add stuff to the window here,
that will be visibly delayed.
The #getSetupProcess method should be used pretty much for everything
else that depends on the opening `data`. It runs before the window
opening animation, so if you add stuff to the window here, it will be
visible while animating it.
Bug: T185944
Change-Id: I71ea5b6e1e1947c1cf8fd749100e854953a8ef3c
The linkCache fetch can push the categories out of order unless everything is
already in cache. As such, remember the initial order and enforce it after the
promises have resolved.
Bug: T197759
Change-Id: I9ea8d5e642f62c96475d0713f2c79258abb33b19
I.e. don't sort them, because they're provided in source order and that's all
we need.
Bug: T197759
Change-Id: I3b9508ff49233ccfbeba1d111a6df9f29f0fc318
They look like they should also apply to Flow, ContentTranslation, etc.
And apparently CollabTarget was already loading them separately.
Change-Id: I5c502f8e060968ecee67567747f29eb630cda718
If the wiki runs on a host that contains a port number, section edit
links would always reload the page, and the "Add section" tab would
not work.
As it happens, my local testing wiki runs on localhost:3080.
It is an unfortunate naming mishap:
* mw.Uri#host is equivalent to location.hostname
* mw.Uri#getHostPort is equivalent to location.host
In this case, we have to compare the port too, otherwise a setup (my
setup ;) ) where one starts up another wiki on localhost:3081 to test
cross-wiki features would fail.
Change-Id: Ib7de4ba3c3a84888f24186af03bd9dcced131051
What happens when an edit tab is clicked is spread across handlers in
DesktopArticleTarget and DesktopArticleTarget.init. Consolidating the logic
into the handler in DesktopArticleTarget.init makes it easier to understand.
It could be moved further into DesktopArticleTarget, but the init handler has
to exist to activate the target in the first place.
This patches a hole where clicking "edit source" while in visual mode would
sometimes not switch to source mode, because it didn't think it was changing
the current section.
Also, fix a typo in the documentation.
Bug: T198272
Change-Id: I12d958b6af1b9fa9aca68b498eb2a1a2d76b5a82
aeb4f2f2b7 added a #wpTextbox1 to the wikitext surface, which confused our
existing teardown check. This confusion only became apparent in single-tab
mode, when using the wikitext editor.
Bug: T197615
Change-Id: I98e64e7135aaf6f8fda441a91e6cbc4bac6cea39
We already do it after save, but not if the editor is closed without
saving.
This behavior is a bit awkward for non-existent pages (redlinks),
since MediaWiki normally doesn't display them in view mode (all links
point to action=edit). But this seems less weird than not allowing the
editor to be closed.
Bug: T122388
Bug: T168338
Change-Id: Id9ee41356f011dfbfa6e8744b8d9076f8eacaf39
New changes:
71baf1c02 Create an 'htmlMsg' function for HTML messages with HTML or DOM arguments
9a7af223e Use ve.htmlMsg to highlight values in attribute changes
a1fd90540 DiffElement: Refactor describeChanges tests
Local changes:
Implement getHtmlMessage in mw.Platform and use for DiffElement
Bug: T195243
Depends-On: Ib4ad16858e4241d33d018830dbcfded63ff703af
Change-Id: Ib5fa39e4f2f529948354b03a141542e23d169fe0
Not checking this results in handlers blocking click actions for "read" after
the teardown of the target.
Bug: T197445
Change-Id: I3a962c66c82a0e48ca54bf2f0b822a9a005da54c
Previously, we changed it on every load, which also occurs when
switching editor modes. That caused it to not be restored when editor
was closed.
Bug: T197490
Change-Id: Icb20c38309fd440553d5245d865b05145542313f
Besides redirects, API can return from-to title pairs for normalized and
converted titles, as well.
Currently, doing an API query on eswiki for page info (prop='info' in params)
with titles='User:Title' returns normalized title 'Usuario:Title'.
processResult() method in ve.init.mw.ApiResponseCache.prototype.processQueue
sets page.title ('Usuario:Title') in cached results, and the promise for
actual queried title ('User:Title') gets rejected in rejectSubqueue() method.
Change-Id: I33fd4640b6eac8018e35c6fe21234f4c469dd97d
In Schema:Edit, all action timing durations (ready, loaded, saveAttempt etc.)
are defined as "time since the editor was initialised", which is internally
stored as the timestamp for the "init" action.
The 'init' action itself does not have a timing duratation, but the Edit schema
has a special case for it, definining it as "time since the page was loaded".
In actually, it isn't actually implemented as "time since the page loaded",
and I suspect that as such, this value is probably not used by EventLogging
consumers of the Edit schema. Or, it might be used, but doesn't represent
what the consumers think it does.
Presently, it uses the init time now() - mediaWikiLoadStart, which basically
means the time between the random point at which MediaWiki core JavaScript
finished executing which is quite variable in practice due to the race between
<script async> and browssing parsing/rendering of HTML. That is by design,
and is also why mediaWikiLoadStart is undocumented and internal, and actually
in the process of being removed.
After many iterations on this patch to try and approximate an alternative to
this undocumented variable, I came up with an alternative approach with DLynch
at the Hackathon, which is to simply not record this one timing value, but
preserve the behaviour of all the other timing values exactly as-is.
That is, keep the behaviour of storing `now()` as "init" when the editor
activates, and keep the behaviour of substracting "init" from all other action
times, but only don't report "init" itself to EventLogging (given its value
would be 0, which isn't useful).
Bug: T160315
Change-Id: I778234efe40dde8ff30333339335be1c3910a4e0
We were scrolling to the edited section when we saved the page, and otherwise
reverting scroll position to the top if we just abandoned the edit. This
unifies these cases, so any section-edit which leaves the editor will scroll
to the section being edited. (If section==new and the edit is abandoned, it'll
scroll to the last section on the page.)
Bug: T194631
Change-Id: Ic2aca68b3127c435545644912b96212bcfa6648d
If the mediawiki Api pass redirects as true, the response will have
redirect data. ApiResponseCache ignores it now. This commit adds
support for processing that and set in the cache.
Change-Id: If4f8c9b6719c123b31d852eb71f06a79cc0f7917
Cite's a08febb0afa2d changed the rules for adding the Cite button to the
toolbar – it now requires a placeholder slot in the toolbar, rather than
finding the link tool and adding itself after that. As ve.init.mw.Target
was updated for this it kept working on desktop, but MobileArticleTarget
completely overrides the toolbar, and was missed.
Bug: T195191
Change-Id: I55c9de9e736bb83f5f05028f2fc07af0ad996050
Pressing escape will close toolbar dialogs (find/symbols/etc) if they're open
instead of trying to teardown the editing surface.
Bug: T190068
Change-Id: I27080649392f17344c901269029368fa0b3c2963
New changes:
3a6d868bf Separate (Comment/Link)InspectorTools into separate files
cb5d36e32 Localisation updates from https://translatewiki.net.
c75491b16 build: Extend 'svgmin' options and amend
ddef270d9 Genericise activeLink behaviour to any annotation
d13d44e12 Create simple comment annotation type for rebaser.
7e49a1f33 Add getters for author properties
1d341ca7d Follow-up I16942623d: Only filter inactive models if they are 'canBeActive'
Local changes:
Change .ve-ce-linkAnnotation-active > .ve-ce-linkAnnotation.ve-ce-annotation-active
Bug: T185596
Change-Id: I2a49315d01aa075373f9b5f0d8802a7e7dd4dca3
Override #addSurface instead of #getSurfaceConfig, so that the
$overlayContainer option only applies to the "main" surface of the
Target rather than all of the surfaces (including those in
TargetWidgets).
Bug: T194433
Change-Id: I61c609e2d52814b4547fb5292a0bfb237c4c218f
Just generate the standard wiki skin markup for categories. Adjust linkcache to always know
whether links are hidden categories. (It previously knew *sometimes*,
depending on whether a MWCategoryWidget had interacted with that category.)
Make the save dialog preview use the same method as the bottom-of-editor preview.
Bug: T194092
Change-Id: I37fea15eaef0a5847f27ce41dd92370a4bf353b6
New changes:
14bcc9256 Give toolbars groups names
Local changes:
Give toolbars groups names
Also create an empty placeholder group for reference tools.
This allows targets to specify if they should show them.
Depends-On: Iccaf35cf941cb47ad55e8d98373461f5eaff5fed
Change-Id: I0bace5e5fe05f9c214d57a74c478b48a7dcaec3b
Pass through the current document when available, otherwise
assume the current surface's document.
Also add a getter for getPageName, so that can vary based
on the target document.
Bug: T193856
Change-Id: Ifdc951fdc6a43b924d102e3fcd7e59e52023757b
When the user is viewing the last stable revision of a page which has
newer unreviewed revisions, FlaggedRevs wants us to open the latest
(unreviewed) revision of the page for editing.
Use the JS config variable 'wgFlaggedRevsEditLatestRevision', provided
by FlaggedRevs since change I4c9804fe2c4924e28770807881379ddca4fd8b76.
Also add an extra comment about loading latest revisions in general.
Bug: T165283
Depends-On: I4c9804fe2c4924e28770807881379ddca4fd8b76
Change-Id: Ic47491e690153d0ad87ce64bfc9e7a28a06fc6e2
The duplicate header, especially the duplicate elements with identical
IDs, were difficult to handle for other scripts.
Now instead of hiding the entire wikitext diff, we only hide the
"content" rows but keep the header, and adjust our attributes on the
header back-and-forth when switching diff modes.
Bug: T192755
Change-Id: I3a6bb4730fefd81f533b786ec3b20241c4cb8d13
When we set up the new section title input and possibly set its value
(preloading from URL query, or from autosave), the "Save" button on
the toolbar must already exist, because we try to enable it.
Bug: T192901
Change-Id: I3bba86a8c8a9b81014d425db256ff49f06bdaea6
Ensures that auto-save data is cleared after
creating a new article, or restoring a revision.
Bug: T192770
Change-Id: I348b8522c1a935d7db1243ba8fcbd5b24e3383a2
These are not specific to desktop.
Also make the static builders static, and move VE target specific
code to caller, such as the click handler.
Change-Id: Ib7e769e3d6d339b9e66e1bc924480b0b0d5db17d
Removing `0.8em` VE special base `font-size` for UI as we're unifying
OOUI interfaces to `14px` equals to `0.875em` at user agent default size.
Bug: T97631
Depends-on: I693d168d2ccf2babbcfe8952af3e1c262aa97773
Change-Id: I84edeec38ecfb90f5d53199f3b26fc3f83ab0611
It's possible for some load failure states to cause this teardown at a point
without a surface. I observed it in MobileFrontend, when restbase can't be
contacted.
Change-Id: I13489640759c73dad5730d0bbadbfb2a38cb8e53
This lets copy-paste between documents retain the numbered status rather than
falling back on pasting "<a>[3]</a>".
Update the part of LinkCache which selects on mw:ExtLink, so it will handle
possible multiple values in the link rel.
Bug: T188429
Change-Id: Ia5e4c9fa45e94da9cbfcd2a42d017d0fda1c511f
Always store immediately if fromEditedState is true. Also
now that we only store if there is state to recover, remove
the check for transactions before deciding to show the notification.
Change-Id: I5357a9098b91e303f5c71881ea03a080d2969fff
Specifically, set arabic(extended) and hebrew to 'rtl'.
Logically depends on I14abd3e0c0d23f79aa01d96c216eea913024b4c8
to set the dir attribute in UI.
Bug: T56310
Change-Id: I1c7e28d3d2f20ca84115be6d49650cd9a81d78dd
1. It wastes valuable time during setup.
2. If a user reloads the page without making changes we
should give them the latest html from the server to
minimise the chance of an edit conflict.
Change-Id: I9a1f8cfd65ef2552fe2c3d6d2bbf975851b52003
