Thu, Mar 22
Wed, Mar 21
@hashar that sounds good to me!
anything that helps simplify the Apache config works (I didn't know the rewrite rule was different on deployment-prep)
A change was deployed on Monday that probably broke the Wikipedia portal on beta https://www.wikipedia.beta.wmflabs.org/
Tue, Mar 20
I agree with @Jdlrobson that to get this working, replaceState seems like the appropriate solution.
While looking at this problem though, I noticed that visiting a page with the #/search url, like https://en.m.wikipedia.org/wiki/Barack_Obama#/search doesn't actually trigger the search overlay either. Seems like that should be fixed too?
Mon, Mar 19
btw this is what I mean about different icon sizes with .mw-icon
I think the discrepancy in icon size is due to switching to resourceLoader's image feature for the icons. The icons were switched to used a standardized mw-ui-icon-large icon size, which coincidentally matched the size of the "empty" icon, but made the icons for the disambiguation preview larger than it should be.
should the infinite scroller (and by extension, this special page) also work on desktop?
(it doesn't btw).
not sure when it appeared, but it's there now :)
Fri, Mar 16
Thu, Mar 15
@Jdlrobson yeah the spinner is being generated by PhotoList.js#44, and the infinitescroller is also being enabled/disabled there, so that's where I'm focusing my efforts. I do wonder though, if this behaviour could be moved to the infinitescroller...
Wed, Mar 14
Tue, Mar 13
Thu, Mar 8
Wed, Mar 7
@Jdlrobson a pox on your CSS in JS! I will have no such sorcery! 🧙♂️
@Nirzar not everyone has access to the Zeplin project. Can you make it public or attach the svg to the task?
Mon, Mar 5
Since that the REST endpoint returns "type": "disambiguation" now, it seems like this feature could be implemented by using the approach suggested by @Jhernandez in T186129. In my opinion, I think that makes T186129 a prerequisite for this task. Thoughts?
Your right, from the webdriver.io docs
Feel free to add me to any selenium patches as well 👍
just my opinion, but shouldn't UI elements provide some tap feedback as well? Many times the ui action, like switches on the settings page, are not guaranteed to provide immediate feedback (actions are carried out asynchronously, or might be waiting for a script to load) so giving users assurance that they tapped the thing seems reasonable to me.
Fri, Mar 2
Thu, Mar 1
Yup I can reproduce this on a Mac using just the "command+d" shortcut at the end of a line.
at least it looks good on Windows
Wed, Feb 28
It looks like the popups code defines a maximum height for the popup text to 140px. That height is probably enough for most languages, but I guess not Arabic.
a. could adjust that height, just give it like, 200px or something bigger than it is now.
b. get rid of the max-height and be certain that the text won't cut off, but risk having very long popups.
ok! I'm on a roll here. The selenium tests are working. The portal/deploy repo has been submodule'd into the src repo, there's just a few outstanding config/jenkins things left.
@hashar I've updated this patch that run the portalsBuilder in the deploy repository https://gerrit.wikimedia.org/r/#/c/393252/.
After that, this config patch will have to be updated to point to the new portal/deploy submodule https://gerrit.wikimedia.org/r/#/c/393239/
For future reference, I'm explaining the cause of this error.
Tue, Feb 27
the patch above represents the minimum viable fix. It fixes the bug but the resulting (and intended) behaviour is that the page does a hard refresh automatically, instead of the user having to hit refresh. The new content is not being shown "immediately" after save though. After looking through the code, I think this ideal behaviour can be achieved with some refactoring.
This looks like it's not just an issue on the user namespace. but on article name spaces as well.
Mon, Feb 26
I've tested this change by just changing
Feb 22 2018
Feb 21 2018
The solution here was quite easy, so I went ahead and pointed, claimed, and submitted the patch.
So I just enabled this feature locally and looked at it on the iOS simulator.
I looked at the origins of this change:
and the rationale was just "Otherwise long lines break the viewport".
I'm not sure if the issue is that the Page Previews:
- are too big on small screens
- are "cut off" on small screens
It appears that the decision was made not to show the back-to-top button on iOS because it was misaligned.
I don't think the reasoning behind this decision was justified, the task just mentions that it looked bad.
If the feature functions well on iOS, I think fixing it's appearance would be more desirable than disabling it.
Feb 20 2018
Feb 19 2018
I'd recommend hitting all 298 birds with one stone...
We should use the MediaWiki title normalization library to parse incoming article titles
Feb 16 2018
Ok, Jenkin's is successfully -1 and +2'ing the patches. This patch was +2'd https://gerrit.wikimedia.org/r/#/c/411292/
Feb 15 2018
I've updated http://tools-static.wmflabs.org/www-portal-staging/wikipedia.org/ with the latest changes. @Nirzar since Anthony has already done cross-browser QA on this, if you think the spacing looks good than it should be ready for sign off.
@Jhernandez please do, there is quite a few of them used by the fetch method, so maybe some could be removed.
Feb 14 2018
yeah, must have gotten skewed during code-review, hope this patch looks better