the browser support for these features is practically universal.

I guess, in theory... http://timpietrusky.com/advanced-checkbox-hack

@alexhollender
bugs: 1, 2, 3 & "Display issues with log entries T229360#5394174"
enhancements: 1, 3, 5
are live on beta.

In terms of browser support, the mechanism employed in the overflow menu & user menu is called the checkbox hack.
It was pioneered in 2010 and it depends on a few CCS level 3 features:

@Jdlrobson I didn't realize the work here should be split off into separate tasks, so I attached the last patch to this task instead (it's small though). The patch I submitted above https://gerrit.wikimedia.org/r/528438 addresses refinements 1, 3, 5.

So far:
Bugs:
1 Page should not scroll horizontally
3 When tapping Hide the entire filter box should be hidden.
Are taken care of in this patch:
https://gerrit.wikimedia.org/r/527132

@Edtadros I think @alexhollender pretty much has the QA for this task covered in T229360, so I think I'll reassign this task to him and put it in sign-off.
There has been one bug identified with the list styles in that task, so I think once we take care of that, this task can be signed off.

^ I've attached a followup patch to this ticket. That one enables the loading spinner for the filters like on desktop.

This is because the icon sizes are determined by the font size of the parent.

@Jdlrobson good point. I like breaking tasks down into smaller pieces of work, but that was confusing in this case.
There was a lot of uncertainty around how the dropdown menu in the rcfilters was going to be implemented for mobile, which is why T225499 was created.
This task is meant to account for the remaining rcfilters work, i.e: the layout & the remaining buttons.

I'm not Alex, but I'll give my 2 cents on the positioning.

It might be a browser bug. I see the notification icon in safari, but not in chrome:

@Edtadros description updated. This should be live on the beta cluster :)

wikimedia/portals uses some build step to generate assets which are then deployed as a submodule of operations/mediawiki-config.git.

Yeah – didn't want to break that workflow. @Jdrewniak, are you the expert on this?

Just created T228419 for the styling portion of this task. I think that along with T228280 encompass the work needed for this feature.

Oh, one more thing. The work described above is not blocked on T225499 the advanced filters work for mobile.

After investigating these list views today, I've come to these conclusions:

Not sure what happened here but it looks like around July 4 the error rate dropped back down to normal levels.

yup! thanks @hashar

@alexhollender the latest update takes into account a few more of your concerns.
I removed the blue border around the input when the dropdown is open, and I added an "x" icon on the popup menu so that it's easier to close.
The scrolling behaviour is also modified so that the page scrolls to the top of the search input (most of the time) when the menu is opened.

@alexhollender thanks for the feedback!

It looks like the flakiest test is editor_wikitext_saving.js. The error message in the screenshot "Error: Another user had edited this page" suggests some sort of race condition or async error.

After looking over the test results over the past couple of days, it seems that the test is now failing intermittently :(

I was about to decline this ticket because the bug seems to be an Android Chrome issue, but then I thought "how does the mobile wikipedia site handle this issue?" and I discovered that the mobile site triggers a blur event when a user scrolls down. That way, the browser doesn't scroll back up when something is clicked. The same approach can be applied here.

@ovasileva @alexhollender one other thing this patch does, is enable the rcfilters module on mobile.
This means that instead of seeing the current page, users will get the still-unperfect-but-somewhat-useable version of the advanced filters:

👆Regarding the above patch, it fixes the virtual keyboard issue on the advanced filters form, but it does so in an unconventional way, so I'll explain.
First it uses the OO.ui.isMobile to check if a user is on a mobile device. I believe that method only returns true if mobileFrontend is used, so using Minerva as a desktop skin isn't affected. If isMobile returns true, a readonly attribute is placed on the search input.

@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.