Page MenuHomePhabricator

Cannot access user contributions when following red link to user page on mobile
Closed, ResolvedPublic3 Estimated Story Points

Description

This is a follow-up to T197581, which introduced an inconsistency: While it is now possible to reach a user's list of contributions from a mobile diff, it is not possible to do so when clicking on a red link to a user page on a e.g. a talk page, except when one opens the link in a new tab.

To replicate:

  1. visit https://en.m.wikipedia.beta.wmflabs.org/wiki/User_talk:Jdlrobson (or find any other talk page post by a user without a userpage)
  2. Make sure there's a red link in that page to User:‎MMiller Test 01
  3. Click on the red link to the user page of the user MMiller Test 01 (or any other link to a user page which has not yet been created)
  4. Observe that there is an overlay displayed:
    grafik.png (250×594 px, 12 KB)
  5. Clicking on create page leads to the mobile wikitext editor. There, clicking on the cross in the upper left-hand corner to close the editor immediately returns back to the village pump. (Clicking on no thanks just closes the overlay.)
  6. Now, instead of clicking on the red link, open the link in a new tab (on smartphones usually possible via a "long click"). Again, the editor opens, but thanks to the changes made in T197581, one stays on the user page and can continue to e.g. the user's contributions.

The expected behavior would be to stay on the user page in the first scenario as well. In general, one rarely wants to create a userpage for another user anyway (this is usually against community etiquette), but quite often would like to check their contributions, e.g. to find out what exactly the problem is they ask about or how long an editor has been active. Therefore it might be worth considering to not ever open an editor when someone follows a link to a user page.

Recommended design

We should aim to have the same behavior as we do when navigating to a user-redlink from a diff, i.e. after tapping the redlink the person lands on the read-version of the nonexistent userpage:

diffempty user page
en.m.wikipedia.org_wiki_Special_MobileDiff_886652910(iPhone 6_7_8).png (1×750 px, 164 KB)
en.m.wikipedia.org_w_index.php_title=User_Oooo45643e3&action=view(iPhone 6_7_8).png (1×750 px, 114 KB)
tap on username

QA steps

  • Here it should be possible to reach the user page of the user Filzstift (e.g. to check their past contributions or leave them a talk page message)
  • On this talk page there are multiple red links to user pages (IP or registered). It should be possible to follow these URIs and access their contributions from the icons at the top of the page.

Developer notes

I (@Jdlrobson) chatted with @alexhollender today (Sep 17 2018) and we plan to resolve this as follows:

When clicking a red link and before showing the Red link drawer, we will scan the uri and determine whether it is to a user page.

If the redlink is to a user page we should not show the drawer, we will drop action=edit from the URI so the user can navigate to their user page.

We also discussed how this behaviour is also "broken" on desktop (although in desktop with the editor open you can still use tab navigation), so there is argument to be had that this should be reviewed site wide on desktop.

Signoff criteria

  • Set up a task for follow up on plan for other namespaces

QA Results

StatusDetails
❌ Deferred to T220114T201339#5080279

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

Change 494369 had a related patch set uploaded (by Niedzielski; owner: Stephen Niedzielski):
[mediawiki/core@master] [Uri] WIP: Update: add getTitle() and isInternal()

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

Change 494370 had a related patch set uploaded (by Niedzielski; owner: Stephen Niedzielski):
[mediawiki/skins/MinervaNeue@master] WIP: Update: don't prompt to create user pages

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

Thank you, @Cirdan, for reporting with nice reproduction steps.

If the redlink is to a user page we should not show the drawer, we will drop action=edit from the URI so the user can navigate to their user page.

To whomever added this note (probably @Jdlrobson), thank you! This was very useful in framing the technical changes needed.

