User Details
- User Since
- Nov 20 2020, 1:35 PM (89 w, 5 d)
- Availability
- Available
- LDAP User
- Vadim Kovalenko
- MediaWiki User
- Unknown
Yesterday
@Tacsipacsi , thank you for the extra info!
What does your patch affect? It’s in a repo named mobileapps, while the original report was about Page Previews, a desktop browser feature.
Page Previews extension relies on the response of the /summary endpoint which is handled inside mobileapps service.
Mon, Aug 8
I've uploaded the patch to resolve flagged revisions (only for the German wiki for now). Useful links:
Tue, Jul 26
Wed, Jul 20
Tue, Jul 19
Hi @Theklan ! Could you provide an example of the issue? Seems that articles with galleries are converted fine at the moment.
@Aklapper, this has been fixed. Could you recheck?
Mon, Jul 18
Fri, Jul 15
I reverted these changes here
Revised issue from the description using Xcode for multiple iPads (see the shots), was unable to reproduce overflow of the parent element.
iPad Pro (12.9 inch)
iPad Pro (11 inch)
iPad Pro (9.7 inch)
Thu, Jul 14
Yes, it's the same issue. For some reason, arbitrary sections nested into the previous section. Set this task in progress.
For some reason, the horizontal scroll disappears and works fine after scrolling down the article.
Hi @Tsevener ! Do you mean this bug?
I reproduced it on both Android and iOS mobile phones.
Wed, Jul 13
This issue happened because the template utilizes .plainlinks a { padding: 0 !important } rule from base.css. I explicitly set !important for paddings of the touch target links.
@MSantos , @Jgiannelos
Tue, Jul 12
Jul 11 2022
Jul 1 2022
Considering Flagged Revision description (link - https://en.wikipedia.org/wiki/Wikipedia:Flagged_revisions) not all wikis use it.
For those wikis, that have FlaggedRevs, related API helps to retrieve more information for current and stable revisions. Example for German wiki:
https://de.wikipedia.org/w/api.php?action=query&prop=info|flagged&titles=sandbox
Jun 29 2022
Hi @cooltey . Please, take a look at the screenshot:
The very first section has different CSS rules for the edit button compared to the next and upcoming sections. Reasons for that are unknown, but I'd like to make these sections consistent somehow. Maybe it is a good idea to create a dedicated container that will store all possible icons and then attach this container to sections and the header. This will help to prevent glitches while button toggling. But the caveat is if the button container will have a width more than width of 2 buttons and we decide to add 3rd button later, text on the left side will have more line breaks.
Not sure if we can override messages directly in mobileapps/i18n since the Translation updater bot does this automatically. @MSantos, what do you think?
Jun 28 2022
@MSantos , @Jgiannelos pls take a look at this patch:
https://gerrit.wikimedia.org/r/c/mediawiki/services/mobileapps/+/805336
Jun 22 2022
Jun 17 2022
Hi @Nikerabbit , thank you for the additional info about the banana-i18n library. I will provide more details. Please, install banana-i18n in isolated environment and check this code snippet for zh-hant:
const Banana = require('banana-i18n') const banana = new Banana('lzh')
Jun 14 2022
Hi @cooltey ! I suspect that happens when you try to set the talk page icon before all other HTML has been rendered. In the current implementation, this button is configured inside the onBodyEnd() function here and this is expected because we need the header to render first to append the icon to it. I have a few questions that might help me to reduce the scope of the problem:
- Do all articles throw an error when you try to set talkPageButton: true or the only these two mentioned in your comment?
- Do you try to set it before HTML has been loaded? In that case, it won't work.
- Maybe you could explain how you wire the button in the app itself so I can also be able to reproduce this issue?
Jun 10 2022
I've implemented View edit history functionality and added i18n tests for Arabic. As for zh languages, they won't work properly till zh-hans and zh-hant (along with some others) be introduced in the banana-i18n package (full list of supported languages here). @Nikerabbit , what do you think? You've mentioned zh and mk languages in https://phabricator.wikimedia.org/T249541#7569365 but mobileapps has 134 predefined language variants compared with banana-i18n which has only ~12 corresponding langs and some fallbacks.
Jun 8 2022
Thank you @cscott, I've added a fix for parsing the legacy HTML output and set the patch to the code review.
Jun 7 2022
The patch above is intended to test a possible solution. Seems that Parsoid propagates already encoded id values and I'm able to decode them on mobile apps (only for zh wiki). Parsoid output - https://zh.wikipedia.org/api/rest_v1/page/html/%E5%BC%80%E5%B9%B3%E5%B8%82/71986109 (see the shot as well).
This problem can be fixed by adding the background-color: initial rule to the pie chart divs which represent sectors.
Jun 6 2022
Jun 3 2022
This might be an issue on the Anroid devices only. I reproduced this issue with these steps:
- Check the explore feed on the Android app. Feature feed triggers this endpoint - https://en.wikipedia.org/api/rest_v1/feed/featured/2022/04/08 where onthisday property contains the page that we need to view when clicking to More on this day →link.
- Click More on this day →. From this point, I suspect that Android app invokes https://en.wikipedia.org/api/rest_v1/feed/onthisday/events/4/8 instead of https://en.wikipedia.org/api/rest_v1/feed/onthisday/selected/4/8 ( If you check selected API, you'll be able to find The Knights Hospitaller … Mamluk sultan Baibars. which was mentioned in the description )
Jun 2 2022
Jun 1 2022
May 31 2022
May 30 2022
A similar issue was mentioned here: T249541. After additional research, I've found that View edit history functionality had not been implemented at all. Check PCS here - https://github.com/wikimedia/mobileapps/blob/master/pagelib/src/pcs/c1/DemoMode.js#L23. The value of editedDaysAgo is hardcoded and was intended to be replaced by upcoming (?) functionality. I checked example of the summary endpoint of one of the article, but it seems that there is no explicit property editedDaysAgo there. However, I can calculate it inside PCS using the timestamp property and then render it on the footer.
@MSantos, @Jgiannelos , what do you think?
After additional research and testing, I've found that attempting to add body.pcs-platform-ios didn't make any changes. But instead, font overriding applied for wikipedia-ios.
Here is a screenshot that compares wikipedia-ios updated font | current font (which is actual now) | mobileapps updated font via body.pcs-platform-ios class:
May 27 2022
I will try to test both variants. I already have some results with overridden styleoverrides.css but will test with PSC as well.
May 25 2022
These cc rules affect the output of mobile devices. I disabled them to quickly check if it helps.
I could try to reset them in mobile apps considering it works fine on the mobile version of the wiki. @MattCleinman , what do you think?
May 24 2022
@MattCleinman CSS rules came from load.php for parsoid output and from https://ar.wikipedia.org/api/rest_v1/data/css/mobile/site for mobileapps ( even for local instance ). Check the shot:
site.css depends on ResourceLoader. Because it provides styles for the entire body, I’m unable to override it with different font only for iOS ( if at least I can apply something like body.pcs-platform-ios {font-family: -apple-system !important;} ). Maybe it is possible to override that font directly in wikipedia-ios?
May 20 2022
May 19 2022
May 18 2022
Styles of the template Autres_projets break layout in this particular article. I suggest refactoring template styles or re-editing the article. I've checked other articles with this template on mobile-html (see the list of them here - https://fr.wikipedia.org/wiki/Sp%C3%A9cial:Pages_li%C3%A9es/Mod%C3%A8le:Autres_projets). Though most of them don't look quite well on mobile viewport, no similar issues have been found.
May 12 2022
Created first MR here - https://gitlab.wikimedia.org/jgiannelos/mobileapps-a11y-tests/-/merge_requests/1
May 11 2022
@Jgiannelos It should be closed because PR has been merged.
May 10 2022
Fixed regression caused by patch for May 5. Pls, check the updated one.
cc: @MSantos , @Jgiannelos
May 9 2022
Hi @cooltey . Sure, I'll take a look.
May 2 2022
Hi @Tsevener ! I've restored previous functionality and kept fixes from the T294899 at the same time. The issue was in the in sGalleryImage method which was intended to parse all images instead of only nested in the unordered list with typeof = mw:Extension/gallery attribute. Pls, check.
cc: @Jgiannelos
@Kelson I've just asked a question about this in the template discussion thread. I'll keep you posted if get any updates.
@Titore Thank you for your attention to this problem. I will take into consideration your case while working on the patch which is currently in progress.
Apr 29 2022
Related repo with analytics functionality - https://github.com/VadimKovalenkoSNF/wmf-theme-issues-analytics
cc: @Jgiannelos
Apr 25 2022
Hi @Tsevener ! I was unable to reproduce the issue on my Android device (see the version on the shot). Could you please provide some more screenshots or videos of the current gallery behavior?
Apr 19 2022
@Brycehughes cases with Barcelona and Tokyo also have been fixed in the patch above, I've just checked them. Once this patch goes to the beta cluster it will be more convenient to test other cases where this issue might happen.
Apr 15 2022
@Brycehughes could you specify which exactly article did you test? I suspect that this might be a cache issue but not sure. I also found another article with exactly the same problem ( go to https://en.wikivoyage.org/wiki/Auschwitz-Birkenau, hover Oświęcim), so I put additional fixes in the follow-up patch above.
cc: @Arlolra , @MSantos
Apr 13 2022
Apr 8 2022
@MattCleinman Patch above is ready for review.
cc: @MSantos , @Jgiannelos
No, it isn't. I'm closing it.
Apr 6 2022
Mar 28 2022
Mar 22 2022
This issue happens because /summary endpoint receives wrong extract and extract_html properties. Similar problem has been resolved in this task: https://phabricator.wikimedia.org/T295255
However, this particular case happens because mobileapps removes necessary data from the tag attribute.
Here is the problem part of the Parsoid output that is received by processing module (lib/processing.js):