Offer: two small mobile UX changes from our fork (1 issue / 2 PRs?)

[kohki-shikata]

What problem would this solve?

Hi maintainers — thank you for Gitea.

We maintain a small fork for better mobile use, and recently landed two independent changes there for our own needs. They seem generally useful, so I wanted to ask whether you would like them upstreamed. If not, that is completely fine — please just close this issue.

1. Fix: Mobile Safari input focus zoom

Mobile Safari zooms focused form controls when the computed font-size is below 16px. We raise shared form controls to 16px under the existing mobile breakpoint, without disabling viewport zoom.

• Commit: b4moss@21fe9c6

2. Enhance: make site-manifest.json installable (minimal PWA)

Gitea already serves a site manifest, but Chromium installability is weak without display / icon sizing. We add display: "standalone", theme_color, and a 192×192 PNG icon so the site can be installed without a Service Worker.

Out of scope on purpose: offline support, and we are not proposing to bring back a caching Service Worker.

We are aware that the Gitea team previously stepped away from a fuller PWA direction (including removing the Service Worker). We do not claim to know whether this minimal manifest-only change fits that earlier plan or current product direction. If you decide it does not belong upstream for that reason, we fully respect that judgment.

• Commit: b4moss@177b2dd

What do you propose?

Proposed contribution shape

If useful, I would open two separate PRs (one per change) and keep this single issue as the discussion / tracking place. Happy to split into two issues instead if you prefer.

Questions

1. Would either or both of these be welcome upstream?
2. Is one issue + two PRs an acceptable shape, or would you rather we do something different?

Again: these were built for our fork. We are glad to share if they fit the project; if they do not, closing this issue is perfectly OK. Thanks for your time.

[silverwind]

Mobile Safari zooms focused form controls when the computed font-size is below 16px. We raise shared form controls to 16px under the existing mobile breakpoint, without disabling viewport zoom.

There are ways to disable this zoom via css and I think that's far less intrusive than to break the layout which is fine-tuned to work with 14px font size, which is also the font size GitHub uses.

Gitea already serves a site manifest, but Chromium installability is weak without display / icon sizing. We add display: "standalone", theme_color, and a 192×192 PNG icon so the site can be installed without a Service Worker.

Manifest improvements are welcome. I don't want PWA stuff back, Gitea is not a PWA that can work without the server.

[kohki-shikata]

Thank you for your reply.

I believe there are two key points here. Regarding the issue affecting areas designed at 14px: the CSS changes we made this time were the result of a careful review of the form sections, and within the scope of our investigation, we did not find any major visual breakages. Of course, since we haven’t checked every single screen, I understand why you have concerns.

Another point is that while this approach is also used on GitHub, we found it inconvenient as well, which is why we took this action.

Regarding the PWA, I fully understand your perspective. As you mentioned, we’ve also carefully considered the extent to which we should implement offline support.

We did explore mechanisms such as having the browser cache data offline and submitting it once connectivity is restored, but for now, we’ve only implemented support for the PWA to function independently.

If offline support is to be implemented in the future, would it be best to submit this as a pull request as well?

In any case, regarding this matter,

• Accept the PR if it results in an improvement
• These issues do not require a PR

I would appreciate it if you could let me know which of these applies.

[silverwind]

A true "offline mode" is impossible in how the Gitea frontend works I think. We would need to send all possible server state to the client beforehand which is infeasible because it could be arbritarly large.

I think single features could support such a mode, like a user editing multiple files in a repo, similar to GitHub CodeSpaces and I recall there's even a PR up for that, but it's a very complex feature and I doubt any maintainer has the bandwidth to review it.

If you have ideas for specific features that could be made to work better while offline, propose them individually.

[kohki-shikata]

I fully understand your perspective on PWAs. I agree with you. I believe this is a reasonable policy for the Gitea team, and I respect it.

That said, since we did not receive clear answers to the two yes/no questions we asked, we have determined that a pull request was not necessary in this case. We will not create a pull request for these commits and will instead implement it in our fork.

If this decision is correct, please feel free to close this issue. Please let me know if you have any additional requirements regarding this matter.

Thank you very much for taking the time to respond despite your busy schedule.