I was unaware of this functionality, although I think in practice this is never done because it is really confusing (and a horrible feature). If multiple ref lists are used on a page, they are each given their own unique group.

In VE it would look like this:

An inline counter is used in old wikitext editor:

I don' think this is for showing "progress" but rather for "warning" the user when they are about to run out of space, as we aren't encouraging very long edit summaries.

"Enter a full URL, e.g. https://example.org"

Filed T228159 as follow up.

We just fixed the regression, so it looks like it did before:

I can't reproduce this. I see the edit card after adding an external link on Android Chrome and iOS Safari.

We didn't really design for this case, but I would guess showing the * Editor loading spinner would suffice.

It also looks like it might be related to some of @matmarex's iOS scrolling hacks?

This is correct behaviour as the bottom padding area is added to avoid having any links that would conflict with the bottom menu bar (clicking in that area just brings the menu bar up).

I could reproduce this on my iOS 9 device, but not my newer one. What version are you testing on?

Is it impossible to add a section editing button to the lede (option c) while also incorporating an Edit All button that only loads on click in the toolbar?

So config.example.yaml should be updated?

In T215717#5330166, @Esanders wrote:

Testing second load times (i.e with the code and page data already fetched and cached), time to loaded was ~2300ms without the patch, and ~1300ms with.

Add "globe" icon to external link search

As implemented:

Is it impossible to add a section editing button to the lede (option c) while also incorporating an Edit All button that only loads on click in the toolbar?

Thanks for the analysis, sounds pretty successful overall.

In T206228#5330185, @Esanders wrote:

Here's how it will look after T215717 is fixed:

Here's the same graph without the intermediate step

Here's how it will look after T215717 is fixed:

See also T206228

Monkey patched on live and edited a section of a long article (mobile site on desktop) (https://en.m.wikipedia.org/wiki/Megan_Rapinoe)

So here are the problems if we don't do this:

• Our A/B test becomes less meaningful as we are comparing different experiences when the user presses the first edit button (which is probably a large percentage of users, if not a majority)
• VE is given an unfair disadvantage in this A/B test as the full page takes so many times longer to load.

I've just discovered this bug which is probably having a fairly big impact on performance: T227897. Basically the first edit pencil opens the editor for the whole page (it shouldn't) which is many times slower than just loading a section.

The drawback of this approach is that when there is nothing to scroll, Safari's menu bar is never minimized, and so we reduce the amount of screen space available for the dialog's contents (see screenshots below).

What are we doing differently in the VE save dialog, because if I view a long diff it scrolls fine?

Clearly much better on mobile :)

Can you update the screenshot with the correct icon ('previous')?

Just as a note, it's totally incorrect to imply that the one-action dialog is not as it was designed.

Does this seem sensible to you @ppelberg ?

An example of the confusion on desktop:
Q: If I press show changes on this selection, will I see the 1 April change, the 3 April change, or both?

In T167047#4393550, @Lea_WMDE wrote:

Hi @Esanders, right now the highlighting represents the versions that are being shown on the diff page. So they are the exact equivalents of the radio buttons you select on the diff page.

Yes the radio buttons on desktop suffer from the same problem.

cc @cmadeo who is thinking about revision comparison on mobile apps.

If the action has a 'back' flag then it doesn't get the correct styling as it assumes the message will be converted to an icon, which it isn't on desktop (yet):

The patch didn't switch all 'back' buttons to use an icon on desktop, which we may want to address is a future release?

The first |- is not required in wikitext, and the examples in the documentation omit it: https://www.mediawiki.org/wiki/Help:Tables#Basics

The tricky part is figuring out how to adapt the styling of existing messages to the mobile interface.

The content can be cleaned up when copying and the converter has separate modes when generating HTML for Parsoid/Clipboard.

I'll try and get around to looking into this this week as I don't know the answer off the top of my head.

Cc @matmarex, we used to do something like this on iOS?

Actually as this is a regression, we should probably take a look.

Replied on gerrit.

The colour is now fixed, but the padding is still incorrect

It looks like the centering code that adds inline padding styles to the title hasn't been disabled (or made desktop-only)

After patch:

Yeah - I think the error was just some debounced calculations happening on an old surface, so I think the try/catch fix is ok.

In T206829#5304178, @alexhollender wrote:

In T206829#5303707, @Esanders wrote:

Looks like the original report is talking about "semi-protected" pages which are only uneditable by logged out users, so I've updated the title.

I wonder if it makes sense to consider both cases (protected & semi-protected) here? See T206829#5202751 in case you didn't already.

As we have deployed the new edit cards to bn/he/fa we can just QA them on those wikis?

As we have deployed the new edit cards to bn/he/fa we can just QA them on those wikis?

Looks like the original report is talking about "semi-protected" pages which are only uneditable by logged out users, so I've updated the title.

This is something I have personally stumbled on quite a few times, as a quickly open/close sections to see if they contain the information I need. It would be interesting to hear if anyone else has encountered this. Potentially we could do a small A/B test to see if expanding sections by default results in fewer editor launches (but the same number of editor completions).

I'm not actually seeing the disambig class in the Parsoid output: https://de.wikipedia.org/api/rest_v1/page/html/0/187176557

We didn't stop users of OOUI to make frameless buttons primary so far, also I could imagine that there's use cases for exactly that as well.

I will provide patches for the identified issues. In this case it's simple side borders/backgrounds around “safe” actions.

In T226168#5296386, @cmadeo wrote:

Due to the fact that there seems to be two very distinct sets of values and backgrounds going into this discussion, I'd suggest that we utilize UserTesting.com to get feedback from a more general group of potential users.

I understand why on pure aesthetics the closed top looks better to a designer, but I would suggest you consult with the intended audience here as their experience may be different from your own. I have spoken to a few friends who studied chemistry all of whom agreed (although admittedly all from the same background as myself).