I debug Contact extension locally, and noticed that user's IP address is added to the email message title.
Here is the logic for adding IP address (link):

I set the patch to the review with the possible solution + tested this in XCode as well. Articles to test:

This ticket is blocked till we decide about ResourceLoader applying in mobileapps. Current patch provides two solutions that are not optimal.

I updated the language codes listed in lib/wikiLanguageMapping.json. As a guideline, I used ISO 15924 and ISO_3166-1.

In addition, I would recommend refactoring template inline styles, for example, moving them into ‎<templatestyles> (docs) . It will make their modification in PCS easier.

@Jgiannelos , @cscott considering https://phabricator.wikimedia.org/T117845#8576044 - does this make a blocker for me to replace sr-el / sr-cr variant codes to sr-Latn / sr-Cyrl in mobileapps service?

@matthiasmullie , it was a pleasure to collaborate with you, thanks for the assistance!

@thcipriani Hi! Pls, remove +2 rights to the SearchVue for me, since I'm not going to be a part of the project owners due to the end of my contract soon.

As I mentioned in https://phabricator.wikimedia.org/T271534#8629524, there are inline template styles that could not be overridden in PCS due to the arbitrary DOM structure of the tweet template. This might lead to the tight coupling between PCS and this template.

Upd: the reason that the first diagram in the example above is not broken on a dark theme, is probably because div tags don't have a text node inside. This might be helpful in terms of solving the issue.

There are a bunch of div elements that should have notheme class to avoid this issue on dark theme: https://de.wikipedia.org/api/rest_v1/page/mobile-html/Vorlage:Sitzverteilung?theme=dark. I'd rather apply a specific class to the template element itself and then recursively add notheme in mobile html then.

I don't think this can be fixed in PCS only by changing CSS rules and without breaking the layout. Changing z-index won't help: <sup> element isn't a positioned element. The problem was probably caused by setting the solid background to the <sup> element on the app (iOS/Android) level. I can suggest mitigating this issue by changing opacity from solid to ~30%, so the text on the left side will be visible. Here is a small standalone example:

Closed this as resolved since this issue has been fixed and fixes are currently on prod. If there are any related problems, feel free to file a new ticket for them.

@Aklapper I was about to close it as resolved but need product and web agreements first. There should be a decision about the definition of what exactly should be excluded inside parentheses.

We are going to close this task but it is blocked by https://phabricator.wikimedia.org/T91344 which is still open.

@cscott , I've tried to open the page with .js at the end of URL on the local mobileapss instance (http://localhost:8888/en.wikipedia.org/v1/page/mobile-html/User%3ACscott%2FTogetherJS.js), but got Dummy output. Parsoid does not support content model javascript. See T324711. error message. Any chances to get this page locally?

@Tsevener I've checked and realized that tweet template has a bunch of inline styles which leads to using anti-patterns in mobileapps to override them. I'd rather leave it as is till we come up with a solution for dark theme issues across Web and app wikis.

Seems that this hasn't been deployed to prod yet, local instance works for me, pls check: http://localhost:8888/en.wikipedia.org/v1/page/summary/Brandy_(You're_a_Fine_Girl)

@Tsevener a lot of lead paragraphs have some text in parentheses which is truncated. You can check my comment here for more details: https://phabricator.wikimedia.org/T259891#8542852. In your particular case, there is a ref inside parentheses that isn't filtered by regexp implemented in this patch. My solution tends to work only with italic letters. There are tons of possible cases where parentheses with the content should be kept for the preview, let's discuss.

@Asartea , could you provide a link to the protected user script page? This page, for example, is not protected and can be editable by any user both from the mobile app and a desktop.

Image attributes removal for mobile-sections has been introduced here - link.
Should we rollback the line with img: ['about', 'alt', 'resource'] to enable the alt attribute for images in mobile-section response?

Though mobileapps doesn't handle any implicit information that comes from templates, I decided to implement PoC patch which solves the problem, but in another hand adds an additional layer of complexity for the transformation module. The only information that we can manipulate here is the Parsoid HTML. For articles without short description explicitly set by wikitext it has <span> element with data-mw attribute. At the same time, this node is empty which is the signal for MobileHTML to strip it, so I've applied extra method to check whether this span was created by {{Short description|none}} wikitext and then passed this info downstream to create a mobile header. Please, let me know what you think of the approach I used in the patch.
cc: @MSantos , @Jgiannelos

(Almost ) all data inside parentheses is truncated now for the summary response, so this issue is no longer valid. Source code here.

I looked around a bit and have a question: Why does this code exist? @Dbrant do you know why?

The reason for this has been described in this ticket: https://phabricator.wikimedia.org/T282295 and the related patch. The problem was that some infobox table elements inherited the default white font color from the infobox when using black/dark mode.

This bug usually happens with articles that have music album/song name in the lead paragraph. I found a few more examples of the bug:

I looked at the Parsoid html and math element - the problem is with a little bit less height of the formula image. Looks like it can be fixed in Mathoid.

The problem is that Parsoid doesn't wrap the Reference list into the section. This happens for all pt wiki articles. Here are some examples of them:

• https://pt.wikipedia.org/api/rest_v1/page/html/Gina_Lollobrigida
• https://pt.wikipedia.org/api/rest_v1/page/html/Sebastian_Vettel
• https://pt.wikipedia.org/api/rest_v1/page/html/Mark_Webber

Red links transform into plain text in mobileapps, check the code here. This functionality has been implemented 3 years ago in this commit, so probably, handling red links can be reconsidered now.

The issue came from Шаблон:Комик which is the template related to ru wiki. Check this page and hover, for instance, Галкин, Максим Александрович. Popup window exposes summary response to prepare the otput: there are unnecessary \n (check стендап-комик\n\n in extract property) that transformed from empty span elems. I'd rather fix the template itself in this case because mobileapps are not meant to handle all possible issues that come from different language templates.
cc: @MSantos , @Jgiannelos

The patch above applies color inversion for img.mwe-math-fallback-image-display elements.

Here is the list of common transformations in the mobileapps:

@CBogen the patch above solves this problem - if no thumbnail for the title from the search list, then QuickView just will be without it on any wiki. The language of the wiki doesn't matter in this case.