Hello, thanks for the detailed explanation.

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)

Oooh, thanks. Do we think the behaviour happens because of setTimeout subtlety? (That would instinctively be my first guess but I haven't checked).

See also T208428 .

I filed an upstream bug about the dragging across ce=false: https://bugs.chromium.org/p/chromium/issues/detail?id=894003

Maybe we should experiment to see whether we can get anywhere using newer features now fairly reliably available on Chrome mobile, e.g. shadow DOM.

Hi @Neil_P._Quinn_WMF , the configuration variables shown here should help:

Here's a version where the text is more or less readable, but JPEG compressed enough that Phabricator accepts it:

I guess this may be the same issue as in T203555.

With input debugging enabled, it's easier to see that if the selection pin lands between the pre-close nail and the post-close nail then the selection collapses. In fact you can see this just editing <h1><a href='x'>foo</a> bar</h1>.

Given the context disappearance is an iOS-specific issue, would it be worth doing the 60px scroll on non-iOS devices only?

This is working now; I guess it has been since 2d8c3e799601d3eb70127b32e262dbe1d64a7e4e .

Thanks @kaldari! As I understand it the fundamental differences between T76541 and T146072 are:

@matmarex Ohhh that's a really good point. And unfortunately you're right to be suspicious; some IMEs can add / remove whitespace without committing all candidate text so we can't safely rerender.

@matmarex , do you want to go forward with the solution you suggested? (I.e. use &nbsp; for every other space, on NWE only)

Hmm, looking at the Filibuster trace, it looks very much like the native backspace action leaves the DOM unchanged. Will investigate further.

@Esanders , should we work round this by having a minimum gap above the CE surface?

I don't know much about this, but will/can we get the data broken down by wiki (and therefore effectively by language)? That could be pretty useful for script / IME support purposes

It's still possible to trigger this bug, though Change 247800 made things much better. Will update the description.

Ok, I think we should worry about Firefox in a separate task, because the issues are different (and I guess more intractable).

Ok, I added some code for cursoring downwards out of a caption. Note though that none of this code fixes things on Firefox.

I agree with @matmarex 's proposal that we shouldn't revert to the &nbsp; behaviour for visual editing (because we want nbsp to represent actual non-breaking spaces). It's a different issue in wikitext because non-breaking spaces are inferred heuristically.

Ok, I created T201599 for the separate slug cursoring issue, which is really a corruption problem as @Deskana suggests.

And the problem happens because Chromium natively puts the cursor into the slug even though the click is outside the slug, but not in Firefox because its native behaviour is different (it puts the cursor directly into the surrounding div).

Clicking twice to the left of the node puts the cursor into the slug text and lets you edit it

This is reproducible with any focusable block node, e.g. on this minimal document:

<hr>x

I feel the following code isn't that sensible now that meta items live in the main linear data:

Thanks! I'm not seeing the error, with parameters: page=Foo&from=en&to=es&targettitle=Bar&version=2&revision=<XXX> . It seems to work fine for me, on both my local installation and on wikipedia.org . Can you confirm a particular page+paragraph that fails for you on wikipedia.org?

Hi @Petar.petkovic, can you tell me steps to reproduce the continuing issues (after Change 446198) you mentioned above? The points you make in T199754 look good, but I'd like to have a failing test case to verify against.

I'm also failing to reproduce this — I tried on 4c51ee9ec57678f29b320868161d570dba7c4ccb and on aca98533eab67e3154c4b243cbcadd155b69398e .

Thanks, that solves it for me - is there any way that can be the default (at least for Unified)?

Sure, thanks

Let me comment on the specific issue of modality. There are definitely parts of the VE code that assume dialogs operating on a portion of the document must be modal. One example is that there's a transaction undo stack that mirrors the dialog opening stack. Another is that there are places where stored offsets could be invalidated if the main document remains editable while the dialog is visible.

@Esanders : yes, that seems to solve the issue, both in my local testing and when I monkey patch the live pl.wikisource.org page above.

As well as the approach in https://gerrit.wikimedia.org/r/433753 , we should also consider the following alternative:

• A class provides the LinearData interface on a live slice of the linear data (performing offset translation and bounds checking)
• ve.dm.Document builds on top of that class

That approach would more robustly prevent access outside the slice. But one drawback would be apparent dangling references in the slice.

Here is a proposal for refinement:

With change 430413, "change citation, undo, redo" seems to work fine in all the cases I've tried.

Hmm, thanks, it seems I overlooked that there are a few different ways reference-instead-of-copy can happen here - investigating further.

Ooooh, this happens because ve.dm.TransactionBuilder#pushAttributeChanges( { key: val }, ... ) puts a live reference to val into the Transaction object. So if val subsequently gets mutated, that invalidates the Transaction object.

A hotfix for the problem I describe is to open the console (CTRL+SHIFT+i), then type

$( '.ve-ce-surface' ).css( 'word-break', 'break-all' )

then press <ENTER>, then close the console (CTRL+SHIFT+i again).

Oh, I can reproduce what might be the same problem, or at least related: I think it's to do with browser rules for wrapping spaces.

That sounds like a good idea, because even if we switched to listening for keydown, we'd be depending on our keydown listener to run first, which would be quite brittle.

@MusikAnimal I think listening to keydown might work here, but might break other uses of jQuery.IME . If it does work here, perhaps we could consider making it an option. Anyone want to try changing the binding and see whether it works?

Thanks SoWhy, things like this would happen during the HTML->wikitext conversion in Parsoid, so I've tagged it as an issue for the Parsoid team to look at.

Thanks, that's most informative and makes me understand the situation a lot better. I wonder can we publish this sort of info for users in sensitive situations (if we haven't already) — and I guess advise them to use something like tor if they still have really serious concerns.

Well, it should improve such situations by giving us the precision to treat them all properly.

Oh, the keypress behaviour we're seeing in Chromium doesn't seem to happen on the CodeMirror demo, either on https://codemirror.net/index.html (presumably the current version 5.35.0) or bundled in http://codemirror.net/codemirror-5.30.0.zip (which is the version the mediawiki extension currently includes).

See https://gerrit.wikimedia.org/r/#/c/419151/1..2/modules/ve-cx/dm/ve.dm.CXBlockImageNode.js .

Oh, of course - we have to allow mwImageCaption to have cxBlockImageNode as a parent ... I'll upload a patch

After debugging this with the help of @santhosh , It seems ve.dm.Document#fixupInsertion is returning unbalanced data . Before the fixup, we have:

Ok, I put some small fixes into https://gerrit.wikimedia.org/r/#/c/398602/5/ and https://gerrit.wikimedia.org/r/#/c/399460/5/ .

Hi, it's currently not working for me on either Firefox 57 or Chromium 63, both on Ubuntu. Here are exact steps to reproduce:

Hmmm, that makes sense, because since 21a5d55b85dd , we only round-trip the meta item back into the ContentBranchNode on serialization if the ContentBranchNode is unmodified - so clearly if the <nowiki/> is being used to separate out pieces of wiki syntax, the behaviour will now not be as intended.