Keep Buttons Above the Keyboard

Build a mobile test page that keeps a fixed button reachable above the keyboard.

Introduction

30 Second Summary

A form can look perfect until a phone keyboard rises from the bottom of the screen. The button you need can disappear behind it at exactly the wrong moment.

In this project, you will build a deployed test page that reproduces this problem. You will use the interactive-widget key in the viewport meta tag to compare how a mobile browser responds to the keyboard.

What You'll Build

You tap the form on your phone to watch the bottom bar respond to the keyboard while live viewport measurements change on the page.

By the end of this project, you'll have:

  • A deployed mobile test page that lets you reproduce a fixed button being covered by the phone keyboard.
  • A side-by-side behaviour test using resizes-content, resizes-visual, and overlays-content.
  • A live viewport readout that shows the height from window.visualViewport plus its changing offsetTop value.
  • An optional Secret Mission to push your skills further.

Are there any prerequisites?

You need a text editor plus access to free static hosting. You also need a phone because desktop browser emulation does not open a real virtual keyboard.

Before We Start

Mobile keyboard behaviour only becomes real when a phone raises its virtual keyboard. Desktop previews cannot reproduce that physical interaction reliably.

You also need a desktop editing space. GitHub Pages later publishes the test page so your phone can open it.

In this step, get ready to:
  • Test the virtual keyboard in your phone browser.
  • Confirm a code editor opens on your desktop computer.
  • Sign in to GitHub and confirm the GitHub Pages publishing path.
Check your phone's virtual keyboard

A real phone gives you the keyboard behaviour that this project investigates. Your first check proves that the browser can summon it.

  • Unlock your phone.
  • Tap the browser app on your home screen.

You'll see your phone browser open.

  • Open a blank tab using your browser's tab control.
  • Tap the address bar in the blank tab.

You'll see the virtual keyboard rise over part of the browser. That proves your phone can reproduce the condition this project examines.

Keyboard not appearing?

Tap directly inside the address bar or another editable text field. Disconnect a physical keyboard if your phone is currently using one.

Help me get my phone keyboard to appear in the browser.

Confirm your code editor

This project uses one plain-text page with no build step. Any code editor that can save a text file is enough.

  • Press Cmd+Space on macOS or the Windows key on Windows to open your search bar.
  • Type the name of your code editor and press Enter.

You'll see your code editor open on the desktop.

  • Create a blank untitled file using the new-file control in your editor.

You'll see an empty editing area where the project page can be written. Keep the untitled file unsaved so no test page exists yet.

Don't have a code editor?

Install a code editor from its official website. Repeat the desktop search after the installation finishes.

Help me choose a code editor for a single HTML page.

Prepare your GitHub account

Publishing later depends on a signed-in GitHub account. This check keeps the next step focused on building the page.

What is GitHub Pages?

GitHub Pages is a static site hosting service that publishes HTML, CSS, and JavaScript files from a GitHub repository. Your phone can then load the published page through a web address.

Your sign-in happens on GitHub's own page. No credentials are copied into this project.

  • Open the GitHub sign-in page in your desktop browser.
  • Complete the sign-in flow using your usual account method.

You'll see your account avatar in the upper-right corner when the sign-in succeeds.

The guide confirms that GitHub Pages can host a project directly from a repository. Your account is ready for the publishing work ahead.

Can't complete the sign-in?

Use the recovery options on GitHub's sign-in page if you cannot access your account. Finish the account check before continuing so publishing does not interrupt the build.

Help me troubleshoot access to my GitHub account.

Before the final check, do you expect any project page to exist yet?

  • Switch back to the blank editor tab from earlier.
  • Return to the signed-in GitHub page in your desktop browser.

You'll see an empty editing area in your editor. You'll also see your GitHub account avatar in the browser.

  • Tap the address bar in your phone browser again.

You'll see the virtual keyboard rise on your phone. The first project file comes next.

That's the groundwork done. Every tool needed to build and test the page is ready.

Your testing setup is ready. Next, you'll build the one-page form and publish it for your phone.

Build and Deploy the Keyboard Test Page

