Kiwix zooms in when switching to other app and back on iPad

[Popolechien]

iPadOS 14.4 and Kiwix for iOS v1.14: when looking at an article and switching to another app (without closing Kiwix), a user reports that coming back to Kiwix the article is fully zoomed in.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be now be reviewed manually. Thank you for your contributions.

[automactic]

The reason this is happening is because when an app goes to background, the system resizes and rotates the app in all different size configs (portrait, landscape, floating, 1/3 width, etc) and take screenshot of the app.

There is an upstream webkit issue that result in viewport repositioning and zoomed when rotate. Also see other similar report on apple dev forum and stack overflow. You can kinda reproduce this by rotating the device without putting the app into background, although it is not always consistently reproducible.

I also did not find a really good hack. The only thing that would be a reliable mitigation is to add a disable zoom/page scale setting with it disabled by default. It will be implemented with a meta tag that set viewport initial-scale=1.0, maximum-scale=1.0, user-scalable=no. Or we can decide not to do anything because the issue is not on our side.

@kelson42 what do you think?

[kelson42]

Seems to be an upstream bug, i have tagged this ticket accordingly.

[automactic]

@kelson42 So what's your opinion? Should we add a disable zoom toggle? Or do you suggest to do nothing?

[kelson42]

I would do nothing for the moment, and hope the bug will be fixed upstream.

[automactic]

It likely won't get fixed any time soon. At the minimum a year till the next major iOS/iPadOS release. But considering the webkit bug I linked was reported in 2019 Dec, it might not even get addressed in the next year

[kelson42]

C'est la vie... we have to live with this. This is not the only upstream project at the root of bugs in Kiwix. We just need to keep track of them as they impact the users.

[automactic]

Can we move issues like this to the GitHub discussion tab or wiki tab as known issues? I personally would like to have the issues tab to be really about issues that needs to be resolved or triaged.

It is very noisy and kinda pointless to have a lot of issues without resolution for a very very long time

[kelson42]

Please keep tickets open if something does not work properly for users. Only two reasons can lead to close a ticket: either this is fixed or this will never be fixed "wontfix". I don't want users to create duplicate; actually they do that already even if they can find everything in one place... If we start to close current bugs ticket then this is just going to be even more complicated for everybody.

If you want to have a view on tickets which is easier to manage than the default one, you can make a filter. I strongly recommend to do like in all other repos: do milestones and put in the milestone the tickets you want/plan to fix. The stalebot can as well help you to have a better view on "current" tickets.

[automactic]

@kelson42 "wontfix" does not mean never will be fixed, it means no action will be taken at this moment for whatever reason. And this one is "wontfix" in my books, because there is literally nothing for me to do.

Also I think your logic is flawed. If user already create duplicates, then the existing tickets are not doing a very job in letting user understand our acknowledgement and current status of the issue.

What I am proposing is to changing the process up a bit. Issues should not be a mess of everything we want to do, user think should happen and issues that need to be fixed. All issues should be actionable. If there is an idea, create a discussion in GitHub. If there is something we have triaged and decide there is nothing to be done from our side, move it to a known issue area. I am unhappy with how issue are currently being used, and how there are many issues that is just left there without me being able to do anything. And frankly after working on this project for 5-6 years, I think my voice deserve to be heard

[kelson42]

All issues should be actionable.

No, this is a developer point of view, but actually the list of tickets are not only for devs. Here is the document instructing users how to report a bug https://github.com/kiwix/overview/blob/master/REPORT_BUG.md. If bugs (and here there is a consensus there is one) tickets are not kept open then they can not be found. As a consequence users can keep reopen again and again new tickets for the same buggy behaviour... this is not what we want... and this is why I insisted here and everywhere to keep tickets open for actual bug (even if the root cause is upstream).

But this is clear that considering that this ticket is a "detail" and that this is "your" repository and that you seem to have a strong opinion on this ticket then lets close it. We both have exchanged our respective arguments, which I'm sure are respectively understood. Lets focus now on more important things.

[automactic]

@kelson42 Once again, I am not saying I want to close issues we recognize but cannot fix. What I want to do is to convert them to discussions. I also think stuff like feature requests should be discussions and not issues.

This might be different from how other repo under the org of kiwix or openzim are run, but I do appreciate it that you could give me this atomony.

For this specific issue, my proposal was to implement an option to disable zoom. But you did not want it as per your comment above