Skip to content

chore: sync upstream PR #8366 - fix(android): implement automatic edge-to-edge and universal keyboard handling - #94

Closed
riderx wants to merge 17 commits into
plusfrom
sync/upstream-pr-8366
Closed

chore: sync upstream PR #8366 - fix(android): implement automatic edge-to-edge and universal keyboard handling#94
riderx wants to merge 17 commits into
plusfrom
sync/upstream-pr-8366

Conversation

@riderx

@riderx riderx commented Jul 14, 2026

Copy link
Copy Markdown
Member

Merge Conflict Review Required

The sync of upstream PR ionic-team#8366 from @fabiomartino encountered merge conflicts.

Original PR: ionic-team#8366

What happened

  • Git applied the upstream-preferred merge strategy
  • This PR requires CI and manual review before merging

Synced from upstream by Capacitor+ Bot

fabiomartino and others added 17 commits March 1, 2026 21:18
…iew support

- Add cachedWebViewMajorVersion field to avoid repeated WebView version lookups
- Add handleOnResume() override to refresh insets on app resume
- Add WindowCompat.setDecorFitsSystemWindows() calls in load(), handleOnResume(), and onDOMReady()
- Add null check in setStyle() PluginMethod for safer style parameter handling
- Preserve backup's applyInsets() implementation with legacy WebView compatibility
- Add setViewMargins() and resetViewBottomMargin() for legacy WebView workaround
- Use MIN_INSETS_VERSION (LOLLIPOP) instead of VANILLA_ICE_CREAM for broader SDK support
- Use INSETS_HANDLING_CSS constant instead of hardcoded string literal
- Remove unused setViewBottomMargin() and getBottomInset() methods
- Rename viewportMetaJSFunction to VIEWPORT_META_JS constant
Fixes edge-to-edge display issues on devices with various WebView versions.
…lder Android

- Add support for API 21-34 by using LOLLIPOP instead of VANILLA_ICE_CREAM
- Add legacy fallback for WebView < 140 on Android API < 30 that forces CSS
  safe-area vars to 0 to prevent double compensation in footer/tab-bar layouts
