Gravity Forms 3.1.1.1 fixes a Safari layout problem where the native Choose File button could overlap the file field border in conversational forms. The defect can look cosmetic on a wide Mac but reduce the tap target, cover the filename, collide with validation text, or block progress on an iPhone using larger text.
Use this for application forms, claims, resumes, identity documents, support attachments, medical intake, and any conversational form where Safari users must upload a file before reaching the next step.
Quick answer
Build a conversational form with required and optional file fields, long labels, help text, accepted file types, and a small upload limit. Test Safari on a Mac, iPhone, and iPad at default size, larger text, landscape, portrait, 200 percent zoom, empty state, selected filename, long filename, validation error, rejected file type, and upload progress. The native button, filename, border, instructions, error, and next control must remain visible, tappable, and in a logical reading order.
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| Mac Safari | 200% zoom | No border collision |
| iPhone portrait | Large text | Button and filename fit |
| iPad landscape | Long filename | Wraps without overflow |
| Validation | Wrong file type | Error visible and announced |
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence | Verification |
|---|
| Freeze a file-field fixture | Record Gravity Forms version, Safari and operating-system versions, device, viewport, zoom, text size, theme, custom CSS, conversational template, and cache state. | The native button and filename remain inside the field without horizontal scrolling. |
| Test native Safari states | Test empty, focused, hover, active, file selected, long filename, validation error, server rejection, upload progress, uploaded, and reset states. | Labels, help text, progress, and errors stay visible and correctly associated with the input. |
| Separate theme and plugin CSS | Use real iPhone and iPad Safari when possible because desktop responsive mode does not reproduce every native file-input style or virtual keyboard behavior. | Keyboard and touch users can select, replace, remove, and submit a valid file. |
| Apply the narrowest correction | Check tap target size, focus visibility, label association, error announcement, filename wrapping, border collision, horizontal overflow, and movement when the next step appears. | The same form continues to work in Chromium and Firefox after any custom CSS change. |
What to check first
- Record Gravity Forms version, Safari and operating-system versions, device, viewport, zoom, text size, theme, custom CSS, conversational template, and cache state.
- Test empty, focused, hover, active, file selected, long filename, validation error, server rejection, upload progress, uploaded, and reset states.
- Use real iPhone and iPad Safari when possible because desktop responsive mode does not reproduce every native file-input style or virtual keyboard behavior.
- Check tap target size, focus visibility, label association, error announcement, filename wrapping, border collision, horizontal overflow, and movement when the next step appears.
- Repeat with the site theme CSS disabled, custom form CSS disabled, RTL text, translated labels, reduced motion, and high contrast to isolate the styling owner.
Field notes
- Write the pass condition before changing anything. A repeatable synthetic fixture makes the before and after comparison far more useful.
- Keep exact versions and UTC timestamps because scheduled jobs, caches, OAuth refreshes, retries, and background processing can change the evidence.
- Check the public experience and the stored server-side result. Admin previews and isolated API calls do not prove the whole workflow.
- Repeat the test after the relevant cache, queue, scheduled action, webhook, and observation window has finished.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
# Capture exact rendering context
Safari: 19.x
iOS: 20.x
Viewport: 390x844
Text size: 135%
Zoom: 100%
Form state: rejected PDF with long filename
Expected: button, filename, border, and error do not overlap
Why this usually happens
- Safari applies native file-input dimensions that differ from Chromium and Firefox.
- A fixed height or line-height assumes the button and filename will stay on one line.
- Theme styles target generic input selectors and override the conversational form layout.
- Validation inserts text without reserving vertical space, causing the next control to cover it.
Decision rule
Approve the update when every supported Safari device and text setting keeps the complete file workflow readable and operable, with no overlap, hidden filename, lost focus, or inaccessible error.
Production verification checklist
- The native button and filename remain inside the field without horizontal scrolling.
- Labels, help text, progress, and errors stay visible and correctly associated with the input.
- Keyboard and touch users can select, replace, remove, and submit a valid file.
- The same form continues to work in Chromium and Firefox after any custom CSS change.
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Freeze a file-field fixture
- Test native Safari states
- Separate theme and plugin CSS
- Apply the narrowest correction
- Retest upload completion
Mistakes to avoid
- Changing production before recording plugin versions, WordPress version, PHP version, UTC time, the exact fixture, and a tested rollback point.
- Accepting one successful admin screen while the public form, stored record, API response, accessibility tree, cache, email, or downstream system remains unchecked.
- Testing only as an administrator instead of the role, browser, device, locale, network state, and failure path that a real customer reaches.
- Leaving test accounts, broad credentials, debug logs, temporary compatibility filters, or synthetic customer data active after verification.
Questions teams ask during testing
Should I test this on production?
Use production for read-only evidence first. Reproduce the change on staging with a current data shape, theme, extensions, caching stack, and browser mix. If a production canary is necessary, make it reversible, identifiable, monitored, and unable to charge a customer or expose personal data.
How do I know the result is not a cache artifact?
Record the origin response, purge only the affected paths, and repeat the test in a private session and a normal session. Compare stored data and server logs with the visible page. A cache hit is useful evidence only when you know which version it contains.
What belongs in the evidence packet?
Keep UTC time, exact versions, fixture ID, role, browser, expected result, actual result, relevant response or log lines, change made, rollback point, owner, and final verification. Redact passwords, tokens, personal data, and private URLs.
When can I close the test?
Close it when the primary path and important failure branches pass, records reconcile across systems, accessibility and mobile checks are complete, temporary changes are removed, and monitoring covers the next update or business cycle.
What to tell the client or owner
Give the owner a short packet with the affected workflow, exact versions, UTC test time, fixture ID, expected result, actual result, key evidence, change made, rollback point, unresolved risk, owner, and next review date. Remove credentials and personal data before sharing it.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, have HandL WP fix a Gravity Forms browser issue.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references