Amended the selector to be limited to the first row. This will remove the icon from the H1/H2 second row headers in the first example, causing a width change, but fixes the row-headers case which is probably more common.

I think a solution that results in FOUC in <10% of cases is better than one that results in a FOUC in 100% of cases.

In T218414#5048560, @alexhollender wrote:

Related to this topic: it seems like we'd benefit (both on iOS and Android) from moving the "Publish" button in the Talk > Reply UI to the header. For Android users this would mean the button is always visible, and for both iOS and Android it would be a more consistent experience with other Publish/Save actions.

What is the next step to provisionally schedule this deploy for that date? CC @DLynch, @Jdforrester-WMF

For future reference it should be noted that userId's are not persistent across wikis for the same user, so if we have a more complex bucket function we should use username to ensure users end up in the same bucket across wikis.

1. Section Editing should not be deployed to the Wikis listed above until the vanishing-toolbars-while-scrolling (T218414) patch is live on the wikis listed above

Side note: we've historically used a gif for that loading spinner, but we could just as easily do it in CSS: https://loading.io/css/

Minor nitpicks for when we implement:

• The text looks like it might be bold, it probably shouldn't be
• The spacing between the spinner are the text should be reduced. If the spinner has the same spacing either side as the close icon, it looks like there are three separate componenets: close, spinner, message, whereas I think it should look more like: close, spinner+message
• We can probably probably have a text ellipsis after the message, i.e. "❋ Loading editor..."

Bisect blames https://gerrit.wikimedia.org/r/#/c/oojs/ui/+/444924/ from 8 months ago (@Volker_E)

Nice!

The above patch introduces a new 'mobile-ab' config setting that turns on mobile section editing for odd-numbered users. We can use that setting on the next set of wikis we deploy to.

Given the time constraints I'll skip the nice-to-haves, and we can just bucket users by odd/even userIDs.

Moving out of VE's QA column as QA will be done by the CX team.

After the above patch here is the change in appearance for a simple sortable table, and @matmarex 's minimal failing test case from the previous attempt:

before	after

There's also not a great place to do saveSuccess client-side, since it'd be on the redirect to a regular article page...

If we are to do the timing the same way VE does it, then init should fire when the edit tab is clicked, and ready/loaded should fire on the edit page after init.

Adding headings is something we will be considering as part of our toolbar/context work.

In T18691#5005790, @dbarratt wrote:

In T18691#5005766, @Esanders wrote:

For shorter articles that don't have any/many h3's that might be fine, but for feature-article length pages it would be not very useful.

Maybe making this configurable per-wiki is a potential solution?

While the stats on heading levels usage are interesting, I'm not sure they will help with the dilemma: If a heading is commonly used that makes the case for both adding the sharing links and that adding those links will clutter the interface. Conversely for less-used headings it is safer to drop the sharing links, but also won't help will reducing clutter.

I think in the second case we'll fail to recover the edits currently.

It sounds like this may have only happened because this was loaded as a webview from withing GChat. Is there a general problem with data being lost when iOS resume from sleep?

Mobile browsers unloading the page (T217783)

The main issue with localStorage is not just that we would need to manage old entries, but that we could also run into limits more often (which would probably result in data loss)

• Even with aggressive garbage collection some users may have multiple documents in storage at any one time
• ResourceLoader uses up a lot of the storage for its cache
• On Firefox quota is shared across the whole domain, not subdomains, making it more likely to hit quota. RL caching was disabled on FF for this reason.

I also think we need to clarify that we really have no strict definition for the difference between a unit test and an integration test. If I test the construction of a complex object, like a VisualEditor data-model document, is that a unit test because it is one method, or an integration test because it triggers thousands of method calls in hundreds of classes?

In T212521#5014406, @Tgr wrote:

Selenium tests are slow, fragile, hard to maintain and hard to understand. Using it for integration tests would just make testing harder.

This is an visualisation of the performance improvements over the past few months (loading html/metadata early, speeding up metadata, client side section editing), based on my initial measurements from November:

Given that the metadata request is still block in some cases (especially on shorter articles, or when loading the page a second time) we should go ahead and try and merge the metadata promise separation patch.

On proposal "B" you have "might compete with browser loader".

I'm not a big fan of the loading dots being used inline. They have only been used once before which is in CX (see T75972) where they are centred on the screen with more padding and at a larger size.

Let's file the flicker issue as new task, I think it is relative minor given this is already an edge case. I'm sure we could find a way around this, but it may be diminishing returns on the effort required.

We should also add cursor:text to indicator the text is selectable, however this also requires user-select to be re-enabled too. @matmarex In your comment you talk about section-0 edit links as content tested in <h1>, where do those appear? Could we add a selector like h1 > a to re-disable those?

We recently made the heading selectable again. This means it wouldn't make sense to keep the tools available when you click on the heading.

and in these cases users indeed changed the mode twice or even more often to compare.

Here is a 7-day rolling overage of 5th centile load times:

Re-running the featured-article tests from T206228, metadata and page html now take about roughly the same time. The issue is now less severe, but there are probably more benefits to be had by not blocking on metadata at all.

VE does this here: https://github.com/wikimedia/mediawiki-extensions-VisualEditor/blob/8846e65e4475fb1942e2d30478d072b5261cd4a7/modules/ve-mw/ve.MWutils.js#L163

My understanding is that if the link is marked with mw:wikilink you can just infer the title from the relative path. Is there a case where this wouldn't work?