Change #1064025 had a related patch set uploaded (by Mareike Heuer; author: Mareike Heuer):

[mediawiki/extensions/MobileFrontend@master] Remove subref number prefix from ref preview

https://gerrit.wikimedia.org/r/1064025

I'm not sure if we can easily remove the number (e.g. the [1.1] in the screenshot). Showing the number appears to be the existing convention for all references, no matter if they are a sub-reference or not. The fact that sub-references show only one of the two possible numbers (the parent doesn't show the [1], but the sub-reference shows the [1.1]) was intentional when we made the first proof-of-concept change way back in 2020 (see https://gerrit.wikimedia.org/r/567458).

I see a few possible ways forward:

1. Stick to the convention to show the footnote marker for the reference the user clicked. If they clicked e.g. [1.1] in the text the popup will repeat the [1.1], as it always did, for all references. This helps the user understand better what the popup represents. However, we don't show the [1] in front of the parent reference. This is the current status quo.
2. Show both numbers. This is consistent with how the two references appear in the reference list outside of the mobile experience.
3. Hide both numbers when the user clicks a sub-reference, but continue to show the number when the user clicks a normal reference. This is probably a bad option. The only benefit I can see is that this doesn't break the existing user experience for normal references, while still removing clutter from sub-references.
4. Show no numbers on both normal and sub-references. While I agree this might be a good option it changes an existing product decision made by the mobile team a long, long time ago. Do we really want that, @ElineWMDE?
5. Same as #1 above, but we move the [1.1] up in front of the parent.

To get the patch unstuck I suggest to do #5, and continue discussing this with UX after it is merged. Merging anything but #4 is fine because it won't have any effect on production wikis.

Thanks for thinking it out in so much detail @thiemowmde!

We haven't user validated how the current version is perceived, so it's difficult for me to say something conclusively.

My assumption is that the number was added to the popup, deviating from the desktop experience, because the link between the popup and the footnote number is not as clear. On desktop, the ReferencePreview is in a tooltip that is directly attached to the footnote marker, so showing the number in the ReferencePreview is not necessary in that case. For mobile, the preview shows up at the bottom of the screen, without a clear relation to the footnote marker it is related to. For that reason, I think the footnote marker number should definitely be in it, so it is clear to the user to which footnote marker the preview is related. This is especially important if there's 2 or more footnote markers in a row in the article, which can make it quite easy to accidentally tap the wrong one, and makes it difficult to see which marker was tapped precisely. Following this logic, the subreference number (eg. [1.1]) would be the most (and probably only) important number to show in the preview. My assumption is that adding the main ref number (eg. [1]) to the top of the preview, might even be confusing: it then seems like the most important number in the preview, while it does not have a direct relation to the marker the user just tapped.

Since we decided on desktop to have the ReferencePreview show the full content of the main & subreference, without clear distinction between the main & subref (with the assumption that readers will primarily be looking for the full content of the reference, and not be concerned with which part of it is a main reference that is re-used in other places of the article, and which part is the sub-reference - if they want an overview on that they will look at the reflist in the bottom of the article), it seems like a good idea to me to continue that same logic for the mobile previews.
With that logic I arrive at Thiemo's option 5 as the best option: the number [1.1] is at the front of the reference to signal which footnote marker was tapped, and the user will see the reference content as if it is a whole reference without clear distinction between main & subref.
I would propose implementing option #5, and then we can validate this decision from user feedback and in future user testing rounds.

TLDR: I agree with Thiemo, option 5 sounds best for now - we could revisit after user validation

Change #1064025 abandoned by Mareike Heuer:

[mediawiki/extensions/MobileFrontend@master] Remove subref number prefix from ref preview

Reason:

Decided to move the number prefix infront of parent ref text for subrefs instead of removing it

https://gerrit.wikimedia.org/r/1064025

Change #1064742 had a related patch set uploaded (by Mareike Heuer; author: Mareike Heuer):

[mediawiki/extensions/MobileFrontend@master] Move subref number prefix infront of parent ref text from ref preview

https://gerrit.wikimedia.org/r/1064742

I just discovered an interaction with orphaned subrefs. Please test the behavior, currently I'm seeing the subref duplicated as its own parent.

Change #1065131 had a related patch set uploaded (by Mareike Heuer; author: Mareike Heuer):

[mediawiki/extensions/Cite@master] Adjust indentation of subrefs in reflist for mobile view

https://gerrit.wikimedia.org/r/1065131

Evaluating the indentation patch:

• Looks much better, although we could continue to reduce indentation. Mobile still has ever slightly more margin than desktop, which we could continue to adjust in the next design iteration. It's nearly perfect now. Compare the following, ordered by decreasing margin :rabbit-hole:

Mobile read mode, unpatched:

• Correctly has no effect on the edit-mode interface.
• We could make indentation responsive to screen size (reduced on small screen) in a later iteration.
• Breadcrumb regarding the root cause: default browser styles include padding on all <ol> elements, which is reset to zero by Vector but not by MinervaNeue. Our solution is great for this one use case, but maybe a similar fix should be applied to the skin.

Change #1065131 merged by jenkins-bot:

[mediawiki/extensions/Cite@master] Adjust indentation of subrefs in reflist for mobile view

https://gerrit.wikimedia.org/r/1065131

Change #1064742 merged by jenkins-bot:

[mediawiki/extensions/MobileFrontend@master] Move sub-ref number prefix infront of main ref when previewing

https://gerrit.wikimedia.org/r/1064742

Note that we made an unreviewed decision to handle orphaned subrefs by showing a spinner:

It might be notable to add that we found this spinner in the existing code. It was originally added as part of T125896: Feature flagged lazy loaded references in 2016, obviously meant as a placeholder while the ref's content is lazy-loaded. That lazy-load feature was removed via T222373: Remove the lazy load references beta feature in 2019, but the spinner was left behind. This might have been a mistake.

Unrelated to the original intention we found that the same spinner appears in error situations where the ref's content cannot be found. Here is the most trivial example I can think of that demonstrates the situation both for a normal ref as well as a sub-ref:

<ref name=a />
<ref extends=b>page 2</ref>

In both cases the (main) ref's content cannot be found and the spinner is shown instead.

@ElineWMDE, it might be worth redesigning this and e.g. showing a more actionable error message instead. However, it's probably exceptionally rare to ever run into one of these two situations, and sticking to the existing spinner should be good enough for now. At least better than making the code run into an error or not showing anything.