Sun, Jun 6
Without the toolbars, the interface is less unwieldy and easier to navigate, especially on mobile:
Sun, May 23
Mar 16 2021
Hmmm I'm not seeing this as a regression — I get the same behaviour going right back to 2016. Investigating further.
This is due to a Firefox issue. A minimal test case for it is:
Mar 2 2021
Jan 16 2021
Oct 21 2020
If I've understood the meaning of the diagram above correctly, I don't think the fallback case will ever happen — because LanguageConverter will always return output for whichever zh variant is specified.
Jul 2 2020
Further detail (from discussing with @DLynch): it's not clear what document data a top-level wrapper could usefully expose as a Vue-style reactive property.
Apr 24 2020
Ah, i see ... with TreeModifier, pressing Enter at the end of a paragraph leaves that paragraph unchanged (whereas before TreeModifier, it was getting rebuilt entirely). Then it moves the focus into the new paragraph below. That means we're escaping the paragraph without cleaning up the unicorns, which the current code assumes to be impossible.
Mar 18 2020
Mar 10 2020
As discussed, I'll base on https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/DiscussionTools/+/578387/ and use the https://en.wikipedia.org/api/rest_v1/page/lint api.
Feb 15 2020
Jan 28 2020
The table selection update is incorrect, because we're calling tx.translateRange with excludeInsertion=false, but there should always be excludeInsertion=true for a table.
Jan 22 2020
The technique in https://gerrit.wikimedia.org/r/539074 does work. And I've used that patchset a few times now to debug silent errors. But it's perhaps too hacky to merge even for debug mode only (it shadows each jQuery promise with a native promise). Maybe it could be merged but needing specific activation.
Jan 7 2020
Dec 19 2019
Dec 3 2019
Apologies @sbassett , I judged the patch wasn't particularly revealing but maybe that wasn't really my call. Given it's already up, should we now proceed as we would with a non-security-related UBN?
Dec 2 2019
This patchset should fix ithe security issue: https://gerrit.wikimedia.org/r/553888
Nov 27 2019
Oct 21 2019
Yes that looks like the same pattern – thanks for the additional info!
Technical details for triage: this is triggered if a transaction contains a removal starting in the interior of a text node, crosses an inline element, and moves immediately into another text node, and then is followed by a subsequent retain and removal. See the patch set above for a minimal example.
Oct 12 2019
I can no longer reproduce this on https://en.wikipedia.org/w/index.php?title=GC_skew&oldid=917245666 – Adding a link annotation to "locations plotted 5′ to 3′ and y-axis" appears to work fine.
Oct 10 2019
Change 541995 fixes the real-life example above.
Steps to reproduce real-life example (from T234142):
Oct 8 2019
Example 3 is not fixed by Change Set 541088. It is a different bug, which I've filed separately as T234881 .
Oct 6 2019
Change 541088 appears to fix every failure case given in the subtasks. (I loaded them all up on the live sites, in-browser patched the code, and cofirmed they no longer fail).
On investigation, all subtasks are failing for precisely the same reason, so we should probably fold them into this task.
Sep 21 2019
Sep 16 2019
Sep 15 2019
Aug 22 2019
Ok, I've added the extra emit method, but with the name emitThrow rather than emitSync, since that makes clearer how this method differs from plain emit: see https://gerrit.wikimedia.org/r/#/c/oojs/core/+/529726/8/src/EventEmitter.js .
Aug 20 2019
Aug 13 2019
I filed a separate task about using window.onerror (T230441)
Aug 12 2019
Aug 9 2019
Ok, the VE engineers have now examined many different possible VE-level fixes to this. Unfortunately, all seem to worsen the codebase.
Aug 2 2019
Hmm, can we perhaps modify the prototype on loading VE? I think when VE is running the chances of anything (VE or otherwise) relying on the non-catchy behaviour are pretty low.
Change 527510 is the code from 84df3f0b9f59626749db6e00b197c18979b0bacd , reimplemented inside VisualEditor as an extension of OO.EventEmitter.
Jul 23 2019
Jul 13 2019
Jun 24 2019
On looking again, it seems enabling input debugging changes the behaviour (at least now it does).
Jun 23 2019
I think this is looking more or less in shape. How about we work out a fairly quiet time to merge it? I ask because, although in theory the behaviour should be unchanged, in practice the internals are fairly radically new, so it would be good to have capacity for reactive QA / debugging if required.
Jun 3 2019
May 9 2019
Hi @deryckchan , do we know which IME / browser / Cangjie IME software combination User:恐狼博士 is using? I can't reproduce the problem, and I've tried a few different Chinese IMEs on zh-yue.wikipedia.org using 2017 wikitext editor, both mobile and desktop.
Apr 11 2019
My only immediate thought to add is a reactive corrector may need to make the same small correction across a few places. E.g. updating a statistic mentioned in an infobox and in free text. For consistency, you wouldn't want to commit that change in two stages.
Apr 4 2019
I am reasonably satisfied with Change 498528 now. I cannot find a case where this breaks input, having tested on multiple types of IME, on Chromium, Firefox and Safari, and on Android, iOS, Windows, Linux and MacOS. Of course, there are almost limitless combinations, so it's always possible there is some breakage I've not managed to find.
Mar 18 2019
Mar 1 2019
To see the real speed benefits of section editing, we may need to test long articles on entry-level devices. Here are recordings of a stark difference, editing United States on the (entry-level) Xiaomi Redmi 6A.
Ok, with Gboard English, this is what happens when you select "de</h1><h1>fg" and press backspace:
- The selection collapses to the end
- A keydown event with an unknown keycode is fired
- The content is deleted (unifying the paragraphs)
Feb 27 2019
Feb 12 2019
See also T215717 (which is a related optimization task, but not a blocking subtask)
Feb 10 2019
Feb 9 2019
Thanks, those "steps to reproduce" are impressively precise. I will investigate.
Feb 8 2019
Oh, good point – yes, that is correct.
Feb 7 2019
Jan 22 2019
Let's go forward with your patch, because it's simple, neat and works fine for links, which in practice are by far the most significant case.
Jan 17 2019
@DLynch : Do you mean when setting up a view selection or a model selection?
Jan 14 2019
I think the current approach is about right for links, which have "nails" anchoring the annotation boundaries – I'll review the details of the patch later on.
Jan 11 2019
@Neil_P._Quinn_WMF : With our implementation of section editing (T76541), we're fetching, loading and editing against the full article's data model in any case, so in technical terms a "continue editing with full article" button would be feasible.
Dec 15 2018
Nov 26 2018
Hello, thanks for the detailed explanation.
Nov 20 2018
Still thinking about programmatic (a.k.a. "fake") selections, but stepping back from the idea that they should be as similar as possible to real ones, some sort of mechanism to select large amounts of content would be useful for large copy/paste tasks (see https://www.mediawiki.org/wiki/Topic:Ul1orwmwk2q32l1v for one such request)
Nov 16 2018
Oooh, thanks. Do we think the behaviour happens because of setTimeout subtlety? (That would instinctively be my first guess but I haven't checked).
Nov 14 2018
Oct 31 2018
See also T208428 .