Some additional notes:

  • We won't be implementing this server side as part of this ticket.
    • The reasons for frontend changes only (care of @Jdlrobson):
      • Context is important. If a user is sharing a URL in IRC or elsewhere it's probably meant to contain action=edit.
      • Changes to only the client are easier in the present architecture.
      • There was worry that backend changes may greatly increase server render time.
      • Supporting this server side is estimated to impact very few users.
    • The reasons for server side changes:
      • Minimizes formatting done on the client so that page bandwidth, browser processing, and first paint are optimized.
      • Identical expectations and similar paths on the client and server improve code readability and reasoning.
      • Front and backend renders function identically.
  • The change applies to links to user pages only, not user talk pages.
  • The frontend side requires changes to Core and refactoring some code from Popups there. Patches in progress.

Change 494542 had a related patch set uploaded (by Niedzielski; owner: Stephen Niedzielski):
[mediawiki/extensions/Popups@master] Hygiene: revise getTitle() to use new Uri methods

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

Task description by @Cirdan

The expected behavior [when clicking the link to the user page, going to edit it, and exiting the editor] would be to stay on the user page in the first scenario as well.

I have found this same issue on mobile, and also believe that it should be possible for users to follow a link regularly and have access to the same tools that following such link on desktop offers.

In this case, what we're talking about is that on desktop, when following a link to a user page that has no content yet (i.e. is red), the only bit that's different from if it did have content, is.. the content (and an editor in place to provide/create the content). The sidebar tools are still available. Hence, the fact that desktop automatically puts you in "edit" mode isn't a problem in this context because the tools are still there. And even if they weren't, one could use the tabular navigation to switch to "Read" mode as needed.

What I disagree with, though, is the exact expectation outlined above. This is obviously part of a larger user need that we shouldn't forget.

The abstract user intention in this case is: I can access "Read mode" and/or "The tools offered on read mode", when presented with a link to a page.

This user intention is currently prevented by numerous factors coming together:

  • Internal links default to read mode, but when they don't have content yet, we default them to Edit mode.
  • On mobile, the edit page is usually replaced in JavaScript with a modal experience. For example, following the link https://en.m.wikipedia.org/w/index.php?title=Wikipedia:User_pages&action=edit&section=0 will load an edit page, and then load another editor over top of it. When you close the modal editor, you're still editing, in the layer underneath.
  • On mobile, links to action=edit are also replaced with a model trigger (hence not actually navigating anywhere).
  • The mobile edit dialog does not offer access to Read mode, History, or advanced tools (e.g. what links here).

None of these are specific to User pages, and the problem only arises from the combination of these 4 factors. Change any one of them, and Cirdan's intention would work fine.

All pages have advanced tools and alternate views that may be useful. E.g. "What links here" makes sense for red links. As well as "Page information" (e.g. page watchers). As well as Discussion pages for content-less subjects. Especially in the Category, User, and MediaWiki namespaces it is very common for the subject view to have useful content despite not "existing" yet as a wikitext page.

Any of these view modes should be possible to access through the user interface. I'm worried that hardcoding this for the User namespace might be side-stepping the issue. But perhaps this is for the short-term only to address the immediate use case first?

Thank you, @Krinkle, for your detailed assessment. @ovasileva, @alexhollender, how do you think we should move forward?

I'm worried that hardcoding this for the User namespace might be side-stepping the issue. But perhaps this is for the short-term only to address the immediate use case first?

@Krinkle has left extensive technical feedback on this short-term User-namespace-only approach that would result in one of the following outcomes:

  1. Port code from Popups into new JavaScript API for mw.Title that MinervaNeue can use. This is already done but may be unacceptable since it could be seen as adding to the the technical debt of the MediaWiki API. In the long term, do we remove the new API in favor of 3.?
  2. Copy code from Popups into Minerva. This adds bytes and some more localized technical debt to Minerva. We also have the option to isolate the code as an NPM library that is shared between MobileFrontend and Popups Webpack'd extensions but this may have some overlap with the MediaWiki title library. In the long term, we would remove the code MobileFrontend / Minerva.
  3. Add a data-title attribute to all page links on the backend. This is the approach suggested by @Krinkle in code review, if I understand correctly. I don't yet know what the effort of this approach would but I believe it to be the ideal solution for obtaining titles from links. In the long term, this would only be used by Popups.

