Jump to content

Wikipedia talk:Mobile communication bugs

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Background discussion

[edit]

Plopping for the record: Wikipedia:Village_pump_(WMF)#What_we've_got_here_is_failure_to_communicate_(some_mobile_editors_you_just_can't_reach). {{u|Sdkb}} talk 23:12, 27 December 2021 (UTC)[reply]

Flip rows and columns

[edit]

Let's flip the rows and columns. It's unlikely that devices will increase much if at all, and we hope that bugs won't, but the reality is that we'll probably find or register more bugs as time goes on, and there's no theoretical limit on the number of them. That argues for having bugs as rows, devices as columns. Before I (or someone else) does this, I wanted to ping User:Suffusion of Yellow for your thoughts, and also ask if anyone knows of a "transpose wikitable" tool. If not, it might be worth writing one. (Such tools exist for html, and if there's a method of converting wikicode to html—maybe an extraction of the page source?—then perhaps we could apply that method.) If a tool isn't available, I might try my hand at a mega-regex, but if it works at all, it probably won't work 100% and would require a fair bit of manual post-processing, and would probably be pretty tailored to this example, and not scale well. The table isn't that huge, that a manual rewrite is ruled out, and perhaps that's about the same level of effort as the other solutions. (please Reply to icon mention me on reply; thanks!) Mathglot (talk) 19:52, 21 April 2021 (UTC)[reply]

@Mathglot: I had to clean up a few stray "undefined"s, but User:Kephir/gadgets/table-editor.js did the trick. Suffusion of Yellow (talk) 20:13, 21 April 2021 (UTC)[reply]
@Suffusion of Yellow:, wow, that was fast! Thanks for linking the tool; will add that to my list of useful gadgets. Mathglot (talk) 20:15, 21 April 2021 (UTC)[reply]

Addressable rows

[edit]

I've added ID's to the rows, so they can be directly targeted with section links. Mathglot (talk) 00:36, 27 September 2021 (UTC)[reply]

—⁠andrybak (talk) 21:31, 26 June 2024 (UTC)[reply]

Global consensus for standard admin protocol

[edit]

Today we've had the umpteenth ANI report about this sort of situation (uncommunicative disruptive mobile editor), and it may be helpful to have an RfC to get global consensus for a standard protocol for administrators to follow in these situations. Something like this, but fleshed out better:

  1. If an editor is making disruptive edits, and
  2. their edits are tagged as mobile edits [we should be specific about the tags], and
  3. they have made no discussion namespace edits [we should list those namespaces?], then
  4. a non-template message should be posted on their user talk page, which can be done by anyone, and
  5. if they continue making disruptive edits after the user talk page message is posted, then
  6. any admin is authorized to partially block the user from mainspace or, if necessary, to indef block the user with the standard block message: ["mobile communication bug" block message], and any editor may request such a block at ANI if the above requirements are met.

I'm not sure what to "fill in the blanks" with and/or where to document this, or if we already have something like this documented somewhere. I feel like it's really just a restatement of blocking policy and these steps would apply to any disruptive editor, mobile or otherwise, but I envision something like where an editor can go to ANI with "requesting a WP:THEYCANTHEARUS block" and then any admin would know how to respond to such a request (per global consensus). Levivich 17:43, 30 September 2021 (UTC)[reply]

