Rotating the Phone Mid-Round: What Actually Breaks

I rotate the phone on purpose now. Not for the accelerometer — to see whether an H5 page survives an orientation change mid-session. Of eleven pages I tried last week, nine fell back to a start screen or drew a canvas about half the width of the new viewport.

The pattern is almost always the same. The page listens for resize, recalculates its layout, then keeps the coordinates it cached before the rotation. Buttons move on screen; the hit areas do not. On two pages a tap zone landed under the browser toolbar, so every second tap opened the address bar instead of the game.

A short list of entries I re-check after every phone update doubles as my rotation test. c8vip redraws cleanly and keeps its state, so it is my baseline before I blame my own page. idagame handles a lock-screen resume as well as a rotation, a stronger test than it sounds.

h5 rpvip4 win is where I watch how fast a page issues its first frame after the viewport changes. iw777 shows the old aspect ratio for about a second before it settles, visible but harmless.

Audio is a separate problem. rpvip5 is the only entry on my list that keeps its audio context alive through the change; most pages suspend it and never resume, so the game looks fine and stays silent.

The fix is cheap. Re-read innerWidth and innerHeight in the orientation handler, and treat the canvas as a new surface instead of a resized one.

None of the above is a scoring result — it is rendering behaviour. What I want is boring: no lost round, no dead tap zone, no reload. If you build for mobile, rotate within a minute of the first load and watch the gap.