So it seems the second issue of up arrow skipping the cells in between and moving to the caption field or to the preceding content is almost fixed. I see a flickering cursor in those positions still but that's negligible I suppose or not :) I am marking this issue verified from my side anyways.

@matmarex: I don't think it's a major issue but I still feel slightly odd about this design having a textfield with focus highlight and a disabled action button right next to it. I did like @DLynch's third suggestion which makes the button look like part of a same unit at-least.

Verified on Beta cluster.

@Jdlrobson: I see, yeah that makes sense. There was indeed no search results when I typed the first two characters fast, and therefore I got only 1 api request for watchstar and 1 for results, even though I typed three characters.

@matmarex: Ah! This is about OWE. Thanks for clarifying that :)

@Jdlrobson: Was checking this on Beta cluster. Couple of questions:

I can't reproduce this anywhere Beta cluster/production following the steps mentioned. So not sure how can I verify the fix in this case.

@ovasileva: Sure, check these two articles for instance: https://en.m.wikipedia.beta.wmflabs.org/wiki/Bear or https://en.m.wikipedia.beta.wmflabs.org/wiki/Bearded_seal

In T200525#4486910, @DLynch wrote:

Question 1 is what I was asking above in my first comment on this task, so I'd say that's somewhat-undecided. I think 2 is unintended, though; it should switch to cell selection first.

In T200525#4467439, @DLynch wrote:

@Deskana: "active node" means one which can have cursor focus within it, in a way that's somewhat separate from the general article flow. This patch makes it so that moving your cursor with the arrow keys doesn't keep it trapped within those nodes. E.g. if you're in a table caption and press the up arrow, you would previously have stayed in the caption, but now you'll find the cursor in the preceding content.

In T199925#4486719, @Esanders wrote:

Yes, "sequences" are only triggered if you actually type them (or at least the last character). I consider them in the same class a keyboard shortcuts, so for me that makes sense.

In T199925#4470198, @matmarex wrote:

Current version of the patches only implements inserting horizontal rules by typing ----. I think that's an uncontroversial improvement, and it is easy to support in the future (comparable to the {| sequence to insert a table that we already have), so I'm going to merge them.

Followed the steps mentioned in T199011 to verify this, not getting this error anymore.

Checked and verified that no more slugs appearing in the space for caption and the highlight is covering the entire gallery. Same for non gallery images.

@ABorbaWMF: Just wanted to mention that this seems to be not working on Beta cluster yet, some of the articles on Beta still has infobox as the first thing instead of the lead paragraph. So, I don't know if the fix has landed on Beta yet, but I was going to mark it as "Done" after verifying it on all other environments. Do you move tasks to Done column as soon as it's working on staging or when it is verified on all environments? Also, if/when you do verify tasks in other environments, how do you usually keep track of which environments it's been tested on?

@Jdlrobson: Tested the fix on the articles mentioned under QA steps in staging environment. As for checking it on some random articles, on staging I am finding it difficult to find one with lead paragraph/infobox in it. Is it on Beta cluster yet? I could then search for some more random articles and check on those.

Verified on these articles: http://reading-web-staging.wmflabs.org/wiki/Copenhagen and http://reading-web-staging.wmflabs.org/wiki/Albert_Einstein. Good to go.

@matmarex: No worries! :) Just tested this. Seems fixed for all cases. Thanks!

This issue also got fixed with T196521.

@matmarex: It's alright :)
I am still getting the error on this page though: https://en.wikipedia.beta.wmflabs.org/w/index.php?title=User:RYasmeen_(WMF)/sandbox&oldid=382759

@ovasileva: Tested it on a iPhone5s following the steps mentioned. Seems to be working fine for me, that section link does redirect to the correct section of the article.

@matmarex: is this ready for testing on Beta cluster?

Yup, got fixed it seems.

I tried to reproduce this in other environments but couldn't. However, this is happening consistently on my sandbox here: https://en.wikipedia.beta.wmflabs.org/wiki/User:RYasmeen_(WMF)?veaction=edit