- Preserve original legacy IME margins behavior for Android 11+ (API 30-33)
- Fixes ionic-team#8394: CSS safe-area-inset-x not being applied on Android API <= 34
Scope legacy fallback to Android API < 30 and force zero CSS safe-area vars in that path to prevent double compensation on top/bottom bars, while preserving behavior on newer API levels.
Keep top safe-area inset at 0 for Android API < 30 (legacy and modern WebView paths), preserve semantic bottom inset handling, and prevent malformed safe-area CSS custom properties from persisting across keyboard/lifecycle transitions.
Se vuoi una versione con riferimento issue:
fix(android): stabilize safe-area CSS behavior on API < 30 (ionic-team#8394)
Keep top safe-area inset at 0 for Android API < 30 (legacy and modern WebView paths), preserve semantic bottom inset handling, and prevent malformed safe-area CSS custom properties from persisting across keyboard/lifecycle transitions.
@riderx

riderx commented Jul 14, 2026

Copy link
Copy Markdown
Member Author

Git applied the upstream-preferred strategy to resolve this sync. Please review the branch carefully before merging.

@coderabbitai

coderabbitai Bot commented Jul 14, 2026

Copy link
Copy Markdown

Warning

Review limit reached

You’ve reached a temporary PR review limit under our Fair Usage Limits Policy.

Your recent review volume is higher than typical usage, so adaptive limits are currently applied.

Next review available in: 59 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details
⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: 6af3247b-147c-4e83-80b4-bcee11ff5a30

📥 Commits

Reviewing files that changed from the base of the PR and between 63026cc and 618b0ce.

📒 Files selected for processing (1)
  • android/capacitor/src/main/java/com/getcapacitor/plugin/SystemBars.java

Comment @coderabbitai help to get the list of available commands.

@github-actions

Copy link
Copy Markdown

Beta npm build

Maintainers can publish one Capacitor Plus workspace package from this PR to npm for fast testing.

Comment /publish-beta <package> after the PR checks are green.

Examples:

/publish-beta core
/publish-beta cli
/publish-beta @capacitor-plus/core

If exactly one workspace package changed, /publish-beta without a package will use that package.

Packages:

  • core (@capacitor-plus/core)
  • cli (@capacitor-plus/cli)
  • android (@capacitor-plus/android)
  • ios (@capacitor-plus/ios)

The workflow will:

  • publish a prerelease package on the beta tag
  • add a pinned pr-94 dist-tag for the selected package
  • update this comment with the install command

Security note: beta publish is only enabled for branches inside this repository.

@cursor cursor Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Risk: medium. Cursor Bugbot was not present on this PR, and no automated review reported findings requiring human attention. Approved as a focused upstream Android SystemBars sync with bounded edge-to-edge and keyboard handling changes. No reviewers assigned.

Open in Web View Automation 

Sent by Cursor Approval Agent: Pull Request Approver

@cursor cursor Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Risk: medium. Not approving — the Android SystemBars edge-to-edge/keyboard changes exceed the low-risk approval threshold. Assigned jcesarmobile and fabiomartino for human review.

Open in Web View Automation 

Sent by Cursor Approval Agent: Pull Request Approver External

@cursor cursor Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Risk: medium. Not approving — the Android SystemBars edge-to-edge/keyboard changes exceed the low-risk approval threshold. Human review is needed; reviewer assignment failed because no eligible collaborators are available outside the PR author.

Open in Web View Automation 

Sent by Cursor Approval Agent: Pull Request Approver External

@cursor

cursor Bot commented Aug 13, 2026

Copy link
Copy Markdown

Not merging this one — it competes with what already landed

Leaving this open rather than merging. It rewrites the same Android insets/edge-to-edge code path as two other changes, and only one of the three can win.

plus now contains upstream #8424 ("make safe-area-inset-x available on API <= 34"), merged upstream on 2026-05-22 and landed here via #70. This PR's upstream counterpart, #8366, predates it and replaces initWindowInsetsListener wholesale — new applyInsets, margin-based layout, a rewritten injectSafeAreaCSS, and deletion of getBottomInset. It also flips WindowCompat.setDecorFitsSystemWindows to true, the opposite of what #8454 (synced as #67) sets.

Signals that pushed me toward not landing it:

Verifying which behaves correctly needs real devices across API 31–35 with and without the keyboard, which I cannot do here, and guessing on core Android UI in production fork infrastructure is not worth it.

What I'd suggest: treat #67 as the edge-to-edge fix for plus and close this one, unless you have a case where ionic-team#8366's approach is the one that works for you. If you want this instead, say so and I will rebuild it onto the current plus and revert the ionic-team#8424 hunks it conflicts with.

Posted by an AI agent (Cursor).

@cursor

cursor Bot commented Aug 13, 2026

Copy link
Copy Markdown

Re-checked against current plus — merging this would revert two shipped fixes

I attempted the rebuild onto the current plus tip. It produces three conflicts in SystemBars.java, and they are not resolvable in any way that keeps both sides: upstream #8366 replaces initWindowInsetsListener with a new applyInsets method, so the hunks plus has simply have nowhere to go. Resolving in this PR's favour means deleting them.

I measured exactly what that costs, counting occurrences in SystemBars.java:

marker plus today after taking this PR
VANILLA_ICE_CREAM — upstream #8424, merged upstream, landed here via #70 2 0
getBottomInset — workaround for chromium 457682720, wrong bottom inset while the IME is visible 2 0

The getBottomInset removal is deliberate in this PR's own history — commit 6cffa1a says "Remove unused setViewBottomMargin() and getBottomInset() methods". That lines up exactly with the regression @prajapatijay95 reported upstream: "it fixes the webview issue on the SDK <= 34. But noticed, scroll is blocked when keyboard is opened."

So this is not a conflict to resolve, it is a revert of two fixes already shipped on plus, in favour of a branch that has had no upstream review, is CONFLICTING against upstream main, and has not been touched since 2026-04-15.

#67 covers the same ground without that cost — it is purely additive, keeps both markers at 2, and additionally restores the insetsHandling: "disable" guard. I have unblocked it and it is on track to merge.

Recommendation: close this in favour of #67. I have left it open rather than closing unilaterally, since it was explicitly on your merge list. Say the word either way.

Posted by an AI agent (Cursor).

@TorichanCapgo

Copy link
Copy Markdown

Closing this. Merging it would revert two fixes already on plus (upstream ionic-team#8424 via #70, and the getBottomInset chromium 457682720 keyboard workaround). Edge-to-edge is covered by #67 instead. Upstream ionic-team#8366 is still unreviewed and conflicting against ionic main.

@cursor

cursor Bot commented Aug 13, 2026

Copy link
Copy Markdown

Closing per Martin's confirmation.

Merging this would revert two fixes already shipped on plus: upstream #8424 (VANILLA_ICE_CREAM handling, 2 occurrences → 0) and the getBottomInset workaround for chromium 457682720, which is what keeps the bottom inset correct while the IME is visible (2 → 0).

Edge-to-edge is covered by #67, which is merged and purely additive.

Posted by an AI agent (Cursor).

@riderx riderx closed this Aug 13, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants