Implement „Find in page“

[Popolechien]

"Search in Android not only finds pages, but matching terms within a page as well. Very helpful in longer articles."
(copied from beta tester feedback)

[stale]

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.

[kelson42]

@automactic Please keep one ticket per issue. If you want to gather tickets together you have many systems, like tags, milestones, projects.

[automactic]

I disagree. If you want to keep issue count down or wish to keep issues from becoming stale, the content of the tickets needs to be small and actionable items. IMO, we need to decide what can and should appear in the issue section of the project.

If you want to keep feature request in the issue section, this is fine by me. But please also don't expect me to be able to quickly resolve issues that needs significant engineering efforts and planning. (i.e. expect issues to go stale)

[stale]

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.

[kelson42]

@automactic I for sure don't want to keep artificially ticket count down and avoid stalled. Tickets should reflect the reality. This is mandatory to understand the status of the project and I do my best to secure a high quality ticket portfolio. Here are the guidelines to report bugs https://github.com/kiwix/overview/blob/master/REPORT_BUG.md, please let me know if something is unclear.

The only solution to keep ticket low and not stalled is to fix issues. Any other way is wrong.

[stale]

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.

[stale]

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.

[nk9]

It looks like this is the single issue being used for both iOS and Mac. Will the UI for this really be the same between the two? For example, one of the duped issues asked for Cmd+F to open this. That affordance makes sense on Mac but not iOS. I appreciate that the code base is the same for both but I'm wondering if it wouldn't be clearer to separate the issues by platform to account for differences like this. I suppose there could be a third bug for common code, but that feels like overkill.

Either way, we need to define how this UI will work on both platforms so that it can be implemented.

I am happy to lend a hand on this issue. I am new to the project, however. Is this a straightforward first issue for someone with a bit of Swift experience?

[kelson42]

@nk9 Both versions, macOS and iOS use now the same code base. Obviously, the keyboard shortcuts are not available on iOS. Regarding the implementation, such a feature has to use the HTML render builtin for the core of the feature. Regarding the UI, it's true that the situation is quite open but I woukd try to do like in Web browsers. How this has been solved in Safari/Chrome/Firefox?

[nk9]

We're using a WKWebView, so it should be as easy as invoking the web view's find method.

I've downloaded the source, will give it a shot and see if I can make a PR. If someone else wants to do it first, be my guest!

[kelson42]

@nk9 Have you been able to make progresses? Meanwhile we have published the xcf and updated the README. It should be very easy to step-in now. This is a very important feature. Getting it done would be a nice milestone!

[VitoVan]

This feature is the one I'm currently craving.

🙏 🙏 🙏

I wish I knew some Swift and macOS programming.

[kelson42]

@VitoVan This is scheduled for next release :)

[kelson42]

@BPerlakiH How complex would it be to implement this feature?

[BPerlakiH]

@kelson42 @Popolechien Please see my PR and videos on this here: #849

[kelson42]

Feature seems unavailable if I open a content from "open new tab", see