PR: https://github.com/wikimedia/wikipedia-ios/pull/4267

My initial hunch was wrong: shouldShowExploreScreenOnLaunch didn't consider whether the user wanted to always launch into the search tab - so it was opening to Search, then switching to Settings.

Turns out there was something stopping Android from syncing, even when manually triggering a sync. He logged out on Android, uninstalled the Android app, reinstalled it and relogged in, and everything synced as expected.

From a quick check, this seems okay - nothing to update.

This starts on June 30th (today), so we should expedite this work: https://developer.apple.com/news/?id=12m75xbj

@vadim-kovalenko - Hold off on this one for now. Sorry, I just found out that the design on this may change. We'll let you know when we're confident how we'd like to move forward with this.

I looked into this, and it seems like some race condition with the last few lines of WMFAppViewController's configureTabController:

if (shouldOpenAppOnSearchTab && self.selectedIndex != WMFAppTabTypeSearch) {
    [self setSelectedIndex:WMFAppTabTypeSearch];
    [[self searchViewController] makeSearchBarBecomeFirstResponder];
} else if (self.selectedIndex != WMFAppTabTypeMain) {
    [self setSelectedIndex:WMFAppTabTypeMain];
}

PR: https://github.com/wikimedia/wikipedia-ios/pull/4263

Bug also exists when adding via share sheet in explore feed.

On Firefox Desktop, if you typed in a URL that is open in another tab, one of the autocomplete options is "Switch to Tab". We could do a similar treatment - if an article is open in another tab, we could offer "open", "open in new tab", and "jump to existing tab" (that should be worded better).

Another report: https://ticket.wikimedia.org/otrs/index.pl?Action=AgentTicketZoom;TicketID=12238543

Another report: https://ticket.wikimedia.org/otrs/index.pl?Action=AgentTicketZoom;TicketID=12236477

Another report: https://ticket.wikimedia.org/otrs/index.pl?Action=AgentTicketZoom;TicketID=12235893

Another report: https://ticket.wikimedia.org/otrs/index.pl?Action=AgentTicketZoom;TicketID=12232218

Two other reports in Znuny

Request via email: "Too bad you can't set anywhere that you want to clear the search history when closing the app. "

Looks like this has been fixed. Thanks so much!

PR: https://github.com/wikimedia/wikipedia-ios/pull/4232

Thanks for your thoughts on this.

