Stop the landing hero eating the first swipe on a phone - #444
Conversation
The home hero paints glows that are deliberately bigger than the hero box, so the section clips. Clipping with overflow: hidden also makes it a scroll container, and it holds real scrollable overflow (280px vertically, 160px horizontally at 390px wide). In WebKit a touch that starts inside a scroll container is latched to that container; a hidden box cannot be scrolled by the user, so the swipe does nothing and does not chain to the page. The hero is the whole first screen on a phone, which is why the home page looked frozen on load and only started scrolling after a tap or a swipe that began below the hero. overflow: clip clips identically and creates no scroll container, so the touch reaches the page. overflow: hidden stays ahead of it as the fallback for Safari < 16, which ignores clip; autoprefixer and cssnano keep both declarations. In real WebKit at iPhone 13 metrics the fix leaves the three affected pages pixel-identical (full-page screenshot diff: 0 changed pixels of 2,330,640) and removes the latching container from under the first screen. Same change for the two other landing heroes built the same way, /data-platform and /labs. The ch3 heroes (cloud-data-platform, agentic-data-plane, connect, self-managed) were already safe: they clip in a separate .ch3-hero-bg layer that is pointer-events: none, so no touch ever lands in it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
Understand this PR’s impact Explore downstream dependencies and potential security impact with Blast Radius. Important Review skippedAuto incremental reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Advanced Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (6)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughWalkthroughLanding-page hero styles now use Priority: ⬇️ Low Estimated code review effort: 2 (Simple) | ~10 minutes Severity of issue fixed: Low 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
✅ Deploy Preview for docs-ui ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
2 participants
The home hero clips glow layers that are bigger than the hero box.
overflow: hiddenalso makes it a scroll container holding real overflow (280px vertically, 160px horizontally at 390px wide), and in WebKit a touch that starts inside a scroll container is latched to it. A hidden box can't be scrolled by the user, so the swipe does nothing and never reaches the page. The hero is the whole first screen on a phone, so the page looks frozen on load until you tap or swipe from below it.overflow: clipclips the same way and creates no scroll container.hiddenstays ahead of it for Safari < 16; autoprefixer and cssnano keep both.Same change for
/data-platformand/labs, which have the same hero. The ch3 heroes were already safe: they clip in apointer-events: nonelayer.Verified
npx gulp lintclean; built CSS keepsoverflow:hidden;overflow:clip.tests/hero-scrollinvalidate-build.yml; removing theclipline fails it.Playwright's WebKit can't synthesize touch drags, so the finger-on-glass symptom needs a check on a real phone against the preview. Chromium scrolls fine either way.
🤖 Generated with Claude Code