It's done because a model change within a ContentBranchNode gets propagated to the view by replacing the entire contents of the CBN, which resets the native selection to the start of the CBN.

How about "topic is renamed"?

Deleted text is supported by resolving T230325 . Deleted DOM nodes need T230323 (which does not fix deleted text).

Glitch behaviour for the 754986 option

@matmarex coded the approach of styling the link node with "white-space: no-wrap", then adding an inner span styled as "white-space: normal". See here: https://gerrit.wikimedia.org/r/c/VisualEditor/VisualEditor/+/754986/

Confirmed that this happens even with the cursor outside the link cartouche. It happens because the paste is calculated entirely within the DM, and the DM cursor positions do not specify on which side of the annotation boundary they lie.

Some brief points from our conversation just now. It's great that you're looking at this issue early on, so thank you!

Hmm, can't reproduce the behaviour on iOS 12. Can you give a specific minimal example (exactly what content, where to click etc)?

I think the second patch means you may have to tap again sometimes to get into the link, but that's better than not being able to drop the cursor outside the link at all.

Without the toolbars, the interface is less unwieldy and easier to navigate, especially on mobile:

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:

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.

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.

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.

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.

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.

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.

Ooh, thanks!

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?

This patchset should fix ithe security issue: https://gerrit.wikimedia.org/r/553888

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.

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.

Change 541995 fixes the real-life example above.

Steps to reproduce real-life example (from T234142):

Example 3 is not fixed by Change Set 541088. It is a different bug, which I've filed separately as T234881 .

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.

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 .

I filed a separate task about using window.onerror (T230441)

Ok, the VE engineers have now examined many different possible VE-level fixes to this. Unfortunately, all seem to worsen the codebase.

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.

In T215717#5330166, @Esanders wrote:

Monkey patched on live and edited a section of a long article (mobile site on desktop) (https://en.m.wikipedia.org/wiki/Megan_Rapinoe)

Testing second load times (i.e with the code and page data already fetched and cached), time to loaded was ~2300ms without the patch, and ~1300ms with.

On looking again, it seems enabling input debugging changes the behaviour (at least now it does).

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.

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.

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.

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.

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:

1. The selection collapses to the end
2. A keydown event with an unknown keycode is fired
3. The content is deleted (unifying the paragraphs)

See also T215717 (which is a related optimization task, but not a blocking subtask)

Thanks, those "steps to reproduce" are impressively precise. I will investigate.

Oh, good point – yes, that is correct.

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.

@DLynch : Do you mean when setting up a view selection or a model selection?

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.

@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.