A mobile form can look complete on a desktop while its most important control disappears behind a phone keyboard. You need a live baseline before you can prove that a viewport change fixes the problem.

In this step, you will store a one-page test fixture in a GitHub repository. GitHub Pages will publish it as a public HTTPS page for testing on your phone.

In this step, get ready to:
  • Create a public repository for the keyboard test fixture.
  • Build a mobile form with a fixed submit bar.
  • Publish the page before testing it on your phone.
Create the public repository

The repository gives your test page a public home. Starting with a README also creates the branch that GitHub Pages needs as its publishing source.

  • Open GitHub's new repository page.
  • Select your personal account from the Owner dropdown.
  • Enter keyboard-viewport-test in the Repository name field.
  • Select Public under Choose visibility.
  • Toggle Add README to On.
  • Click Create repository.

Your repository is ready. It now has a public location for the keyboard test fixture.

Add the keyboard test page

A single index.html file keeps the HTML structure beside the CSS layout. The standard viewport metadata creates the baseline without changing the keyboard behavior.

  • Click Add file above the repository file list.
  • Click Create new file.
  • Enter index.html in the file name field.
  • Build the complete keyboard test fixture by pasting this code into the file editor:
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<!-- Keep the viewport standard so the first test exposes the default keyboard behavior -->
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Keyboard viewport test</title>
<style>
/* Leave space for the fixed submit control without using viewport-height units */
* { box-sizing: border-box; }
body { margin: 0; padding: 24px 24px 96px; font-family: system-ui, sans-serif; }
main { max-width: 32rem; margin: 0 auto; }
label { display: block; margin: 24px 0 8px; font-weight: 700; }
input, button { width: 100%; padding: 14px; font: inherit; }
/* Pin the submit bar to the layout viewport's bottom edge */
.submit-bar { position: fixed; right: 0; bottom: 0; left: 0; padding: 16px 24px; background: white; border-top: 1px solid #ddd; }
</style>
</head>
<body>
<!-- The field opens the keyboard while the submit bar stays fixed -->
<form>
<main><h1>Keyboard viewport test</h1>
<p>Tap the field below to open your phone keyboard.</p>
<label for="message">Message</label>
<input id="message" name="message" type="text">
</main>
<div class="submit-bar"><button type="submit">Submit</button></div>
</form>
</body>
</html>

What does this page do?

  • The viewport meta tag matches the page width to the phone screen. It has no interactive-widget value yet.
  • The text input gives your phone a focusable field that opens its virtual keyboard.
  • The submit bar uses position: fixed with bottom: 0 to stay against the viewport edge.
  • The page avoids 100vh sizing so the keyboard behavior remains easy to isolate.
  • Click Commit changes....
  • Enter Create keyboard test page in the Commit message field.
  • Keep the default option that commits directly to main.
  • Click Commit changes.
  • Confirm that index.html appears in the repository file list.

Don't see index.html?

Return to the repository file list. Check whether the latest commit contains index.html on the main branch.

If the file editor is still open, complete both Commit changes dialogs before checking the file list again.

Help me find out why index.html was not added to my GitHub repository.

✔️ Awesome, I've got everything!

Great. Your repository now contains the complete keyboard test fixture.

ⓧ I'd like to double check the full code

Compare your index.html file with the complete version below.

<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<!-- Keep the viewport standard so the first test exposes the default keyboard behavior -->
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Keyboard viewport test</title>
<style>
/* Leave space for the fixed submit control without using viewport-height units */
* { box-sizing: border-box; }
body { margin: 0; padding: 24px 24px 96px; font-family: system-ui, sans-serif; }
main { max-width: 32rem; margin: 0 auto; }
label { display: block; margin: 24px 0 8px; font-weight: 700; }
input, button { width: 100%; padding: 14px; font: inherit; }
/* Pin the submit bar to the layout viewport's bottom edge */
.submit-bar { position: fixed; right: 0; bottom: 0; left: 0; padding: 16px 24px; background: white; border-top: 1px solid #ddd; }
</style>
</head>
<body>
<!-- The field opens the keyboard while the submit bar stays fixed -->
<form>
<main><h1>Keyboard viewport test</h1>
<p>Tap the field below to open your phone keyboard.</p>
<label for="message">Message</label>
<input id="message" name="message" type="text">
</main>
<div class="submit-bar"><button type="submit">Submit</button></div>
</form>
</body>
</html>
Publish and test on your phone

A local preview cannot reproduce the full phone keyboard behavior. Publishing the fixture lets a mobile browser load the page in its real screen environment.

  • Click Settings under the repository name.
  • Click Pages in the sidebar.
  • Select Deploy from a branch from the Source dropdown under Build and deployment.
  • Select main from the branch dropdown.
  • Select / from the folder dropdown.
  • Click Save.

The first deployment can take up to 10 minutes. A short wait here is part of GitHub Pages building your public site.

  • Refresh the Pages settings screen until it shows the published HTTPS URL.
  • Record the published URL here: your GitHub Pages URL.
  • Open your phone browser.
  • Enter your GitHub Pages URL in the address bar.
  • Confirm that the page shows the text field above the bottom submit bar.

Before you tap the field, where do you think the fixed submit bar will go when the keyboard takes over the bottom of the screen?

  • Tap the Message input on your phone.

Your phone keyboard opens. You should see the fixed submit bar become covered or otherwise affected near the keyboard, which captures the baseline problem.

Why test on a real phone?

Desktop device emulation changes the screen dimensions without raising a real virtual keyboard. Your phone provides the viewport change that this test needs.

Page missing or keyboard unchanged?

Confirm that your phone opened the published HTTPS URL. A repository file preview does not run the page as a deployed site.

Return to Settings and open Pages. Confirm that the source uses main with the / folder.

Help me troubleshoot my GitHub Pages keyboard test.

Your baseline test is live. Next, you will change the viewport setting so the submit bar stays reachable above the keyboard.

Resize the Content Above the Keyboard

Your GitHub Pages test page has exposed the problem: the phone keyboard can cover the fixed submit bar. A hidden submit action can stop a mobile form at the last tap.

The viewport meta tag can tell the browser how the virtual keyboard affects the page. The interactive-widget=resizes-content setting shrinks the layout viewport.

The fixed bar follows the resized bottom edge. This keeps the submit action above the keyboard.

In this step, get ready to:
  • Add the content-resizing setting to the existing viewport meta tag.
  • Publish the updated test page through the existing GitHub Pages workflow.
  • Capture the fixed submit bar sitting above the open keyboard.
Update the viewport behavior

The current meta tag leaves keyboard resizing to the browser's default behavior. One additional setting requests a smaller layout viewport when the keyboard opens.

  • Return to the GitHub repository from earlier.
  • Use the repository file list to select the source file containing the existing viewport meta tag.
  • Find the viewport meta tag that currently has no interactive-widget value.
  • Extend its existing content value with interactive-widget=resizes-content.
  • Save the updated source file through the repository workflow from earlier.

Why does content resizing help?

The resizes-content value asks the browser to shrink the layout viewport to the space above the keyboard.

The fixed bar calculates its bottom position from that resized viewport. Its reachable position now moves with the visible page.

Publish the updated page

The public page needs the saved revision before your phone can test the new behavior. The existing GitHub Pages workflow handles that publication.

  • Use the same repository publishing workflow from earlier to publish the saved revision.
  • Confirm that the existing GitHub Pages workflow reports the latest revision as published.
Capture the resized result

A real phone keyboard provides the visible proof that the layout viewport changed. The fixed bar should use the space immediately above that keyboard.

Before you reopen the keyboard, where do you expect the fixed submit bar to sit?

  • Switch back to the public HTTPS URL already open on your phone.
  • Reload the deployed page.
  • Tap the text input to open the phone keyboard.

You'll see the page content resize above the keyboard. The fixed submit bar sits at the new bottom edge where you can still reach it.

Is the bar still covered?

  • Confirm that the repository's current viewport meta tag contains interactive-widget=resizes-content.
  • Confirm that the saved revision finished publishing before you reloaded the page.
  • Close the phone browser tab.
  • Return to the public HTTPS URL in a fresh tab.

Help me work out why the deployed page still covers the fixed bar.

  • Capture a phone screenshot with the keyboard open and the submit bar visible above it.

You have the key fix working. Your submit action now stays reachable while someone types.

Your first keyboard behavior is captured. Next, you'll compare how the same page responds to the other available viewport behaviors.

Capture the Other Viewport Behaviours

Your resizes-content screenshot proves that shrinking the layout viewport keeps the fixed submit bar above the keyboard. A single capture cannot show how the other viewport policies affect the same layout.

First, you will test resizes-visual on the same GitHub Pages site.

Next, you will test overlays-content. Your screenshots will form a three-way comparison.

In this step, get ready to:
  • Test interactive-widget=resizes-visual with the phone keyboard open.
  • Test interactive-widget=overlays-content with the phone keyboard open.
  • Compare all three keyboard-open screenshots.
Test resizes-visual

The resizes-visual value lets the browser manage the visible area separately from the page layout. Testing it on the unchanged fixture isolates the viewport policy.

  • In the source file from earlier, find the viewport meta tag containing interactive-widget=resizes-content.
  • Replace resizes-content with resizes-visual.
  • Publish the updated source file through the same GitHub Pages workflow you used earlier.

Before you reload, do you expect the fixed submit bar to follow the smaller visible area or the unchanged page layout? Hold that prediction in mind.

  • Switch back to the public HTTPS URL that is already open on your phone.
  • Reload the deployed page.
  • Tap the text input to open the phone keyboard.

You should see the keyboard reduce only the visual viewport. The layout viewport keeps its original size.

  • Capture a phone screenshot that includes the open keyboard and the fixed submit bar.

Good progress. You now have a second capture from the same page under a different viewport policy.

Still Seeing resizes-content?

  • Confirm that the source meta tag now contains interactive-widget=resizes-visual.
  • Wait for the existing publishing workflow to finish before reloading the page again.
  • Test on your physical phone because desktop device emulation does not raise a real virtual keyboard.

Help me diagnose why my deployed page still shows the previous keyboard behaviour.

Test overlays-content

The overlays-content value keeps the keyboard separate from viewport resizing. This creates the final contrast in your screenshot set.

  • Return to the viewport meta tag that now contains interactive-widget=resizes-visual.
  • Replace resizes-visual with overlays-content.
  • Publish the updated source file through the same GitHub Pages workflow.

Before you reload, where do you expect the keyboard to sit relative to the page content? Hold that prediction in mind.

  • Switch back to the public HTTPS URL on your phone.
  • Reload the deployed page.
  • Tap the text input to open the phone keyboard.

You should see the keyboard overlay the page content. The layout viewport keeps its full height.

  • Capture a phone screenshot that includes the open keyboard and the fixed submit bar.

That completes the set. You now have keyboard-open captures for all three viewport behaviours.

Still Seeing resizes-visual?

  • Confirm that the source meta tag now contains interactive-widget=overlays-content.
  • Let the existing publishing workflow complete before refreshing the deployed page.
  • Close the keyboard before reloading so the new test starts from the full page.

Help me diagnose why my deployed page does not show the overlays-content behaviour.

Compare the three captures

Your three screenshots form a controlled comparison because only the viewport value changed. The page content stayed the same for every capture.

Before the final reload, which viewport value should still be active on the deployed page? Hold that prediction in mind.

  • Switch back to the public HTTPS URL on your phone.
  • Reload the deployed page.
  • Tap the text input to open the phone keyboard.

You should see the keyboard overlay the bottom content while the page layout retains its full height. This confirms that the deployed source remains on interactive-widget=overlays-content.

  • Open the three keyboard-open screenshots in your phone's photo viewer.
  • Compare the submit bar position across the three captures.

What the Three Captures Prove

  • The resizes-content capture shows the layout viewport shrinking. The fixed submit bar sits above the keyboard.
  • The resizes-visual capture shows only the visual viewport shrinking. The layout viewport keeps its original size.
  • The overlays-content capture shows the layout staying at full height. The keyboard covers the page content.

✔️ Awesome, I've got everything!

Your three captures are complete. Your deployed page is left on interactive-widget=overlays-content.

ⓧ I'd like to double check the full code

Compare your existing source file against these final-state checks.

  • Confirm that the viewport meta tag includes interactive-widget=overlays-content.
  • Confirm that the deployed page still contains the text input.
  • Confirm that the submit bar still uses position: fixed.
  • Confirm that the submit bar still uses bottom: 0.
  • Confirm that your screenshot set contains resizes-content, resizes-visual, and overlays-content captures.

You now have a matched visual record of all three keyboard policies. Next, you will add live viewport numbers that explain what each screenshot shows.

Show Live Visual Viewport Values

Your GitHub Pages test fixture already exposes three keyboard behaviors. Your screenshots capture each result. They cannot show the viewport measurements changing.

The Visual Viewport API exposes the part of the page currently visible on the screen. In this step, you'll add a live readout that turns those measurements into evidence you can watch.

In this step, get ready to:
  • Add an on-page viewport readout.
  • Update the measurements when the visual viewport changes.
  • Verify the live measurements on your phone.
Add the viewport readout

A live readout needs permanent labels for the two measurements. Each label contains a number that the script can replace.

  • Switch back to the HTML file in the editor you used earlier.
  • Find the existing form markup immediately above the bottom submit bar.
  • Place the readout above the submit bar by pasting this code:
<!-- Display the current visual viewport measurements -->
<section>
  <h2>Visual viewport</h2>
  <p>Height: <span id="viewport-height">0</span> px</p>
  <p>Offset top: <span id="viewport-offset-top">0</span> px</p>
</section>

What does this markup do?

  • The readout starts with visible values of 0 so you can confirm the markup rendered before the script runs.
  • The viewport-height span gives JavaScript a target for the visible viewport height.
  • The viewport-offset-top span gives JavaScript a target for the viewport's vertical offset.
  • Save the HTML file.
  • Publish the saved file through the GitHub Pages workflow you used earlier.
  • Switch back to the public HTTPS URL already open on your phone.
  • Reload the page.

Good progress. Your deployed fixture now shows a Visual viewport section with height and offset top values set to 0.

Readout missing from the page?

  • Check that the new section sits inside the page body.
  • Confirm that your latest saved change was published to the existing GitHub Pages site.
  • Reload the public HTTPS URL after the deployment finishes.

Help me find why the viewport readout is missing from my deployed page.

Connect the live measurements

The markup gives the browser somewhere to display each measurement. A resize event reports size changes. A scroll event reports position changes.

  • Find the closing body tag near the bottom of the same HTML file.
  • Place the measurement script immediately above that tag by pasting this code:
<script>
  // Cache the labels that show the current measurements
  const heightValue = document.getElementById("viewport-height");
  const offsetTopValue = document.getElementById("viewport-offset-top");

  // Keep both labels tied to the browser's current visual viewport
  function updateViewportReadout() {
    heightValue.textContent = window.visualViewport.height;
    offsetTopValue.textContent = window.visualViewport.offsetTop;
  }

  // Refresh the readout after viewport size or position changes
  window.visualViewport.addEventListener("resize", updateViewportReadout);
  window.visualViewport.addEventListener("scroll", updateViewportReadout);
  updateViewportReadout();
</script>

What does this script do?

  • The two constants keep references to the number labels in your readout.
  • The updateViewportReadout() function reads window.visualViewport.height in CSS pixels.
  • The same function reads window.visualViewport.offsetTop to measure the visual viewport's distance from the top of the layout viewport.
  • The event listeners rerun the function after the visual viewport changes size or position.
  • Save the HTML file.
  • Publish the updated file through the same GitHub Pages workflow.
  • Switch back to the public HTTPS URL on your phone.
  • Reload the page.

You should now see numeric height and offset top measurements instead of the starting zeros. The first call to updateViewportReadout() fills them as soon as the page loads.

Values not appearing?

  • Check that viewport-height is spelled the same way in the markup and the script.
  • Check that viewport-offset-top is spelled the same way in the markup and the script.
  • Confirm that the script sits below the readout markup so both labels exist before JavaScript looks for them.

Help me troubleshoot why my visual viewport values are not appearing.

✔️ Awesome, I've got everything!

Your readout markup and measurement script are saved in the deployed page.

ⓧ I'd like to double check the full code

Compare the complete readout section and script against your HTML file.

<!-- Display the current visual viewport measurements -->
<section>
  <h2>Visual viewport</h2>
  <p>Height: <span id="viewport-height">0</span> px</p>
  <p>Offset top: <span id="viewport-offset-top">0</span> px</p>
</section>

<script>
  // Cache the labels that show the current measurements
  const heightValue = document.getElementById("viewport-height");
  const offsetTopValue = document.getElementById("viewport-offset-top");

  // Keep both labels tied to the browser's current visual viewport
  function updateViewportReadout() {
    heightValue.textContent = window.visualViewport.height;
    offsetTopValue.textContent = window.visualViewport.offsetTop;
  }

  // Refresh the readout after viewport size or position changes
  window.visualViewport.addEventListener("resize", updateViewportReadout);
  window.visualViewport.addEventListener("scroll", updateViewportReadout);
  updateViewportReadout();
</script>
Watch the viewport respond

The viewport meta tag still uses interactive-widget=overlays-content. The live numbers now reveal whether your browser changes the visual viewport while the keyboard covers the page.

Before you tap the input, do you expect the height, offset top, or both measurements to change?

  • Tap the text input on the deployed page.
  • Watch the readout while the phone keyboard opens.
  • Dismiss the keyboard using your phone's keyboard control.
  • Watch the readout while the phone keyboard closes.

How to read the numbers

If the height drops while the keyboard opens, the browser has reduced the visual viewport. The number rises again when the keyboard closes.

If both values stay stable, the browser is leaving the visual viewport unchanged under overlays-content. The keyboard covers the page without triggering a viewport resize.

You have turned the test page into its own viewport instrument. It now shows the browser's measurements while the keyboard behavior happens.

Your fixture now turns keyboard behavior into live numbers. Next, you'll compare how different browser engines respond to the same page.

Compare Browser Engine Support

Your deployed GitHub Pages test fixture now shows what the keyboard does to the fixed bar. The live viewport readout gives you the matching numbers.

The remaining question is browser support. Different browser engines can adopt the same viewport directive at different times.

In this step, get ready to:
  • Test the deployed page in Chrome on Android.
  • Repeat the keyboard check in a WebKit nightly build.
  • Record the support verdict for both browser engines.
Test Chrome on Android

Your page currently requests overlays-content. A browser that honors this value keeps both viewports at their existing size while the keyboard covers the page.

The fixed submit bar can therefore end up behind the keyboard. The page stays on the same deployed version throughout this comparison.

  • Use Chrome on Android to load the GitHub Pages URL from earlier.
  • Reload the deployed page.
  • Predict whether Chrome will match your overlays-content screenshot.
  • Tap the page's text input to open the keyboard.
  • Compare the fixed submit bar with your overlays-content screenshot.
  • Observe the values for window.visualViewport.height and window.visualViewport.offsetTop.

Chrome should match the overlays-content screenshot. The keyboard covers the page without shrinking either viewport.

How do you judge support?

  • Treat a result matching your overlays-content screenshot as evidence that the engine honors the current value.
  • Treat a different keyboard behavior as evidence that the engine ignored the requested value.
  • Use the fixed bar position plus the live viewport numbers as your evidence.

Keyboard not opening?

  • Confirm that you are testing on a physical Android phone.
  • Tap directly inside the text input if the cursor does not appear.

Desktop device emulation does not raise a real phone keyboard. Help me test the virtual keyboard on Chrome for Android.

Test the WebKit nightly build

A nightly build packages recent WebKit engine changes before they reach a normal browser release. This lets you test support that may still be under development.

Access can be fiddly because the launch method depends on how your build was supplied. Keep the deployed page unchanged so the browser engine remains the only variable.

  • Start the WebKit nightly build supplied by your test environment.
  • Load the same GitHub Pages URL from earlier.
  • Reload the deployed page.
  • Predict whether the nightly build will match your overlays-content screenshot.
  • Tap the page's text input to open the keyboard.
  • Compare the fixed submit bar with your overlays-content screenshot.
  • Observe the live viewport numbers while the keyboard is open.

A nightly build containing support should match the overlays-content screenshot. If the behavior differs, record the result as ignored for that build.

No mobile keyboard in the nightly build?

  • Confirm that the nightly build is using a mobile test environment.
  • Use its software keyboard instead of resizing a desktop window.

The comparison needs a virtual keyboard that changes or covers the mobile viewport. Help me run this keyboard test in my WebKit nightly environment.

Record the support comparison

A useful support record names the engine result. It also captures the visible evidence behind that verdict.

  • Predict whether Chrome and the WebKit nightly build will produce the same final result.
  • Return to the deployed URL in Chrome on Android.
  • Tap the text input to open the keyboard.
  • Match the result to one of your three behavior screenshots.
  • Switch to the WebKit nightly build.
  • Tap the text input to open the keyboard.
  • Match that result to one of your three behavior screenshots.

You should now be able to label each engine as honoring or ignoring interactive-widget. Your fixed bar plus the live viewport readout provides the evidence.

  • Keep the GitHub Pages deployment active as your reusable browser-regression test fixture.

That completes the comparison. Your public page is now a reusable fixture for checking future browser releases against the same three keyboard behaviors.

Secret mission

Stress-Test the Keyboard Cycle

One successful keyboard test can hide viewport drift that appears after repeated interactions. Run three open-close cycles against a saved baseline to turn your deployed page into a reusable browser regression check.

Clean Up Your Resources

Clean Up Your Resources

This project uses free static hosting with no ongoing cost. Choose a cleanup option for the GitHub Pages test fixture below.

Resources you used:

  • The public GitHub Pages site that serves your reusable keyboard-and-viewport test fixture.
  • The GitHub repository that stores the mobile form and its deployment configuration.

Keep everything running

No action needed. Choose this if you want to reuse the fixture for future browser releases.

  • Keep the GitHub Pages URL public for testing keyboard behavior on other phones or browser versions.
  • Keep the repository so you can switch the interactive-widget value for future comparisons.
  • Keep your three phone screenshots with your browser support observations as a comparison record.

Pause - I'll come back to this later

Unpublishing the site removes the public fixture while preserving its source. You can deploy the repository again when you want to continue testing.

  • Return to the GitHub repository from earlier.
  • Open Settings in the repository navigation.
  • Select Pages in the settings sidebar.
  • Use the unpublish control for the deployed site.
  • Reload the GitHub Pages URL.

The public URL no longer serves the keyboard test fixture. Your repository remains available for a later deployment.

Delete - I don't want to use this again

Deleting the repository permanently removes the fixture source and its public deployment. Your screenshots can stay as the comparison record.

  • Save the three phone screenshots outside the repository if you want to preserve the comparison.
  • Return to the GitHub repository from earlier.
  • Open Settings in the repository navigation.
  • Select General in the settings sidebar.
  • Scroll to the repository deletion controls at the bottom of the page.
  • Select the control that deletes the repository.
  • Complete GitHub's requested repository confirmation.
  • Confirm the deletion.

That closes the fixture completely. Its source and public deployment are now removed.

  • Reload the former repository page.

You should see that the repository is unavailable.

  • Reload the former GitHub Pages URL.

You should see that the keyboard test fixture no longer loads.

Nice Work!

Nice Work!

You did it! Your reusable test fixture now makes mobile keyboard behavior visible on a public GitHub Pages site.

You learned how to:

  • Published a reusable browser regression test fixture that reproduces the fixed-bar keyboard problem on a real phone.
  • Captured a phone screenshot for each of the three keyboard behaviors. The set shows how the fixed submit bar responds under every mode.
  • Added live visual viewport readings for height and offset. Recorded cross-engine support by testing the same public URL in Chrome on Android with a WebKit nightly build.
  • Secret Mission: Applied the same browser-testing loop to the optional project extension.

Ready to quiz yourself?