Fri, Aug 16
Tue, Aug 13
Fri, Aug 9
Thu, Aug 8
Wed, Aug 7
the browser support for these features is practically universal.
I guess, in theory... http://timpietrusky.com/advanced-checkbox-hack
Tue, Aug 6
@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.
Mon, Aug 5
1 Page should not scroll horizontally
3 When tapping Hide the entire filter box should be hidden.
Are taken care of in this patch:
@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.
Thu, Aug 1
^ I've attached a followup patch to this ticket. That one enables the loading spinner for the filters like on desktop.
Wed, Jul 31
This is because the icon sizes are determined by the font size of the parent.
Tue, Jul 30
@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.
Mon, Jul 29
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:
Thu, Jul 25
@Edtadros description updated. This should be live on the beta cluster :)
Wed, Jul 24
Tue, Jul 23
Mon, Jul 22
Jul 18 2019
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?
Jul 17 2019
Jul 16 2019
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:
Jul 15 2019
Jul 11 2019
Not sure what happened here but it looks like around July 4 the error rate dropped back down to normal levels.
Jul 8 2019
yup! thanks @hashar
Jun 27 2019
Jun 19 2019
@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.
Jun 18 2019
@alexhollender thanks for the feedback!
Jun 17 2019
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.
Jun 14 2019
Jun 13 2019
@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.
Jun 12 2019
Jun 11 2019
- Make the filter dropdown work on mobile
- 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 :)
Jun 10 2019
When looking at this task, it occurred to me that a lot of the features work to an acceptable degree on mobile (IMO).
Jun 6 2019
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.