In mobile VE, we render a fake selection for these nodes rather than a "native" selection, because a native selection causes the touch keyboard to pop up on mobile devices. The lack of native selection means that keyboard shortcuts that operate on text selection won't work (and this is a low priority issue for actual mobile devices, because they are not often used with a hardware keyboard, and the touch keyboard doesn't have these keys/shortcuts).
What do you mean by "test wiki"? It is not yet live on https://test.wikipedia.org/, it will go out with the train next week. It is live on Beta (e.g. https://en.wikipedia.beta.wmflabs.org/wiki/User:RYasmeen_(WMF)/sandbox?useskin=minerva) and this functionality works as expected there for me (other than the "read-only mode" and not being able to save changes, which is apparently an unrelated ongoing issue).
Wed, Feb 20
I see what you mean, but I don't think that's a problem. I've always seen ordered lists displayed (and printed) in this way (with the digits of the same magnitude aligned).
I think we still want to switch to outside list style for ordered lists (for scannability, for consistency with unordered lists, and to avoid the rendering bug inside styling causes in VE as seen on T208102).
This will be fixed on Turkish Wikipedia next week, with the deployment of MW 1.33.0-wmf.19.
Thank you for fixing this!
This only occurs for this single demo example, and nowhere else. It seems to be caused by the unicode-bidi: bidi-override; rule added in https://gerrit.wikimedia.org/r/c/oojs/ui/+/482703/5/demos/styles/demo.css#422 (it disappears when I remove it). That rule should only apply to elements with a label, but it also applies to these label-less buttons. I don't think we need the workaround in OOUI library code, only in demo code.
Tue, Feb 19
Lukewarm responses to my patch convince me that we all feel like the solutions are worse than the problem. I am not planning to work on this further. Please read my earlier comments for the drawbacks of each possible solution.
I have no opinion, but if you make this change, you should also add similar aliases for any other analogical options/attributes – for example, tabIndex in TabIndexedElement and noFollow in ButtonWidget.
No, it’s easy to use the indeterminate progress bar.
Mon, Feb 18
The browser console output looks like a problem with some browser extension, or with the console (developer tools) itself, rather than VisualEditor.
I think it's a valid issue? The problem is slightly different than you described it originally, but there is a real problem here, as I hope I explained in the comments above.
Looks like my fixes for this task have been very precisely unfixed, and the mobile editor loads on desktop again, bringing back the problems. I'm not sure which particular patch caused it, maybe rEMFR2309260e78b0: mobile.editor module merged into mobile.init? I will try to fix it again and hope it sticks.
This does not happen for me using iPhone SE, which should be the same screen size. (In this recording, I zoom in with pinch-zoom.)
On en.wiki, it did not prompt for any CAPTCHA when I added an external link for the first time in a session but after that for subsequent sessions it did.
(Eh, I guess we should go through the motions if I've put it on our workboard; for anyone else watching it, please consider it resolved)
Also, if you're sorting alphabetically, you have to sort according to the rules of the given language. For example, in Czech (cs), the namespace "Šablona" (Template) should be ordered after "Soubor" (File) and before "Uživatel" (User). The currently proposed patch will put it at the end of the list. In PHP you can use the Collator class for this (but you'll have to have a fallback in case the 'intl' extension is not available, since we don't actually require it right now).
I think one argument for keeping the current order (by namespace id) is that it is consistent across all languages. As someone who is occasionally asked to debug weird issues in various languages, I find it very convenient to navigate the interface without being able to speak the language it's written in. (Note that the namespace names are in the wiki content language even if you switch your interface language.) This is very much a minority use case though (probably only relevant to developers and stewards).
I thought that this can't possibly be the first time this is proposed, searched, and found the two duplicates. :) There was some discussion there (and also semi-relevant discussion on T176992, about the dropdown on Special:RecentChanges only).
I wanted to compare the performance using the production data as part of QA:
Fri, Feb 15
VisualEditor and MobileFrontend both use the action=edit API for saving changes.
With that patch, the issue is fixed for refs' context menus, but it is not fixed for reflists' CE renderings. We might need a similar patch in the Cite extension?
I logged-out and the issue was not happening. When I logged-in again the issues was not happening. So there is some intermittent behaviour with this that makes it hard to reproduce, but the issue still happens in some cases.
Thu, Feb 14
This occurs because when iOS scrolls the cursor into view after opening the keyboard, it scrolls the browser viewport (and we otherwise go to great lenghts to avoid it from being scrolled, because on iOS we maintain our own viewport to work around lack of support for fixed elements). We work around this issue in mobile VE, but the mobile wikitext editor has no workaround for it.
(Krinkle talked to me yesterday after seeing the loading progress investigation. Apparently there exists a Navigator.connection API that can be used to get some data about the user's connection speed, which we could use to estimate load time. However, it seems sparsely supported by browsers.)
This is definitely not caused by https://gerrit.wikimedia.org/r/c/mediawiki/core/+/314725. That patch actually fixed a similar issue to this, but with characters from other alphabets (T147646). It does nothing about Georgian scripts though.
Wed, Feb 13
I spent a few hours finding out. The conclusion: it could be done, but it would take a lot of work, we would need support from folks in Performance and SRE, and from whoever owns RESTBase these days, and the end result would probably still feel worse to users than the current fake progress bar.
Oh, thanks for finding that! I was just guessing based on when both tasks were reported.
People are using GIFs instead, because no one wants to spend 15 minutes every time re-encoding an OGV until you get one that is <4 MB and not utterly messed up by the encoder, and it makes me sad :( T210630#4949865 T215361