If it's not redundant to established blocking policy, this sounds very reasonable. {{u|Sdkb}} talk 17:46, 30 September 2021 (UTC)[reply]
I really like the block message since afaik isn't actually being used currently. Although I'd like to amend it and say something along the lines of if the editor in question genuinely appears to have not realized they were doing something wrong they may be unblocked as long as they behave appropriately (maybe a partial block would be better just to make sure they're being honest). ― Blaze The WolfTalkBlaze Wolf#6545 18:34, 30 September 2021 (UTC)[reply]
+1 pblocking from mainspace should be the first option, I updated my OP accordingly. Thanks for the suggestion! Levivich 19:51, 30 September 2021 (UTC)[reply]
And also a tag, so we can find them, and try to gauge the impact scope? Mathglot (talk) 16:42, 1 October 2021 (UTC)[reply]
It might make sense in step 4 to clear the user's talk page except for that one message, so the important stuff ("please communicate") is easier to see. I also agree with Blaze The Wolf; I think a standardised block message should try to direct the user to their talk page as a final effort in telling them how to communicate with other editors. – Rummskartoffel 21:00, 30 September 2021 (UTC)[reply]
Maybe collapse (with some conventional, and helpful collapse bar title) instead of clear the page. Many won't know how to access history, and a collapse would provide essentially the same thing, that is, leaving (almost all) screen space for the latest message. Also, some messages shouldn't be cleared (maybe not even collapsed?). Mathglot (talk) 16:38, 1 October 2021 (UTC)[reply]
Collapsing doesn't work properly in at least the Android app and the mobile web interface. In the Android app, collapsing does nothing (except pointlessly add the completely unformatted text "Extended content"); the collapsed text is just displayed as if the collapse templates weren't present at all. In the mobile browser interface, if the section header is inside the collapse template, the section is completely invisible and cannot be expanded; if the section header is not inside the collapse template, the only thing the template does is to put a box around all the comments inside the section. I have created an example at User talk:Rummskartoffel/sandbox (direct link to mobile web version). – Rummskartoffel 19:43, 1 October 2021 (UTC)[reply]
@Sdkb:, also, to point 2: yes, please! I recently wondered about this factor at this ANI case ( perm). I was uncertain whether mobile user deafness could be involved in this user's non-responsiveness and ANI case, and linked this page. But, it turns out I was in error; as Asartea pointed out, "their contributions are not tagged with one of the mobile tags", which I hadn't considered, and was dimly aware of, if at all. (Btw, is the converse also true: that is, if someone is editing on mobile, will that *always* be tagged?)
So, the user in the ANI case appears to be a non-responsive desktop user and so apparently does not fall into the scope of these mobile comm bugs, and I likely would not have responded there as I did had I known about the tags. So as a corollary, I'd like to see a section added to this page about the mobile tags, which would list and briefly explain them, including what can (and cannot) be gleaned from their presence/absence. If this is covered somewhere else already in detail, then maybe just a WP:SS-style summary section with a {{Main}} or {{Further}} link; if it's covered somewhere, but only briefly, then maybe slurp the whole section. (Pinging Suffusion of Yellow who created the page and is the main developer, in case they prefer to keep this page lean and not branch off into related issues that are not strictly "bugs".) At a minimum, we should link to the tag information from here, and any new "mobile deafness" block consideration could point here, or link the same thing. Mathglot (talk) 19:57, 26 October 2021 (UTC)[reply]
@Mathglot: If the "tag" row isn't enough, I have no objections to a simple "how to figure out if you're dealing with a mobile editor, and if so what kind" guide. I've just been to lazy to write it. Suffusion of Yellow (talk) 00:25, 30 October 2021 (UTC)[reply]

Glossary or definition notes

[edit]

@Suffusion of Yellow: or anyone, could we have either a brief Terminology/Glossary section or more explanatory notes, to explain some of the terms used here? For starters, in the boxed material above the table, I see the terms mobile web interface as well as mobile app, and I'm not entirely sure what the difference is, other than the latter must be an app loaded from the app store (iOS or Android, I assume), which implies, since there are two terms, that the former term is not an app. Is the first one what I get when I click 'Mobile view' regardless what device I am on? Likewise for all the table column headers; I'm pretty fuzzy on what's meant by Mobile Web (IP) vs. iOS (IP), and so on. I can guess for most of them, but I'd rather have an explicit definition (linked, if possible) and not guess, as clearly these are shorthand for well-defined terms. Thanks, Mathglot (talk) 16:33, 1 October 2021 (UTC)[reply]

"Mobile Web" refers to the interface shown by default when viewing Wikipedia in the browser on a mobile device. You're right to assume that's the interface you see when you click "Mobile view". Android and iOS, respectively, refer to the Wikipedia apps for those platforms. – Rummskartoffel 19:43, 1 October 2021 (UTC)[reply]
@Mathglot: I added some links to the table header. If that's too WP:EGGy feel free to rework. Suffusion of Yellow (talk) 22:13, 2 October 2021 (UTC)[reply]

Snowmen bug?

[edit]

The snowmen bug should be added. Greatder (talk) 06:15, 19 October 2021 (UTC)[reply]

@Greatder: link, please? And/or: WP:BEBOLD. Mathglot (talk) 19:10, 26 October 2021 (UTC)[reply]
@Mathglot: https://www.mediawiki.org/wiki/Topic:Vu3252t6joywqesa?markasread=1369536&markasreadwiki=mediawikiwiki#flow-post-waw36a1r56yq504g Greatder (talk) 11:01, 27 October 2021 (UTC)[reply]
@Greatder: You are talking about this edit at MobileCoin, I believe. Whatever you saw, it sounds like it could have been a whole lot of things, not necessarily related to mobile communication bugs. The known issues listed in the table are all easily reproducible. If the effect you saw can be reliably reproduced, please leave instructions on how to do it. Otherwise, there just isn't enough information here to proceed. Mathglot (talk) 10:04, 29 October 2021 (UTC)[reply]

"Read more" suggestions -- where do they come from?

[edit]

(I don't know if this is a bug, but it seems like a usability issue; if I'm in the wrong place, let me know!)

I've gotten some very weird suggestions from the "Read more" sections. From Cincinnati chili I got a suggestion for Spaghetti Red, a similar dish that has been tagged for notability since 2011 and for zero sources since 2018 and which I've just AfD'd. Why would we want to suggest such a low-quality article to mobile readers? In Spaghetti Red's "Read more" our suggestions are List of Japanese dishes, List of Korean dishes, and Luosifen. Other than being food-related these have zero to do with Spaghetti Red. Where are these suggestions coming from? —valereee (talk) 15:05, 12 November 2021 (UTC)[reply]

@Valereee: See WP:Related Pages extension and the 2016 RFC linked there. I remember a discussion about the poor quality of the suggestions that happened sometime in the last two or three years, but I'm not sure where that was and can't seem to find it now. Levivich 15:29, 12 November 2021 (UTC)[reply]
@Levivich, thanks! Somewhere in the rabbithole that led me down I found a template to use to override the rando suggestions (which btw is {{#related: article}}, and you can specify up to three) that worked for a short while. Not sure why it stopped working again, but we're back to rando stuff. —valereee (talk) 19:02, 12 November 2021 (UTC)[reply]
@Valereee: Where is it not working? I checked New York City (which has three {{#related:}} articles specified), and they show up fine for me. Levivich 20:10, 12 November 2021 (UTC)[reply]
@Levivich, at Cincinnati chili. Maybe I'm doing something wrong? —valereee (talk) 21:39, 12 November 2021 (UTC)[reply]
@Valereee: I'm seeing the correct related articles (Buffalo Wing, Detroit-style pizza, Midwestern cuisine). What do you get, just random articles? Levivich 21:53, 12 November 2021 (UTC)[reply]
@Levivich, I'm sure I'm doing something stupid. Right now I'm getting Skyline Chili, Coney Island hot dog, and Cuisine of Kentucky. Which aren't bad choices except that the first two are already linked in the article. Refreshed and got Slinger (dish), Hot dog variations, and Cheese dog, also not bad choices. Refresh again, Cuisine of the Midwestern United States, Chili con carne, Chili dog. —valereee (talk) 22:00, 12 November 2021 (UTC)[reply]
Weird, it's still showing me those same correct articles every time I refresh. I'm not sure why the overrides are showing for me but not for you; beyond my technical knowledge. Maybe move this thread to WP:VPT? (This page may not get the right eyes for this as this isn't a mobile communication bug.) Levivich 22:07, 12 November 2021 (UTC)[reply]

Here's the query behind this: https://en.m.wikipedia.org/w/api.php?action=query&format=json&formatversion=2&prop=pageimages%7Cdescription&piprop=thumbnail&pithumbsize=160&pilimit=3&generator=search&gsrsearch=morelike:Cincinnati_chili&gsrnamespace=0&gsrlimit=3&gsrqiprofile=classic_noboostlinks&uselang=content&smaxage=86400&maxage=86400

Edit notices

[edit]

Hi folks! Just a note that edit notices are now shown in the Android app (when entering the workflow of editing the wikitext of any section). Also, talk page banners are also shown, albeit as a separate topmost "topic" in the Talk interface. DBrant (WMF) (talk) 17:51, 26 January 2022 (UTC)[reply]

@DBrant (WMF), glad to hear! I've updated the chart. There's still work to do for mobile web/iOS, though, thus my wishlist suggestion below. Cheers, {{u|Sdkb}} talk 22:50, 29 January 2022 (UTC)[reply]

Suggested wishlist item

[edit]

Hi all! I encourage you to go support Show editnotices on mobile at the wishlist. Cheers, {{u|Sdkb}} talk 22:47, 29 January 2022 (UTC)[reply]

Help? Please?

[edit]

So I just spent the last hour tearing my hair out trying to test if a "fixed" bug is actually fixed. I'd like to spend my time doing something else, or I'm going to say something I regret.

So, can I get some help testing please? I'll give detailed instructions, but you will need to expose your own IP. Suffusion of Yellow (talk) 22:05, 4 February 2022 (UTC)[reply]

Cliffhanger! What was this? – SJ + 15:57, 2 May 2022 (UTC)[reply]
@Sj:
  1. On your desktop device, log in to your account.
  2. On your mobile device, log out, and go to https://en.m.wikipedia.org/w/api.php?action=query&meta=userinfo, and write down what Wikipedia sees as your IP
  3. On your mobile device, either clear all cookies, or close all browser tabs, and open a new private tab. This is important. You may have left over session cookies, even if you're logged out, or even if you never logged in.
  4. On your mobile deivce, go to https://en.m.wikipedia.org/. Click on mainspace links until you find some article to edit. Do not click on anything that is not a mainspace link. Do not visit the desktop site. Do not visit this page. Do not attempt to view the history of any page, or do anything apart from read articles.
  5. On your mobile device, make an edit to an article. A WP:DUMMYEDIT is sufficient. A WP:NULLEDIT is not. (This step of course will expose your IP)
  6. On your desktop device, while still logged in, leave a message on the user talk page of the IP you recorded in step 2.
  7. On your mobile device, attempt to edit the same page.
  8. You should see a "you have new messages" alert.
This is all seems complicated, but it's really just the normal steps of "reader sees something to fix, tries to fix it, but breaks it instead, and you need to tell them that they broke it or they'll do it again".
Now I already know this works some of the time. So we can't just look for mobile IPs responding to talk page messages; that would prove nothing. Ideally as many people as possible should try this, and get an alert every time. Suffusion of Yellow (talk) 17:42, 2 May 2022 (UTC)[reply]
Indeed it does not work. A light yellow banner is visible on pages of every namespace except the article namespace. [android:ff/chrome] – SJ + 20:44, 2 May 2022 (UTC)[reply]
Thank you! @Sj: Just to be totally clear, it doesn't appear even when you click "edit" in step 7? In mainspace, it's never supposed to show when you're just reading. (This is to avoid bothering the next person who got assigned the IP). You need to attempt to edit something. Suffusion of Yellow (talk) 20:53, 2 May 2022 (UTC)[reply]
Correct, not even when editing.
And while it shows up on most non-NS0 pages, it doesn't on some. Talk:World Snooker Tour for instance! – SJ + 20:58, 2 May 2022 (UTC)[reply]
Thanks again. What's happening here is that you're seeing the cached version, because your session cookies aren't set. So the banner should always show on uncachable pages (Special:Whatever), or pages that don't happen to be cached (e.g. obscure talk pages). But the talk page of TFA is probably getting lots of hits, so it's cached. Now successfully saving an edit is supposed to set session cookies. I don't know why it's not. Suffusion of Yellow (talk) 21:14, 2 May 2022 (UTC)[reply]

Ok, the following is replicable for me on chrome (ff, after a hiccup, now shows a banner persistently on all edits and talk pages, even on a new private tab):

NS0 pages that don't show a banner on edit: Rebranding, World Snooker Tour, Stock, IOU,
NS0 pages that do show a banner on edit: Dividend, Multilateral exchange
NS1 pages that don't show a banner: Talk:World Snooker Tour

Also noted: sometimes when loading a page, it will first show an older, more colorful (desktop-like layout, from before recent years' updates) banner at the top, and only after a second or so redraw the whole page w/ the smoothed modern mobile interface. Could there be a race condition w/ multiple style sheets for the same names rendering at different times based on [???]? – SJ + 21:28, 2 May 2022 (UTC)[reply]

Thank you again. But I don't know where to go from here. I had thought this really was fixed. Suffusion of Yellow (talk) 22:16, 3 May 2022 (UTC)[reply]

Editnotices/iOS

[edit]

According to the table I shouldn't be able to see the talkpage editnotice that's just been put on Talk:Turkey on my iPad and iPhone. But I can. DeCausa (talk) 16:46, 21 June 2022 (UTC)[reply]

Are you using your iOS devices' browser (probably Safari) or the Wikipedia iOS app? The table means "iOS" to refer to the app – browser users on iOS would fall under Mobile Web or Desktop, depending on which they use. Rummskartoffel 19:49, 21 June 2022 (UTC)[reply]
Ah ok. I'm using safari not the app. That would explain that. (I'm sure from the table that would be obvious to the more tech-literate, but not me!) Thanks. DeCausa (talk) 20:31, 21 June 2022 (UTC)[reply]
It may be obvious to some users, but there's nothing to be gained from it being hard to understand to anybody else, so I've gone and added "app" to the relevant table headers in an attempt to make it more easy to understand in future. Rummskartoffel 21:01, 21 June 2022 (UTC)[reply]

Duplicate notifications

[edit]

There was a question at the Teahouse about someone recieving duplicate notifications relating to edit milestones. See here. I'm not sure if there's broader applicability but I wanted to mention it since this is the page that's specifically about mobile communication bugs. Clovermoss🍀 (talk) 03:12, 25 November 2022 (UTC)[reply]

Requested move 16 January 2023

[edit]
The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review after discussing it on the closer's talk page. No further edits should be made to this discussion.

The result of the move request was: not moved. Extraordinary Writ (talk) 21:53, 1 February 2023 (UTC)[reply]

Wikipedia:Mobile communication bugs → Wikipedia:Communication bugs – The current title made a lot of sense when the only bugs listed here were mobile communication issues, but the inclusion of DiscussionTools makes the current title less accurate than the proposed title. — Red-tailed hawk (nest) 19:11, 16 January 2023 (UTC) — Relisting.  ASUKITE 15:16, 25 January 2023 (UTC)[reply]

I'm not sure if that would be helpful. The current title is direct and IMO it was helpful in motivating developers and decisionmakers to work on the required improvements. "Communication bugs" is, in comparison, a vague unactionable complaint.
I would actually suggest removing the "DiscussionTools" column from the page (it was added somewhat recently: [1]), I think it is distracting from the purpose of the page and it doesn't have the kind of issues that led to the creation of this page. If you want to keep the information, I think it could go as notes in the "Desktop" and "Mobile Web" columns, like the mentions of the desktop Minerva skin. Matma Rex talk 23:52, 17 January 2023 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

I went ahead and removed the DiscussionTools column: [2]. I kept the content in footnotes, although I'm not sure if that isn't too much detail… I hope that's okay, feel free to edit if not. Matma Rex talk 23:26, 1 February 2023 (UTC)[reply]

Mobile DiscussionTools deployment

[edit]

Hi y'all – as people motivated to improve the mobile communication experiences, the Editing Team thought you would value being aware of, and potentially participating in, a discussion about the proposed plan to make the suite of mobile DiscussionTools available to everyone (logged in and out) at en.wiki the week of 6 March 2023.

A screenshot showing what mobile Wikipedia talk pages look like when DiscussionTools are enabled.
What mobile talk pages look like when DiscussionTools are enabled.


Please feel free to ping @Whatamidoing (WMF) or me if the above brings any questions to mind.

In the meantime, you can see and try the mobile DiscussionTools by appending ?dtenable=1 to the URL of any en.wiki talk page. E.g. https://en.m.wikipedia.org/w/index.php?title=Wikipedia_talk:Talk_pages_project&dtenable=1. PPelberg (WMF) (talk) 05:21, 23 February 2023 (UTC)[reply]

@Suffusion of Yellow, as someone who has been key in improving the mobile communication experience, I thought you'd value knowing that the Editing Team is planning to offer the suite of mobile DiscussionTools as default-on features for people who are logged in and out at en.wiki next week.
In doing so, "Custom edit filter messages" and "Talk page banners" will become available on mobile talk pages.
Please let me know if anything about the above brings new questions to mind. PPelberg (WMF) (talk) 02:11, 3 March 2023 (UTC)[reply]
Update: last week, mobile DiscussionTools became available to everyone (logged in and out) at en.wiki by default.
As a result, talk page banners and custom edit filter messages should now be available to everyone. I've indicated as much by updating the project page. PPelberg (WMF) (talk) 21:53, 14 March 2023 (UTC)[reply]
@PPelberg (WMF): Thanks for the heads up. I can confirm that edit filter messages now work (at least while logged in). But I see no talk banners. They're still hidden behind a "Learn more about this page" link, which nearly defeats their purpose. Suffusion of Yellow (talk) 20:55, 18 March 2023 (UTC)[reply]

Talk page banners on Android

[edit]

It looks like talk page banners finally appear on the top and with different styling on Android, at least in simple cases. However, I’m not sure how this copes with more complicated cases like signed comments in the lead section, or when the fix has been released (a random task I found about this matter is phab:T310801, but that doesn’t seem to be the original task nor does it link to it), could someone with more knowledge or confidence update the table? Maybe @DBrant (WMF), who has commented about the Android app in an earlier section. —Tacsipacsi (talk) 17:37, 16 April 2023 (UTC)[reply]

FYI, thanks to @Izno (T324139#8433778), there is now a tracking category for pages that have signed comments in the lead section: Category:Talk pages with comments before the first section (defined in MediaWiki:Discussiontools-comments-before-first-heading-category). This can be used by developers to test how the apps cope with this situation, or by users to clean up those pages, since even in the best case the app will have to make some guesses when displaying these comments / leads. Also, if you have an Android device, I'd be curious to see some screenshots of how it behaves. Matma Rex talk 03:17, 17 April 2023 (UTC)[reply]
@Matma Rex: Thanks! I new it was in the works, but I didn’t realize that it has already been deployed and enabled. I randomly chose Talk:5th Marine Regiment, and it displays a topic (rather than a header) in which the first comment contains the message boxes as well. Screenshots: phab:F36955529, phab:F36955530 (app version 2.7.50436-alpha-2023-04-06). By the way, the boxes being broken is not specific to this case, even talk pages whose lead section contains no comments lack box styles. —Tacsipacsi (talk) 14:46, 18 April 2023 (UTC)[reply]

Amboxes

[edit]

@Izno: I think amboxes deserve a place here. While they are indeed not as direct attempts to communicate as most of the others, I don’t think article message boxes are less direct attempts to communicate than talk message boxes, which are already listed, and they’re just a bit less direct than editnotices. —Tacsipacsi (talk) 01:56, 23 April 2023 (UTC)[reply]

If an ambox is missing, life will more or less go on. There is no threat of a sanction and certainly there isn't active communication for someone using these systems who ignores an ambox. This is my primary reason for suggesting it's not appropriate to put them on this list. Izno (talk) 15:26, 27 April 2023 (UTC)[reply]
For that matter, I don't really see why CentralNotice is on this list either. Same reasoning. Izno (talk) 20:45, 27 April 2023 (UTC)[reply]
[C]ertainly there isn't active communication for someone using these systems who ignores an ambox – it depends. In most cases, there isn’t, but for example if someone ignores {{in use}}, they may well get active (and even quite upset) communication from the person who got an edit conflict despite having been added the ambox. On the other hand, I don’t think we should even have that strict inclusion criteria; what harm does it cause if there are more rows in the table? —Tacsipacsi (talk) 08:01, 28 April 2023 (UTC)[reply]
I don't see why not. They're not that different from talk page banners or central notices in that they're alerting readers of something specific about the page content. The very fact they used to be hidden on MobileFrontend but not anymore is a testament to this being a "mobile communication bug". Nardog (talk) 17:48, 28 April 2023 (UTC)[reply]

Discussion at phab:T341305

[edit]

 You are invited to join the discussion at phab:T341305. The title of the ticket is "Talk page notification alert bar: revised styling to meet WCAG color contrast AA requirements". A couple proposals have been made so far that lower the visibility of the user talk message orange alert bar. –Novem Linguae (talk) 20:45, 26 June 2024 (UTC)[reply]

Some observations

[edit]

I've tried mobile web on Chrome (vector 2022) out of curiousity the past few days and I've noticed some things.

  • Sometimes talk page sections "freeze" and don't open up
  • Pings work normally (I'll get red notifications)
  • Thanks notifications don't show up until I click on it (same look as no notifications/all read)
  • Subscribed thread notifications have a slight difference but fade into the background (see File:Faded notification on mobile web.png).

Clovermoss🍀 (talk) 01:12, 11 October 2024 (UTC)[reply]

I can comment only on two of the four items:
  • Sometimes talk page sections "freeze" and don't open up – same in Firefox on Android, very frequent;
  • Subscribed thread notifications have a slight difference but fade into the background (see File:Faded notification on mobile web.png). – this is phab:T376359 and phab:T376414 (from Wikipedia:Village pump (technical)/Archive 215#Watchlist icon issue on Mobile).
—⁠andrybak (talk) 08:32, 11 October 2024 (UTC)[reply]
Thanks. I wasn't sure if these were already known issues (hence my talk page comment here). Clovermoss🍀 (talk) 13:13, 11 October 2024 (UTC)[reply]
Poked around, and came up with a possible answer to Thanks notifications don't show up until I click on it (same look as no notifications/all read) – I'm pretty sure that's intentional, because in Minerva, the button for notifications merges two corresponding buttons of the desktop website: "alerts" and "notices". Only alerts make the mobile button red. However, IIRC, the notices are also counted towards the total, when the number in a red circle is shown. —⁠andrybak (talk) 14:30, 11 October 2024 (UTC)[reply]
I'm used to vector 2010 where it does show as a light blue. I only switched to vector 2022 a few days ago because I'm trying to understand what everything looks like to a newbie. Clovermoss🍀 (talk) 18:16, 11 October 2024 (UTC)[reply]
I just confirmed that it shows up as light blue on vector 2022 desktop as well. I don't think it's supposed to be nonexistent on mobile web. Clovermoss🍀 (talk) 18:45, 11 October 2024 (UTC)[reply]
For how the counter in Minerva works, I found related ticket phab:T310559.
I tried digging to find where it all comes from, but wasn't very successful.
At this point I recommend contacting people who worked on it. I don't know what's the best place to ask.mw:Project:Support desk or WP:VPWMF, perhaps? —⁠andrybak (talk) 19:25, 11 October 2024 (UTC)[reply]
@MMiller (WMF): Now that I'm more sure that this might be something worth bugging you about, do you know who the best person to contact about this is? Clovermoss🍀 (talk) 19:46, 11 October 2024 (UTC)[reply]
Hi @Clovermoss -- thanks for getting in touch about this. I want to make sure I know what you're trying out here. You usually edit in desktop view from your phone, so what is the new thing you're doing? Is it that you're trying out Chrome but usually use a different browser? Or that you usually use Vector 2010 and you're trying out Vector 2022? MMiller (WMF) (talk) 21:24, 11 October 2024 (UTC)[reply]
@MMiller (WMF): The new thing is that I am trying out the mobile version of the site and in Vector 2022. Figured I'd mix things up. Clovermoss🍀 (talk) 23:00, 11 October 2024 (UTC)[reply]
Okay, I just want to double-check because I'm a little confused. I remember you saying that you usually edit using the desktop site on your phone, and it sounds like now you're trying the mobile site for the first time. The thing is that our mobile skin is called MinervaNeue. For desktop there are two popular skins, called Vector 2010 and Vector 2022, and so when you use the desktop site on your phone, you're in one of the Vector skins. The screenshot you posted here is in MinervaNeue -- so I think that's the skin we're talking about, right?
If you want to check out the difference between Vector 2010 and Vector 2022, you can switch them around if you go to Preferences and then the Appearance tab. MMiller (WMF) (talk) 23:16, 11 October 2024 (UTC)[reply]
@MMiller (WMF): I suppose we're talking about MinervaNeue then. My confusion comes from what I have set in my preferences, I wasn't expecting mobile web to have its own separate thing. Clovermoss🍀 (talk) 01:26, 12 October 2024 (UTC)[reply]
Okay, got it. Yeah, when you open the mobile site (en.m.wikipedia.org), it automatically uses the Minerva skin. Your preferences indicate your default skin for opening the desktop site. You're making me realize that distinction could be clearer.
Anyway! I am pinging @OVasileva (WMF) who is the product manager for the Web team, and @PPelberg (WMF), who the product manager for Discussion Tools. Between them, I think they can help you think about the bugs you and @Andrybak noticed. MMiller (WMF) (talk) 21:58, 12 October 2024 (UTC)[reply]
Hi @Clovermoss, @Andrybak - thanks for flagging these! For a bit of background, we accidentally introduced a few bugs last week as we were migrating some of the icons on our mobile skin, MinervaNeue, to use our design system Codex. These changes were causing the issues you saw with notification color and disappearing icons. These are now fixed, but let us know if you're still experiencing any weirdness. More info on the change that caused these is available on this ticket. OVasileva (WMF) (talk) 15:49, 14 October 2024 (UTC)[reply]
Hi @Clovermoss and @Andrybak - thanks for flagging the talk page issue. I've created a phab ticket, and we'll report back once we got a chance to look into this in more detail. SPerry-WMF (talk) 15:22, 18 October 2024 (UTC)[reply]

Relation to mobile edit tags in the history

[edit]

Suffusion of Yellow, I recently added section § Tags to Help page Help:Mobile access, and I would like to say something here at WP:Mobile communication bugs about which tags might lead one to conclude that a user whose edits are thus tagged are likely to fall into the They Can't Hear You group, but I am not sure which ones they are, or even if the presence of one or more of these tags is conclusive. Can we add some sort of section below the table about tags, discussing this situation?

Likewise, I would like to augment the new Tags section at Help:Mobile access to, um, tag some of the tags listed there with some icon or link here, for those tags which imply a risk of TCHY (and to prune any that don't belong). However, I am at a loss where to find the information about this relation. Special:Tags doesn't have much. Can you or anyone help? Mathglot (talk) 20:36, 5 November 2024 (UTC)[reply]

Hmm, Suffusion last edited in July, so not sure if they will see this. Anyone else know about this? Mathglot (talk) 20:37, 5 November 2024 (UTC)[reply]
@Mathglot: Sorry, I haven't really kept up on recent changes to the mobile site/apps. AFAIK mobile edits should always have at least one of the three tags already mentioned in the table, but I haven't tested recently. Suffusion of Yellow (talk) 21:59, 10 November 2024 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Mobile_communication_bugs&oldid=1256639716"