looks like an iOS 13.1 bug, appears to be fixed in iOS 13.2

looking at the arrow color bug, looks like there were some changes to nav bar appearance in iOS 13 - https://developer.apple.com/documentation/uikit/uinavigationbarappearance

thanks for the screenshot @ABorbaWMF! The centered headers seem off too - I added that as a bullet point to the punch list ticket - T237314

@awight thanks for asking! it was already merged, should go out when 6.5 is released: https://github.com/wikimedia/wikipedia-ios/pull/3315

@cmadeo thanks for the review!

Thanks for catching this @Luky001, and thanks for the callout @MarcoAurelio! Pushed a fix: https://github.com/wikimedia/wikipedia-ios/pull/3311

Great, thanks @cmadeo!

@cmadeo Selection flow question

BTW, in looking at the design mock-up currently in the description of that task I note that it does not seem to be using the counts of total actors or of reverted edits since the change in T228783#5439449, while it does seem to want to know the count of "user edits" (meaning non-IP?) and the count of revisions with rev_minor_edit set. The "user edits" could be calculated as total edits - IP edits,[2] but the count of minor edits would need a new endpoint.

It's enough detail for me - one thing I forgot to mention is that the API offers only daily/monthly granularity as of now :(

If we want to use the edit metrics API, max queryable timespan is limited to 1 year (https://wikimedia.org/api/rest_v1/#/Edits%20data/get_metrics_edits_per_page__project___page_title___editor_type___granularity___start___end_)

@Aklapper Victor submitted a pull request with this change here: https://github.com/wikimedia/wikipedia-ios/pull/3291

Thanks for clarifying @eprodromou! Yes, if it makes it easier for you, we can make multiple calls

Are you planning to have one endpoint that combines all the count types? Something like /page/{title}/history/counts that returns all the counts or /page/{title}/history/counts?type=revertededits&type=botedits&type=anonedits that returns selected count types

Same user also suggested that it would be useful to be able to add the Main page to saved articles.

I couldn't find anything about a public API that lets us hook into the undo / redo actions as of iOS 13.1.

I couldn't reproduce this on a device running 12.4.1, here's a gif of what the flow looked like for me -

Per 09/03/2019 sync, it'd be ideal to be able to restore the feed position.

The file appears to be unsigned.

When the language changes in Settings, the app is relaunched and (mostly) restored to its previous state.

The solution to this is related to the modal presentation of Settings (T229489). If we stick with the full screen modal presentation (default < iOS 12), this will be fixed. If we use the new iOS 13 modal presentation (card that can be dismissed), this will require further investigation - the swipes seem to be interfering with each other (dismissal vs font size slider swipe).

The PR that excludes the app from dark mode was merged into the xcode_11 branch (https://github.com/wikimedia/wikipedia-ios/pull/3165).
Some system controls end up being too dark/light when there's a system/app theme mismatch.
The reorderControl caught by @Tsevener is not exposed via a public API so we can't adjust its tint color. Setting a custom editingAccessoryView results in not being able to drag & reorder items.

On iOS, we append 2 special items to TOC - “About this article” (https://github.com/wikimedia/wikipedia-ios/blob/ca4df05eaeab29aaa9c023aa8bb9ce59f5feb39e/Wikipedia/Code/WMFArticleContainerViewController%2BTOC.swift#L124) and "Read more" (https://github.com/wikimedia/wikipedia-ios/blob/ca4df05eaeab29aaa9c023aa8bb9ce59f5feb39e/Wikipedia/Code/WMFArticleContainerViewController%2BTOC.swift#L127).
If the user taps on “About this article“, we scroll them to pagelib_footer_container_menu. For “Read more”, it’s pagelib_footer_container_readmore (https://github.com/wikimedia/wikipedia-ios/blob/ca4df05eaeab29aaa9c023aa8bb9ce59f5feb39e/Wikipedia/Code/WMFArticleContainerViewController%2BTOC.swift#L60).

This is not reproducible on a device (iPhone 7 Plus) running iOS 13 beta 8, only on a simulator.

This is not reproducible on a device (iPhone 7 Plus) running iOS 13 beta 8 (or previous), only on a simulator.

Thanks for all the clarifications @MusikAnimal, it's very helpful! Moving this spike to Blocked & Waiting now so that the iOS team can reassess. Related development work continues in T228783.

Thank you for all the information @Mholloway, that's super helpful!

https://github.com/wikimedia/wikipedia-ios/pull/3203

User added that the problem is occasional and it occurs when editing the references and/or external links sections

If "Open app on Search" is on and I leave the app with a stack of articles pushed from Search, should I have the stack restored or not (assuming it happens before the cutoff date)?

@Eholshouser Thanks for looking into this. I'd expect the "Open app on Search" setting to override state restoration. cc @JMinor

• Sparkline: https://wikimedia.org/api/rest_v1/metrics/edits/per-page/www.en.wikipedia.org/Ching_Shih/all-editor-types/daily/20170404/20190806. Queryable timespan is limited to 1 year. We could assume that the start year is current year - 1 but if a page was created less than 1 year ago, we'll get a 400 response (https://wikimedia.org/api/rest_v1/metrics/edits/per-page/www.test.wikipedia.org/Young_page/all-editor-types/daily/20170806/20190806). We could get page's creation date using https://xtools.wmflabs.org/api/page/articleinfo/en.wikipedia.org/Ching_Shih (created_at).
• Getting total number of edits for page: https://xtools.wmflabs.org/api/page/articleinfo/en.wikipedia.org/Ching_Shih (revisions)
• Getting total number of editors for page: https://xtools.wmflabs.org/api/page/articleinfo/en.wikipedia.org/Ching_Shih (editors)
• Count of minor/ip/bot/reverted edits for page: XTools API doesn’t expose those in the API response for articleinfo, looks like it could be included:
  • Building the response: https://github.com/x-tools/xtools/blob/6d8f265ec0aecf6f3a6909b742cc4cda0d28d94f/src/AppBundle/Controller/ArticleInfoController.php#L238
  • Gettings counts https://github.com/x-tools/xtools/blob/19bcac6775a8302273a4314bbfe1b0e753458255/src/AppBundle/Model/ArticleInfo.php#L485
  • Talk page question: https://www.mediawiki.org/wiki/Topic:V4x15ga6upb875w1
    • It's possible to add an option to get the number of minor & IP edits. Getting the number of reverted edits would be too slow for an API endpoint (it's an approximate figure anyway).
• Total number of edits for user: https://xtools.wmflabs.org/api/user/simple_editcount/en.wikipedia/Badylek (live_edit_count). API docs state that To ensure performance and stability, most endpoints related to users will return an error if the user has made an exceptionally high number of edits. (https://xtools.readthedocs.io/en/stable/api/index.htm)
• Sending thanks:
  • api.php?action=thank&rev=16543&token=%2B\, https://www.mediawiki.org/wiki/Extension:Thanks#API_Documentation
  • Python example: https://gist.github.com/notconfusing/460d6ffb6682439ebe6b70b78e7759af#file-flask_thank_app-py-L60

It looks like the endpoint we're using to get languages for articles in the main namespace doesn't return languages for user talk pages.