Page MenuHomePhabricator

No categories displayed in MobileFrontend output
Closed, DuplicatePublic

Assigned To
None
Authored By
Verdy_p
Apr 22 2016, 5:56 PM
Referenced Files
F3942945: categories.gif
Apr 28 2016, 5:24 PM
F3940485: Screenshot_2016-04-28-04-02-08.png
Apr 28 2016, 2:10 AM
F3940458: Screenshot_2016-04-28-03-57-29.png
Apr 28 2016, 2:01 AM
F3940453: Screenshot_2016-04-28-03-57-29.png
Apr 28 2016, 1:59 AM
F3940446: Screenshot_2016-04-28-03-47-59.png
Apr 28 2016, 1:58 AM
F3940437: Screenshot_2016-04-28-03-49-40.png
Apr 28 2016, 1:58 AM
F3940452: Screenshot_2016-04-28-03-57-29.png
Apr 28 2016, 1:58 AM
F3933423: Screen Shot 2016-04-26 at 10.39.13 AM.png
Apr 26 2016, 5:41 PM

Description

I've not found any way to display the categories at bottom of pages on the mobile version.

There's :

  • no collapsible option for them, and
  • no configuration option in panel displayed from the left-side "Configuration" menu, which only allows selecting if we want to display images (on by default) or not.
  • no item in the left menu pane as well to list these categories on demand

How can we navigate categories on mobile wikis ??

We can only list the content of a category, provided we find a link to it, but no way to see the categories of pages, or parent categories of categories !!!

This is an important bug that impact severely almost all pages on Mobile MediaWiki (and notably those that are supposed to be navigated most by categories only)

Event Timeline

First you need to enable the beta feature, then you can go to a page and scroll down the page. If you see the Categories button next to the Talk button then the page has categories, otherwise it doesn't. Clicking on the button will obviously allow you to see the categories. Here is a page where there are categories: https://en.m.wikipedia.org/wiki/Book?mobileaction=beta

That button should always be there. It is ALWAYS missing (invisible) on smartphones (e.g. Android), and there's no such "Beta" option available on the Android version of the wiki.
I can only see this button when viewing the mobile from the PC (even if "Beta" is not enabled)

Also on Android, the only button I see at bottom of the mobile version of Wikipedia is "View in another language".
There's no "Talk" or "Categories" button, EVEN if the "Beta" option is enabled on the lateral Preferences menu.

These remarks on Android are true, independantly of if I'm logged in or not with my Wikimedia account.
In other words the missing features are only in the Windows version with all browsers (may be it is available on OSX or iOS too, but I could not test them)
I tried 3 browsers on Android (stock browser, Chrome, and Firefox), none are displaying these buttons; they all display a "Beta" button in preferences, but it has no effect at all.

OK, can you also share more info about your device? What is it called, what version of Android are you running, and what versions of browsers are you running? Thanks!

