@ovasileva nope, it's available for all. e.g. an IP userpage: https://en.m.wikipedia.org/wiki/User:66.87.68.6

@matmarex thanks for the insight. I see it's a tricky issue because a fixed or min width is sometimes desirable. What I did to work around this issue in this case is set a max-width:100% on the container element, which offsets the min-width value.

I've created T225499 and updated T223363 (that one could probably use more detail though) to reflect what I think are the two bigs chunks of work in this spike.

1. Make the filter dropdown work on mobile
2. Make the filters look good :)

I've closed this task because while analyzing T224655 I discovered this can be fixed with OneLineOfCSS™️, so I bundled that change with a few other that would make this dropdown widget adequately function on mobile: T225499.

@alexhollender, yes, all three filters use the same dropdown, and are thus equally broken :)

When looking at this task, it occurred to me that a lot of the features work to an acceptable degree on mobile (IMO).

I dug into this a bit today, and this bug is interesting. It's not a problem with the CSS or positioning of the search suggestions, but it's tied to how Android handles blur events.

This task seems to want 2 things:

Wrong token error
I've tracked down our special Minerva token error (I hope). It comes from the World.js file exporting an instance of MWBot, which holds on to its edit token. The wdio-mediawiki library requests new edit tokens for each api action, and so when we try to use that first instance, it's edit token has already been invalidated.

Error setting beta mode

Wrong token error

The online fundraising team can probably deploy this via CentralNotice for the purpose of initial testing

Regarding the implementation details. it's worth noting that the main menu is generated client-side, so if CentralNotice were to add a menu item, it would have to do so after the menu is generated.

@Edtadros this is live on the beta cluster right now.
e.g:
https://en.m.wikipedia.beta.wmflabs.org/wiki/User:192.178.9.23
vs.
https://en.m.wikipedia.org/wiki/User:192.178.9.23

this change is visible on the beta cluster right now: https://en.m.wikipedia.beta.wmflabs.org/wiki/Albert_Einstein
(the .reflist element has a column-gap: 2em; rule).

@alexhollender the patch above adds a column-gap: 2em to the references list (instead of padding-right: 1em). Due to the difference in font size between Vector and Minerva, it's hard to judge if this is enough, but it's more it was before.

Probably caching. The links show up now.

This is something that a user on the MediaWiki Support Desk commented, so I'm not sure if this is actually a bug or not.

@Dyingfromhorribledesign could you please specify which app you're referring to? (Android or iOS)

The patch above fixes the z-index issue.

The workflow for when to display the stylized pages and when not was a little confusing to me at first, so I made this chart to help me step through each scenario. Maybe it'll helpful for QA or something.

Armchair designer here:
Since the "In other projects" menu link behaves differently than the other menu links, could we differentiate its bit more?
My suggestion would be to add an ">" forward arrow after the text, so it reads "[icon] In other projects [>]" .
Has that already been considered?

user pages that exist on a different wiki

Good point. I'm not sure how those kinds of pages will work. My guess is that they will show up as an "existing" page, and not as a red-link page. I think it has a "create" button on desktop because you might be able to override that page by creating a local version of it. I'm not sure how to test this behaviour locally though, so I'll need to dig into it a little more to see what happens.

@Nikerabbit yeah, that sounds like a good idea :)

you can call the mediawiki.ui mixin from whereever

Unfortunately that's not the case :( Only files in resources/src/mediawiki.less/ get that global magic, whereas the button styles are in resources/src/mediawiki.ui/.

@Volker_E, for this task, we don't want to change the look these buttons on desktop, so we're not placing the css classes mw-ui-button mw-ui-primary mw-ui-progressive in the button HTML. Instead, we have to add these styles to the existing classes. To achieve this, we have to create a mixin that contains all the button styles we want to use on this element. The core patch above moves one button mixin into the mediawiki.less folder, making it available in Minerva.

This just needs QA steps, but I'm having a hard time tracking down similar references other than the exact one in the description.

@alexhollender

should we ditch the "Compare selected revisions" button at the bottom of the page?

@alexhollender re: radio button functionality & grey background: Yeah, it looks like the Javascript that's responsible for changing the visibility of the radio buttons, as well as the background color of the selected revision, isn't being run on mobile. I'm not sure if there's an easy way to enable this, but I'll look into it.

@Jdlrobson it could. We would just have to pull out the following rule from being history-page specific and place it somewhere more generic.

Just a note on the radio buttons. That effect on iOS is actually due to some overly broad rules in the Minerva reset.less file:

input {
border: 0; 
background: none;
}

At first, I thought the verification was step 6, but I'm not sure based on the Expected and Actual. Please confirm what the validation should be.

@Volker_E I took a look at this approach today, essentially making the text "screen-reader only" when a section is in the collapsed state.
This works pretty well, simply by removing the aria attributes, keeping tabindex=0 on the headings, and using the following CSS to show/hide the sections instead of display: none;

@Jdlrobson I hope that's an issue with my setup and not a change I made, since it appears that way for me on master (images might be cached though) and I don't think I touched any code that would change that icon.

I think those two patches fix this nicely :)

Just out of curiosity, recent MacOS versions have added dark-mode as an OS level feature, and a new CSS media query has been devised to response to that setting: prefers-color-scheme. The spec is only a draft at this point, but it's already been implemented in Safari and Firefox on MacOS. It would be pretty cool if our solution responded to that OS-level setting, so I'm just wondering if that's been considered.

When we estimates this bug yesterday I think our understand may have been incomplete. Reading over the comments in T218154, it appears that this might not be an issue with the focus state being invisible: As @Volker_E wrote:

Thanks to @zeljkofilipin 's work today we got a daily job running the Mobile Frontend tests on the beta cluster today. Hurray!
However, I still want to edit/write/find a MobileFrontend test that works properly on the beta cluster so that this job doesn't just fail every day.