If we pursue a long-term approach, such as one listed by @Krinkle or perhaps another yet to be determined, do we need to consult with anyone? Do we implement the short-term and then the long-term?

...

  • We won't be implementing this server side as part of this ticket.
    • The reasons for frontend changes only (care of @Jdlrobson):
      • Context is important. If a user is sharing a URL in IRC or elsewhere it's probably meant to contain action=edit.

(I understand you mean "it's probably meant for the 'edit page' use case, not for the 'access contributions and other user-centered tools' use case".)

Why do we assume that? Users will generally share the URL that the interface offers them, i.e. they won't have the time or even skills to reformat it. E.g. (to take a link from the second example listed under QA, in the desktop version), they would send/use https://de.wikipedia.org/w/index.php?title=Benutzer:217.225.218.165&action=edit&redlink=1 instead of
https://de.wikipedia.org/wiki/Benutzer:217.225.218.165 even for the purposes of the second use case.

We could pull some actual data to check the above assumption (e.g. by looking at action=edit&redlink=1 user page views without referrers, and see how often they lead to action=submits vs. clicks on the linked contributions page). But even so, the probability assessment in the task description, which goes into the opposite direction, sounds more plausible to me ("In general, one rarely wants to create a userpage for another user anyway (this is usually against community etiquette), but quite often would like to check their contributions, e.g. to find out what exactly the problem is they ask about or how long an editor has been active").

From an experience perspective, I think we should aim to have the same behavior as we do when navigating to a red user link from a diff:

diffempty user page
en.m.wikipedia.org_wiki_Special_MobileDiff_886652910(iPhone 6_7_8).png (1×750 px, 164 KB)
en.m.wikipedia.org_w_index.php_title=User_Oooo45643e3&action=view(iPhone 6_7_8).png (1×750 px, 114 KB)
tap on username

I have found this same issue on mobile, and also believe that it should be possible for users to follow a link regularly and have access to the same tools that following such link on desktop offers.

I think this is actually a different problem. The problem here is that the mobile editor overlay loads on action=edit. The OverlayManager/ has no way at current time to know whether clicking back will leave the site or leave the overlay, but could if we checked fragment at the start of a load. This would mean clicking back/close button would provide access to the read version of the site. I see this as a separate and trickier problem. This is described in T201852

The abstract user intention in this case is: I can access "Read mode" and/or "The tools offered on read mode", when presented with a link to a page.

This is T201852

In this case, what we're talking about is that on desktop, when following a link to a user page that has no content yet (i.e. is red), the only bit that's different from if it did have content, is.. the content (and an editor in place to provide/create the content). The sidebar tools are still available. Hence, the fact that desktop automatically puts you in "edit" mode isn't a problem in this context because the tools are still there. And even if they weren't, one could use the tabular navigation to switch to "Read" mode as needed.

From my perspective the bug is in desktop. If i am logged in as User:Jdlrobson and I click a link to a non-existent User:Krinkle page I am currently taken to the editor. This doesn't make sense as user pages should only be edited by their owner. That's the problem here.

Any of these view modes should be possible to access through the user interface. I'm worried that hardcoding this for the User namespace might be side-stepping the issue. But perhaps this is for the short-term only to address the immediate use case first?

Yes this is a short term solution. Longer term I'd love us to update the parser to handle user page links specially. A red link to User:Krinkle should take me to the user page not the ?action=edit. Would you agree with that statement?

I have found this same issue on mobile, and also believe that it should be possible for users to follow a link regularly and have access to the same tools that following such link on desktop offers.

I think this is actually a different problem. [..] described in T201852

I'm not familiar enough with the internals to know if this is that task is what I think it is. I don't know whether it always makes sense to have closing the editor go to the read mode. I suppose it depends where you came from. E.g. if I came from the history page of the same article, and edit is modal, I'd expect closing it to return to where I was. Not a huge deal either way, but that'd be my intuition/expectation.