I have the same problem on my two HTC models, as well on my older Samsung Galaxy S 3.
They are running Android 4.2 for the older one, and Android 5 for the newer (with a firmware last updated in last november 2015)
I think that all Android smartphones have this problem (don't trust what you may see in "smartphone emulators" that you can find in some browsers for Windows).

@Verdy_p thanks for the info. That's a weird problem as I see this working correctly on my Android 6 with latest Firefox. We'll look into the issue more.

Peachey88 renamed this task from Bug: No categories at all on Mobile wikis ! to No categories displayed in MobileFrontend output.Apr 23 2016, 10:18 AM

I believe this is a duplicate of T24660

@Verdy_p can you confirm a few things.

Can you confirm it is ticked like so?:

Screen Shot 2016-04-26 at 10.38.29 AM.png (391×394 px, 31 KB)

  • Can you confirm that the search bar looks like this:

Screen Shot 2016-04-26 at 10.39.13 AM.png (52×267 px, 13 KB)

  • The categories are showing for me in beta but not when beta is enabled on my Android devices. It looks like this:

Screen Shot 2016-04-26 at 10.38.59 AM.png (114×360 px, 14 KB)

(Note this is not the same as the desktop beta features as visible on https://en.wikipedia.org/wiki/Special:Preferences

Yes I am speaking of the same "Beta" button, in the specific preference panel of the Mobile frontend (not the user preferences on the desktop version, which also makes no differences when it is enabled there to allow desktop features

Yes The top searc bar looks like this

And no, checking or not that Beta button plays no difference, Categories are hidden in both cases (no such "Categories" button at bottom of the article)


This "Categories" button is probably not the best place to there anyway, it should better be put in the left-side menu, along with the "Edit this page" instead of the ugly pencil icon taking a large vertical space at top of the article; note that pencil buttons for editing individual sections are placed on the left of the section heading, this is not the case of the pencil button not placed to the left of the article title, but below it).

As well the line showing "Last edited x days ago by User:Y" could be in the information window which would show the history (we never see that info directly on the page on the desktop version, we always see that in the "history" page). The information window would also link to the attributions (the user page). This line here just useless shows a user name.

@Verdy_p can you give us a single URL to replicate (regardless of whether it's an issue on every page or not)?
Thank you.

@Verdy_p

  • Are you logged in or anonymous?
  • Do you have any gadgets installed?
  • Can you upload some screenshots?
  • My account has a few common gadgets, and some custom javascript, but there's absolutely no error reported on the console (no deperecated API). These javascripts only handle sorting tables and changing the destination of the home page for the top-left Wikipedia icon on the desktop version but only on Wikipedia.
  • Being logged in or not does not change the behavior, so gadgets or any other personal preferences are not an issue.
  • All pages on all Wikimedia wikis are affected

Bottom of the home page of English Wiktionary (logged in):

Screenshot_2016-04-28-03-49-40.png (1×720 px, 124 KB)

Bottom of the home page of French Wikipedia (logged in):
Screenshot_2016-04-28-03-47-59.png (1×720 px, 160 KB)

Bottom of the home page of Metawiki (not logged in):

Screenshot_2016-04-28-04-02-08.png (1×720 px, 214 KB)

Apparently there's a conflict with the generation of the button "Read in another language" and the button "Categories". Both cannot coexist, or one overwrites the other.

Just to clarify, is it just the homepage you see this issue? I can replicate this issue on homepage but not on a standard article page.

https://en.m.wiktionary.org/w/index.php?title=Wiktionary:Main_Page&mobileaction=beta
https://en.m.wiktionary.org/wiki/Wankelmut?mobileaction=beta

I've still not been able to locate ANY page on any wiki that shows the categories button.
No this is not specific to the home page (where there's not always a category, even if many wikis have a hidden category there)
May be this is caused by the hidden categories in those pages (many pages have hidden categories for various internal tracking purposes)

And sorry for the previous reedited message with the empty image. There was a temporary issue copy-pasting the image, each time I got a 0-byte upload, apparently caused by my smartphone (I had to upload the snapshot first to my synchronized Google Drive to get a non-truncated upload that I could copy-paste correctly here.

Apparently it is also not possible to drag and drop from the smartphone storage (connected via USB) to this page on a PC browser, probably a security barrier set by the browser between the web and my local USB device against cross-site scripting)

This remark however is not related to this discussion. But it's not easy to put mobile snapshots here (it would have been even more difficult to post it on Commons, and not needed there).

Also did you really test the two links above with a smartphone (not on a PC browser) ? I see the buttons on my PC (browsing with Google Chrome), not on my Android smartphone. There's something in the javascripts downloaded by mobiles that prevent these displays.

Yes. I have 5 devices in the office I tried this one, I've tried devices in browserstack.com and right now I am on my phone device (android) looking at categories. As a result I'm baffled at what's going on in your device and really keen to get to the bottom and of it. I really appreciate all the help so far so apologies I haven't got there just yet.

I'll upload a screenshot I just took when I'm back at my laptop of what I see. I see a talk and a category icon here at the bottom:
https://en.m.wikipedia.org/wiki/San_Francisco_8?mobileaction=beta
What do you see?
Do you see either button when logged in/anon?

@Florian can you think of any theories?

https://en.m.wikipedia.org/wiki/San_Francisco_8?mobileaction=beta

  • That's the first time I see a "categories" button there. Coincidentally on a page that has NO translation (no button to "See this this page in another language")
  • On this page now, I see the button whever I'm logged in or not, with or without the "Beta" option checked (in the Preferences from the mobile side bar).

However, on the desktop version:

https://en.wikipedia.org/wiki/San_Francisco_8

  • There are two listed translations... not displayed now on the mobile version.
  • There are categories too.

So The mobile version has replaced the button to display translations by the button to display categories.

The language button has moved to the top in beta mode. It is still there in top left corner.

If you visit https://en.m.wikipedia.org/wiki/San_Francisco_8 do you see the same?

I'm pretty confident something is going wrong when you opt into beta.
To be crystal clear to you, this is what I see on my device and how I opt into beta:

categories.gif (647×440 px, 2 MB)

Are you able to upload a similar gif (I used the application licecap to make this)

You are too much confident, I do exactly the same thing to opt into Beta in the same left-side panel.
And no I cannot create and upload such animated GIF.
May be the only difference is that my Android devices are all set with a default French locale (I did not test it by using English by default in the device's system settings, I know that it will cause issues in many apps not prepared to allow changes of system locale).

IMHO this is a bug in the javascript (or in non-unique CSS selectors when using jQuery) that causes these scripts to overwrite these buttons

May be the only difference is that my Android devices are all set with a default French locale (I did not test it by using English by default in the device's system settings, I know that it will cause issues in many apps not prepared to allow changes of system locale).

It doesn't seem to be language specific: https://en.m.wikipedia.org/wiki/San_Francisco_8?uselang=fr

IMHO this is a bug in the javascript (or in non-unique CSS selectors when using jQuery) that causes these scripts to overwrite these buttons

I can't reproduce the problem, too (in the chrome web tools emulator and on two devices, HTC One M9 and Nexus 9). Could you please try to open a new incognito tab and load the page there, so you have a clean session? Do you get the same result?

I have already tested with not being logged in (see above)
Using a clean cache does not change the issue. Changing for another browser (I tested with the stock Android browser, with Android Chrome and with Android Firefox) on my HTC does not change the results, I still don't find the Categories

Note: when I spoke about the locale, I was NOT speaking about the language of the wiki (I have the same issue on English or French wikis, or on Meta and Commons that are internationalized but with default in English), but the language of the device itself (i.e. the default language reported by the browser in HTTP request headers, and also used when executing the downloaded scripts if ever these scripts are locale-sensitive, for example in number formatting; I have not investigated if this could be the cause).

It seems the bug here is that you are not correctly opting into beta for some reason which suggests some kind of cache issue

Please tell me what you see at the bottom of the page https://en.m.wikipedia.org/wiki/San_Francisco_8 (this is a different url to before)/do you see talk and language button?

I confirm this is not a local caching issue. I clear the cache on my smartphone several times a day, automatically due to limited storage space.
Loading the page in a private web session (ignoring caches, cookies, local storage and so on) does not change anything.
And this affects 3 different Android devices as well.
OK I cannot reproduce it when using emulators (such as Chrome on Windows with the developer console), but I think that the mulation is still not perfect.
I even tried configuring the device and reboot it using English as its default locale, and this does not change anything, Categories are not always shown where they should be.
I have no idea what to do more, I have correctly set the Beta option like everyone would do it on a smartphone.

May be this is a problem of execution order in one of the loaded scripts, i.e. dependencies missing in the script loader.

I wasn't suggesting a local caching issue. I'm worried thus might be on the varnish level. Can you please answer my above question?

What do you see at the bottom of https://en.m.wikipedia.org/wiki/San_Francisco_8 ?
What do you see at the top of the page?

For whatever reason you are not being opted into beta correctly. This could either be because the save button on Special:MobileOptions is not working for you or our caching servers are sending you the wrong thing. It is not possible that this is JavaScript related.

Do you have cookies disabled? This could also cause issues.

Jdlrobson changed the task status from Open to Stalled.Apr 29 2016, 2:59 PM

Until an engineer can reproduce this issue.

Bottom of the home page of English Wiktionary (logged in):

Screenshot_2016-04-28-03-49-40.png (1×720 px, 124 KB)

The screenshot above clearly shows that the user was not able to switch to beta because in beta the language button is at the top of the page.

I can kind of re-produce the issue. I’m using Android 4.1.1 on a Samsung Nexus S. Here are the steps:

  1. Visit https://en.m.wiktionary.org/wiki/Wankelmut
  2. Click on the hamburger menu and click on the settings
  3. When the settings page opens check off the beta checkbox, and click on save
  4. Wait until the URL in step 1 opens and notice that the header does not have the word “Beta” in the search bar. Scroll to the bottom of the page and notice that no “Categories” button appears.
  5. However, when I refresh the page, the site correctly switches to the beta version (the word “Beta” appears in the search bar) and the “Categories” button shows up at the bottom of the page.
  6. Additionally, switching back to “Stable” via the hamburger menu doesn’t work until the page is refreshed as in step 5.

Duplicate of T14975 ? Wrong. T148975 was a later created duplicate bug, with an unrelated problem. This current bug was not about the "beta option", even if it depended on it to work.
In fact cdategories are still not displayed for non logged in users, anon given they cannot optin to the beta feature.
I consider this old bug still open (indepenantly of T148975 releted to a specific problem occuring when anon users are visiting only those wikis in the beta cluster !

But anon users should still be able to navigate categories on their mobile without even having to optin some "beta" feature on any wiki. Navigating categories should be possible immediately (at least from the panel that pops up when clicking in "hamburger" menu icon [≡] in the top corner of the mobile page to show all possible actions on this page: categories, talk, edit, talk, links to other language versions, etc. or user preferences, personal talk page, etc., i.e. all options that are normally accessible from modules in the side bar or the top bar of the desktop version)

So you close this old bug request (that you refused to honor, saying it was duplicate when it was not) and for that you have created MUCH LATER a new bug...

I was perfectly right the first time.