Thanks for this!

EDIT: I misunderstood the problem. This seems like a fix better suited for Safari. But I don't have any Apple device to test it.

css body { min-height: 100vh; min-height: -webkit-fill-available; } html { height: -webkit-fill-available; } https://css-tricks.com/css-fix-for-100vh-in-mobile-webkit/

It's actually not that difficult to fix. Well, this is actually a workaround to keep viewport in place.

I usually put a transition (forgot to do it here) that keeps page from resizing.

css .container { min-height: 100vh; transition: height 10000s steps(0); }

steps() function prevents excessive layout calculations, and lets the page snap back into place (10000s ~= 3h later) in a single step. This fix also prevents page from jumping around when the keyboard pops up and down.

This is likely to be covered by plugin hooks: #860 for the metadata and after investigating in #1042 it looks like the existing prepare_jinja2_environment hook may already be enough to load templates from the database.

This is STILL a good idea.

I deployed this to https://datasette-issue-1129.vercel.app/ (using datasette publish vercel fixtures.db --branch 8d4c69c6fb0ef741a19070f5172017ea3522e83c --about_url https://github.com/simonw/datasette/issues/1129 --about datasette/issues/1129 --project datasette-issue-1129) - weirdly, on Mobile Safari the footer appears just below the visible window:

I've seen other problems with fixed footers on Mobile Safari too: at Eventbrite this was a really nasty problem for us to figure out: https://www.eventbrite.com/engineering/mobile-safari-why/

Codecov Report

Merging #1130 (8d4c69c) into main (49d8fc0) will not change coverage. The diff coverage is n/a.

```diff @@ Coverage Diff @@

main #1130 +/-

======================================= Coverage 91.42% 91.42%
======================================= Files 31 31
Lines 3873 3873
======================================= Hits 3541 3541
Misses 332 332
```

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 49d8fc0...8d4c69c. Read the comment docs.

Codecov Report

Merging #1128 (7004c3b) into main (49d8fc0) will decrease coverage by 0.00%. The diff coverage is n/a.

```diff @@ Coverage Diff @@

main #1128 +/-

========================================== - Coverage 91.42% 91.42% -0.01%
========================================== Files 31 31
Lines 3873 3872 -1
========================================== - Hits 3541 3540 -1
Misses 332 332
```

| Impacted Files | Coverage Δ | | |---|---|---| | datasette/utils/asgi.py | 92.13% <ø> (-0.04%) | :arrow_down: |

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 49d8fc0...7004c3b. Read the comment docs.

https://latest.datasette.io/-/versions now shows this: json { "python": { "version": "3.8.6", "full": "3.8.6 (default, Nov 18 2020, 13:49:49) \n[GCC 8.3.0]" }, "datasette": { "version": "0.52.3", "note": "49d8fc056844d5a537d6cfd96dab0dd5686fe718" }, "asgi": "3.0", "uvicorn": "0.12.3", "sqlite": { "version": "3.33.0", "fts_versions": [ "FTS5", "FTS4", "FTS3" ], "extensions": { "json1": null }, "compile_options": [] }, "pysqlite3": "0.4.4" }

I'm going to check pkg_resources.get_distribution("pysqlite3-binary").version too.

Urgh, figuring out the version of pysqlite3 is WAY harder than I expected. The getversion module looks like the smartest attempt at solving this problem generally, but I'd like to avoid adding another dependency just for this: https://github.com/smarie/python-getversion

That didn't work - https://latest.datasette.io/-/versions isn't showing the package.

I bet that's because I'm actually installing pysqlite3-binary here: https://github.com/simonw/datasette/blob/e2fea36540e952d8d72c1bd0af7144b85b7a4671/.github/workflows/deploy-latest.yml#L57

That worked.