This is due to a bug in PCS. It is considering the page name AIDS (instead of the accurate HIV/AIDS, and so isCitation is incorrectly returning false. This is due to ClickedItem constructor being given an incorrect pageTitle, as it assumes slashes are never in page titles (around line 289 of InteractionHandling.js).

No giant rush, but do you know when this will be deployed?

I spoke to @Dbrant yesterday, and the Android architecture for this departs from iOS. Android uses what the API gives it in each appropriate spot:

• Explore feed: When loading the Explore feed, it calls the featured (https://en.wikipedia.org/api/rest_v1/feed/featured/2022/04/08) endpoint. Unlike iOS, it uses the contents of the onthisday object to provide data for the On This Day card in the explore feed.
• On This Day detail view: When tapping the card and entering this view, the Android app hits the onthisday endpoint (https://en.wikipedia.org/api/rest_v1/feed/onthisday/events/4/8), and shows the results in the feed.

This is fixed in the current beta - if we get additional reports of this, we can explain that we expect to have it fixed in the main app store version soon, and we should share the instructions for joining the beta.

Added this to board as an engineering thing that had been bugging me, during our post-release week.

PR: https://github.com/wikimedia/wikipedia-ios/pull/4246

Thanks for this. It fixes the problem and tests great, thank you.

For simplicity, we're going to go with a top half of the screen, but instead of green text we say something like "The first edit of [article name]".

I think I'd rather fix this on wiki or PCS than with a hack the iOS codebase. (In part because the fix will get out their even quicker.)

The version that mobile apps use is available here: https://fr.wikipedia.org/api/rest_v1/page/mobile-html/%C3%89ph%C3%A9m%C3%A8re

That sounds good to me @vadim-kovalenko , thanks!

@scblr I'm not sure I understand how this would help this situation - doesn't that link compare two versions, and this situation is talking about when there is only one version of the page?

This layout bug in the image above is replicable in a web browser if you make the width of the window fairly small: https://fr.wikipedia.org/api/rest_v1/page/mobile-html/%C3%89ph%C3%A9m%C3%A8re

@vadim-kovalenko Thanks for your work on this. I want to make sure you saw the comment directly above this - this probably should move from the sign off column, to handle that tweak that is needed. Thank you!

Two questions to answer for the spike:

1. Can we filter our search API requests to certain domains, or would we do the filtering locally?
2. Can we do the UI of the bar at the bottom of search?

Removing myself as assignee, as this is out of app's expertise.

It's possible there could be a quick fix using .pcs-platform-ios somewhere. But overall, we need to make sure the Ariel font-family isn't what is being used in the body. There may be an on-wiki fix, but I'm not quite sure how this Arabic wiki specific css feeds into PCS.

monospaced text

PR: https://github.com/wikimedia/wikipedia-ios/pull/4226

PR up shortly. For posterity, the problem:
When a user was in our app, selected a word/phrase, then tapped "Look Up" (and entered the iOS overlay), then tapped the "Siri Knowledge" cell (if available), then tapped "Wikipedia": iOS's overlay would open the link in the app, but currentNavigationController would present the new article VC on the iOS Look Up VC, not the original article VC (as expected). Since the iOS Look Up VC would deinit nearly immediately, the new article would close after a split second.

It's from the CSS font-family: Arial found in site.css, in the first part of the file:

html, body, #content h1, #content h2, #content #firstHeading, .mw-body .mw-editsection, .mw-body .mw-editsection-like, .ui-widget, .mw-body #toc h2, .mw-body .toc h2, .flow-topic-title, h2.flow-board-header-title, .mw-collapsible-toggle, .mw-collapsible-toggle > a, .CategoryTreeToggle, .CategoryTreeEmptyBullet, .NavToggle {
    font-family:Arial
}

Remove this, problem goes away.

It seems like this is because we take our tabViewController's presentedViewController. Unfortunately, in this situation it's the spotlight VC, and it has no relationship to our app's VCs, so we can't start with it and work our way to the expected VC. I think the only way to do this is to work our way up from the tabVC. This gets a tiny bit tricky, as VCs and NavControllers may be pushed or presented on any variety of VCs, so we need to carefully traverse our way up the stack.

In WMFAppViewController, it presents the VC in (WMFArticleViewController *)showArticleWithURL:(NSURL *)articleURL animated:(BOOL)animated completion:(nonnull dispatch_block_t)completion

I can replicate while only messing with text size on the article for Crosswords.
I can see a couple characters change when the text size increases and a word gets kicked to the next line.
Arabic letters have different forms depending on where it is in the word. And a letter moves from the middle-position form to the final-position form as the text size increases and the word moves to another line. Which obviously shouldn’t happen.
It doesn’t happen to this word on web.
Also happens on 15.4.1, but not 15.3 or 14.7
On 15.4.1, It does not happen on the output of PCS loaded in Safari on iOS (https://ar.wikipedia.org/api/rest_v1/page/mobile-html/%D9%83%D9%84%D9%85%D8%A7%D8%AA_%D9%85%D8%AA%D9%82%D8%A7%D8%B7%D8%B9%D8%A9). This seems very app specific.

Possibilities of source of issue, and some thoughts

• iOS changed font
  • Looks identical on Windows and macOS and IOS
  • Looks identical on multiple versions of iOS
• Our app changed something
  • Report came when we were still on 6.8.2 - nothing had changed in months
• Somewhere on Wikipedia servers changed font
  • Android isn’t seeing similar complaints (though there could be something Android-specific that means a PCS change isn’t being seen on Android)
  • No reports of issues elsewhere

@alaa we're trying to track this down, and are having some trouble. Apologies for my ignorance, but can you help confirm the problem with these screenshots? My understanding of Arabic is that the same letter may be written different depending on whether it is at the start of the word, in the middle, or at the end. Is this the issue that we're having? Or is it something different?

@JMinor and @JTannerWMF are okay with natural cache replacement. The bug exists only in cached articles. As articles get edited, the cache will get updated. (There is no automatic refresh of this cache, it turns out.) It looks like about 6k articles per month are edited, and this bug cropped up in January/February of this year…. which means given that the fix was deployed 2 weeks ago, it will (mostly) naturally take care of itself in the next few months. (And if we get complaints on specific articles, we can run open the URL with ?action=purge to immediately invalidate.)

It seems like the problem has been fixed, but old (and broken) versions exist in the cache. This is now article-specific, and the cache will naturally be updated when each article gets updated. I'd like to look into invalidating the cache in a more complete fashion, so let's keep this open for now.

This works on both web (https://en.wikipedia.org/api/rest_v1/page/mobile-html/Metapuzzle, then in console run pcs.c1.Page.setEditButtons(false)) and on iOS in app.

Another report: https://ticket.wikimedia.org/otrs/index.pl?Action=AgentTicketZoom;TicketID=12173516

Happy to help with this however we can. So you know, this APNs key rotation isn't something we anticipate happening frequently, so we may not want to over-engineer an automated check for it. There is no expiry of the key. In this case, we wanted to rotate the key we had been using for dev before it goes to production, but from here out we don't expect to update it even once per year.

PR: https://github.com/wikimedia/wikipedia-ios/pull/4198

Despite repro'ing this several times before I filed this, I can't repro it anymore. Closing.

If not easy to give contextual dates ("3 months ago"), better to just give absolute dates ("Dec 20 2022") in Chinese.

iOS also doesn't use them or plan to. Seems like they're safe to remove, at least from the standpoint of mobile apps.

Adding @Dbrant - Do you know the history of these? (These pre-date my and Jazmin's time on the team, but thinking Dmitry may know off the top of his head.)

@Dzahn I don't believe I have access to production servers - is that what you mean by deployment ones?

Content showing up in Featured feed should also be in OnThisDay feed.