This is a result of the iOS app not having switched to the new description API which was just completed. We will be adressing this in the next release: https://phabricator.wikimedia.org/T257867

While I understand this is frustrating, Unbreak Now signals the teams that they must drop all other work to solve this issue. This level is for things like "I can't reach wikipedia" or "the app crashes every time I run a search" that effect many users and require an immediate response.

Potentially an issue with iOS 14's new "preferred email client" setting? We just ask the OS to open a draft mail, and may not have control of what happens after that.

@cmadeo might need a bit more specifics for some. Feel free to do as a "realtime" pixel push with an engineer if easier.

I haven't looked at the detailed analysis, but I expect this should be fine/an improvement, so consider me signed off. Ill let app folks know so we can keep an eye on user feedback for any "spam" popping up on top read lists.

Nope, this just got left open through process stuff, follow-up tickets work best for us too.

Yes, I think everyone who requested to be added to the allow list has been added. There were a couple questions on the mailing list related to OSM chapters usage. I have reached out to those folks a couple times, but received no answer. So, I think we are clear to merge the change, as is.

malformed image loading problems tracked in T263691

Did we ever hear back or figure out the deal with greyscale? Should we file a follow up ticket so we don't forget this issue exists?

rtl wtf

Da!

Seems like this was an OS issue or was resolved by resolving other issues (like the crashes) so I'm going to invalidate this.

We are publishing v6.7.2 (1780) of the app as I write, which has our initial smear. Users tend to update over a few days, although the weekends tend to be the prime app update time, so we may get quick uptake. At any rate the client side remediation should be noticeable by Monday and conintue to improve over the week. If we're not seeing that, or the remediation isn't sufficient, just let us know and we'll iterate.

There isn't anything in the log specific to this and we don't call that domain (thats for mix panel analytics which we don't use). Closing this as I think this is purely user confusion and connection issues.

We're currently swallowing the first link and bringing them to our On This Day view. Should we also swallow links of the second variety? (That page allows editing and such - which our On This Day view does not do.)

No, as you noted, for specific days its probably best to put them into an editable page that looks "normal" when coming from a wiki. I do want to keep "today" pointing to our version.

Thought this was just a broken link, turns out it is an app specific issue. Not sure why this page won't load, but likely due to some kind of namespace issue or filter. Even if we can't open in the app article views, these links should open in the in app browser, as these are pages on our domain(s).