Checked it on this page: https://readers-web-master.wmflabs.org/wiki/Syracuse,_Sicily. Looks good to me.

Okay, this time I finally got bucketed to get "page issues" link rendered under the heading. So marking it as verified.

@matmarex: Can you try it on this page: https://en.wikipedia.beta.wmflabs.org/w/index.php?title=User:RYasmeen_(WMF)/sandbox&redirect=no&veaction=edit

@matmarex: Actually I can't even add any text there even if I click on them directly. There is just no cursor to insert anything.
See this screenshot without the blue highlight preventing it.

In T186760#4441358, @Niedzielski wrote:

@Ryasmeen, sorry for the confusion. There are two tests:

1. Login and visit https://en.wikipedia.beta.wmflabs.org/wiki/Special:Preferences#mw-prefsection-rendering (desktop)
2. Ensure the "optimize and simplify special pages when on mobile (recommended)" option isn't present.
3. Visit https://en.m.wikipedia.beta.wmflabs.org/wiki/Special:EditWatchlist (mobile)
4. Ensure the watchlist is the modern mobile friendly version shown on prod.
   
   And:
5. Visit https://readers-web-master.wmflabs.org/w/index.php?title=Special:UserLogin&returnto=Main+Page (note the HTTPS).
6. Create an account and login.
7. Disable "optimize and simplify special pages when on mobile (recommended)" from https://readers-web-master.wmflabs.org/wiki/Special:Preferences#mw-prefsection-rendering (desktop).
8. Visit https://readers-web-master.wmflabs.org/w/index.php?title=Special:EditWatchlist&mobileaction=toggle_view_mobile (mobile).
9. Ensure the watchlist is ugly!

@Jdlrobson: So I see now http://reading-web-staging.wmflabs.org/wiki/Talk:Sandwich has "About this Page" link and it takes me to issues page and there is no empty rows on that issues page.

@Jdlrobson: I don't see this Mobile Preferences option in the user preferences - appearance section on reading-web-staging or on beta cluster, where should I test it?

Checked all the acceptance criteria except the last one, and they are passing.

In T185944#4417645, @matmarex wrote:

@Ryasmeen The OOUI refactoring has also revealed a few other minor issues in VisualEditor, which are now visible on https://en.wikipedia.beta.wmflabs.org/:

• Page options → Templates used (and other options, except the first one) opens the first panel first, then visibly flashes to the right panel
• Insert → Template opens as empty dialog first, then the form flashes in
• Welcome dialog first opens with three buttons, then some of them disappear (depending on whether page is visually-editable)
  
  Quick recording for reference: https://drive.google.com/file/d/1mJhmKQOe8eEblFmQhnsNqB57tsEOdAyJ/view?usp=sharing (too large for Phabricator)
  
  All of these are fixed by my patches above (pending review).
  
  ----
  
  Similar issues might appear in other code using OOUI dialogs. I think it's unnecessary to try to check them all (it's a lot of code, and the issues, if any, are just minor visual glitches like these).
  
  However, if QA or anyone else spots a problem like this (contents or buttons of a dialog somehow rearranging themselves immediately after it opens), please know that this is the root cause, and the issue is fixed by moving initialization code from #getReadyProcess to #getSetupProcess. #getReadyProcess should basically only contain code that focusses/activates something in the dialog. I'm not sure if we should try to announce this somewhere.

Happens on the media search panel too, while inserting an image.

I see a different error now though while doing the same and in fact now it does not even switch to the option "Don't use machine translation" anymore.

@Deskana: Just checked this on production, and from my own first time user experience, I initially thought that the "Change label" button was not working because the context menu stayed open without any visual change. It feels that the text selection being enabled in the document is so subtle to notice, compared to an open dialog.

Verified this issue on production. Looks good to me. However, found another issue with page previews while testing this, filed as T199508.