Mon, Jun 3
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 .
Oct 30 2018
Oct 29 2018
Oct 24 2018
Oct 10 2018
I filed an upstream bug about the dragging across ce=false: https://bugs.chromium.org/p/chromium/issues/detail?id=894003
Oct 9 2018
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.
Oct 4 2018
Hi @Neil_P._Quinn_WMF , the configuration variables shown here should help:
Sep 26 2018
Sep 19 2018
Here's a version where the text is more or less readable, but JPEG compressed enough that Phabricator accepts it:
Sep 14 2018
I guess this may be the same issue as in T203555.
Sep 13 2018
Sep 10 2018
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>.
Sep 5 2018
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 .
Sep 4 2018
Sep 3 2018
Aug 29 2018
@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.
Aug 28 2018
@matmarex , do you want to go forward with the solution you suggested? (I.e. use for every other space, on NWE only)
Aug 26 2018
Hmm, looking at the Filibuster trace, it looks very much like the native backspace action leaves the DOM unchanged. Will investigate further.
Aug 24 2018
@Esanders , should we work round this by having a minimum gap above the CE surface?
Aug 23 2018
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
Aug 20 2018
It's still possible to trigger this bug, though Change 247800 made things much better. Will update the description.
Aug 19 2018
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.
Aug 13 2018
I agree with @matmarex 's proposal that we shouldn't revert to the 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.
Aug 9 2018
Aug 8 2018
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:
Jul 27 2018
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.
Jul 12 2018
Thanks, that solves it for me - is there any way that can be the default (at least for Unified)?
Jul 10 2018
Jun 25 2018
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.
Jun 14 2018
@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.
May 20 2018
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.