The tricky bit is when the editor modal for a page is launched from another page, such as the case in the bug described here. I'm reading page X, and there's a red link to Foo (whether it's a User page is imho besides the point). Here, mobile currently allows the user to skip the intermediary step of visiting the page first and choosing to edit it.

Hence it creates a situation where I'm not sure there's a "right thing" to do. We've conflated the user intent of opening a page with editing a page. If we make closing always go to read mode, that'd probably be unexpected for the majority of users. page X -> redlink Y to edit -> close means go back where I was. I was never on Y, so we shouldn't return there, right?

On the other hand, because the edit modal has no page action controls, there's also not a way for the user to self-correct away from the encouragement to create the page.

A red link to User:Krinkle should take me to the user page not the ?action=edit. Would you agree with that statement?

Yes. There are a number of cases where our encouragement to create a page is unexpected and not useful. It should still be possible for advanced users, but not encouraged by default. I would say this applies to all cases of red links to user pages, not just someone else's. It probably should also apply to category pages, mediawiki pages, and file pages. The reason being that all of these can have view information that isn't editable. I'd bet 9 out of 10 times a user goes to such a page, they're not interested in creating it. And showing the editor first there is actively making it difficult (on desktop) or impossible (on mobile) to access that information.

Solving that would be great, and significantly reduces the surface area of this bug. But, it does not solve it. A user should still be able to get to the subject mode, page info, logs, discussion page, etc. of any redlinked page that does open a modal editor, especially in the main namespace where we'd presumably still default to edit mode.

I don't have any preference for how to address that, but it could manifest as an option to "not edit" from the redlink pre-modal, or an option to "read" from the editor.

I'm not particularly familiar with red links and how we handle them. Although I wonder if it's as simple as: whenever following a red link, unless it's stated in the interface that "You can create page X" (as it is in the screenshot below), that you land on the empty-state version of the page. I imagine there are reasons why sometimes on desktop you'd want to land directly in the editor, but to mitigate possible confusion it seems like the additional step (of landing on the empty state, then having to navigate to the editor) would be worth it no mater what. I at least feel confident enough saying this is true for mobile.

image.png (907×1 px, 331 KB)

FYI @iamjessklein @ppelberg, since this is an interesting intersection between reading & editing

@Krinkle - I also think it's a good idea to start the conversation around overall behavior. However, the motivation as written in the task description that users are more likely to access contributions rather than create a page for a user different than themselves feels correct, although we can confirm as @Tbayer suggested).

My suggestion would be to move forward with this task as written as the fix for the current issue and perhaps open a separate task around the default behavior for all pages? As a start, we can also look at the pages that might need a similar treatment (like the category and mediawiki namespaces mentioned above) and then continue by namespace. @alexhollender - perhaps it might be a good idea to do some research around user expectations as well?

@ovasileva to clarify, is the question we'd like to answer (potentially with research):

  • should redlinks lead to the creation/edit mode, or a read mode?
    • should the default behavior differ based on certain factors (e.g. namespace), or can we be entirely consistent?
In T201339#5018854, @alexhollender wrote:

@ovasileva to clarify, is the question we'd like to answer (potentially with research):

  • should redlinks lead to the creation/edit mode, or a read mode?
    • should the default behavior differ based on certain factors (e.g. namespace), or can we be entirely consistent?

Exactly. I would also add "Should this behavior be consistent across platforms?"

Ok. Per @ovasileva's suggestion I've added a design recommendation to this task (which I believe everyone in this discussion is already in support of), and created T218208 to investigate the larger question.

WRT the immediate JavaScript changes in Core, "read only link" detection is requested by @matmarex and @Esanders. It's URI manipulation logic but Uri is fairly destination agnostic and "isReadLink()" would be very MediaWiki-specific. I could add a Title.uri property instead and expose a getUri() method next to the existing getFragment() method but... It would be a little weird to make a Title from a URL and then ask the title if its uri property was a wiki read link and there would be unfortunate overlap with the existing Title.fragment property. Per @Esanders and @matmarex, I will try to add a function to mw.util or a "mustBeReadLink" / readonly proprerty to Title.newFromUri's options. For the former, the usage would look like:

var uri, isReadLink, title

try { uri = new mw.Uri( USER_INPUT ) } catch {}
isReadLink = uri && mw.util.isReadLink( uri )
title = isReadLink ? mw.Title.newFromUri(uri) : null

if (title) console.log(`this is a wiki link to ${title}`)
else console.log('no title, no service')

And the latter:

var title = mw.Title.newFromUri(USER_INPUT, {validateReadOnly: true})

if (title) console.log(`this is a wiki link to ${title}`)
else console.log('no title, no service')

The implementation of "isReadOnly" will probably only return true for empty query parameters (e.g., /wiki/Foo) or only a title parameter (e.g., /w/index.php?title=Foo) and false for everything else. All this will be used by Popups and VE. Minerva will only need Title.newFromUri() but not the read-only validation.

For @Krinkle's data-title patch feedback, I will open a new ticket to evaluate adding a data-title attribute to anchors in Parsoid output which would be the preferred long term solution for at least Popups and Minerva. Via @Esanders, there is already a title attribute (e.g., <a rel="mw:WikiLink" href="./Main_page" title="Main page" class="new">Main page</a>) but this is probably only for presentation purposes, not modeling.

Thanks to @Krinkle, @Esanders, and @matmarex for the continued feedback.

I will try to add a function to mw.util or a "mustBeReadLink" / readonly proprerty to Title.newFromUri's options. For the former, the usage would look like:

I've made an attempt at this. Please let me know your thoughts!

I will open a new ticket to evaluate adding a data-title attribute to anchors in Parsoid output which would be the preferred long term solution for at least Popups and Minerva. Via @Esanders, there is already a title attribute (e.g., <a rel="mw:WikiLink" href="./Main_page" title="Main page" class="new">Main page</a>) but this is probably only for presentation purposes, not modeling.

I'll follow up on this tomorrow and will leave this task assigned to me until I do.

I'll follow up on this tomorrow and will leave this task assigned to me until I do.

Done in T218358.

Change 494369 abandoned by Niedzielski:
Update: add Title.newFromUri() and Uri.isInternal()

Reason:
It sounds like there are still some legit concerns about moving this code to Core. I've copy and pasted it into Minerva for now. We can pick up this conversation again later as needed. Thanks everyone for the reviews and careful consideration!

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

Change 494542 abandoned by Niedzielski:
Hygiene: replace getTitle() with Title.newFromUri()

Reason:
Core dependency is abandoned.

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

I've copy and pasted the code from Core into Minerva for the time being. Ready for review.

Change 494370 had a related patch set uploaded (by Niedzielski; owner: Stephen Niedzielski):
[mediawiki/skins/MinervaNeue@master] Update: don't prompt to create User pages

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

Change 494370 merged by jenkins-bot:
[mediawiki/skins/MinervaNeue@master] Update: don't prompt to create User pages

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

Test Result

Status: ❓ *OS: macOS Mojave
Browser:** Chrome DevTools Device Emulator (iPhone X)

QA steps

  • Here it should be possible to reach the user page of the user Filzstift (e.g. to check their past contributions or leave them a talk page message)

T201339.png (2×1 px, 799 KB)

T201339-2.png (2×1 px, 1 MB)

T201339-3.png (2×1 px, 336 KB)

T201339-4.png (2×1 px, 238 KB)

  • On this talk page there are multiple red links to user pages (IP or registered). It should be possible to follow these URIs and access their contributions from the icons at the top of the page.

T201339-5.png (2×1 px, 390 KB)

T201339-6.png (2×1 px, 223 KB)

T201339-7.png (2×1 px, 201 KB)

T201339-8.png (2×1 px, 97 KB)

Only Red Links with a User Name worked with this. I tried all IP address links and they yielded pages similar to this

T201339-9.png (2×1 px, 315 KB)

Edtadros added a subscriber: Edtadros.

@Jdlrobson the QA steps state that both IP or Registered user links should allow you to access their contributions using links at the top of the page. I was only able to get the links for the registered user.

@Jdlrobson the QA steps state that both IP or Registered user links should allow you to access their contributions using links at the top of the page. I was only able to get the links for the registered user.

This is on production now, so you can QA this using https://de.m.wikipedia.org/wiki/Diskussion:Klingelton
The beta cluster doesn't allow IP users for spam protection so it's going to be too difficult to setup testing there.

Test Result

Status: ❌ FAIL

*OS: macOS Mojave
Browser:** Chrome DevTools Device Emulator (iPhone X)

QA steps

✅ - Go to https://de.m.wikipedia.org/wiki/Diskussion:Klingelton, find a red user name link and click it.

T201339-b1.png (2×1 px, 369 KB)

T201339-b2.png (2×1 px, 223 KB)

T201339-b3.png (2×1 px, 203 KB)

T201339-b4.png (2×1 px, 97 KB)

❌ - There are multiple red links to user pages (IP or registered). It should be possible to follow these URIs and access their contributions from the icons at the top of the page.

In the previous step, I clicked on a user name and it worked fine, so I tried to find an IP address that would allow me to view contributions and talk from icons at the top of the page. Every red IP address took me to this page (but with different IPs:

T201339-b5.png (2×1 px, 349 KB)

There are no icons at the top that allow me to talk or view contributions. I tried this logged in and out with the same result.

❌ There are multiple red links to user pages (IP or registered). It should be possible to follow these URIs and access their contributions from the icons at the top of the page.

Over to you @alexhollender - I hadn't realised this but when following a link to the user page of an IP you are taken to a page that does not behave like mobile user page e.g. https://en.m.wikipedia.org/wiki/User:80.251.236.46 - they do not have a contributions link (https://en.m.wikipedia.org/wiki/Special:Contributions/80.251.236.46) for example. Is this intentional? We should create a new bug if not.

✅ - Go to https://de.m.wikipedia.org/wiki/Diskussion:Klingelton, find a red user name link and click it.

That's probably enough to call this particular task done IMO.

looks good to me

can you expand on what this means? Do you mean "looks good to me" let's not worry about this at all OR "looks good to me" let's create a patch to take care of this but it's out of scope for this particular task?

@Jdlrobson sorry for the lack of clarity. The non-IP redlink userpage experience looks good to me. Regarding the IP redlink userpage experience, here is a separate task for that: T220114.

Secondly, apologies for this slipping through the cracks, but for both of these pages would it be preferable to show the toolbar? We discussed a similar case in T211775 recently. If so, happy to create a separate task for this, as the current patch is a step in the right direction either way.

redlink userpageredlink IP userpage
without toolbar
en.m.wikipedia.org_w_index.php_title=User_11-17geek(iPhone 6_7_8) (3).png (1×750 px, 112 KB)
en.m.wikipedia.org_w_index.php_title=User_11-17geek(iPhone 6_7_8).png (1×750 px, 115 KB)
with toolbar
en.m.wikipedia.org_w_index.php_title=User_11-17geek(iPhone 6_7_8) (2).png (1×750 px, 106 KB)
en.m.wikipedia.org_w_index.php_title=User_11-17geek(iPhone 6_7_8) (1).png (1×750 px, 112 KB)

Okay let's discuss all these changes in T220114. I think it's easiest to think of them together. @Edtadros looks like the failing step will be dealt with in T220114. For QA results should we update to say "deferred" for that step and mark which ones passed?

@Edtadros, per T201339#5085646, I've updated the task's QA to defer to T220114 and will move this to sign off.

ovasileva claimed this task.

First portion of QA looks good, so resolving this. Also marking as a subtask of T220114: Updates to user page treatment (apply for IP address and always show toolbar) so things are a bit clearer.