Skip to content

revert PR #1902 simplify edge-to-edge preference logic in CordovaActivity and SystemBarPlugin#1962

Closed
GitToTheHub wants to merge 1 commit into
masterfrom
pr-revert-pr-1902-simplify-edge-to-edge-preference-logic
Closed

revert PR #1902 simplify edge-to-edge preference logic in CordovaActivity and SystemBarPlugin#1962
GitToTheHub wants to merge 1 commit into
masterfrom
pr-revert-pr-1902-simplify-edge-to-edge-preference-logic

Conversation

@GitToTheHub

@GitToTheHub GitToTheHub commented Jun 23, 2026

Copy link
Copy Markdown
Contributor

Platforms affected

Motivation and Context

  • Android EdgeToEdge was introduced in Android 15 and should only be used from there on
  • Add small comment to the condition
  • Enabling this on pre Android 15 would create an issue on Android 7 where content is rendered behind the navigation bar, which should not happen, and results in parts of the page not being visible.
  • If the status bar should be hidden on pre Android 15 the Status Bar JS API can be used: window.statusbar.visible = false;

Description

Testing

Checklist

  • I've run the tests to see all new and existing tests pass
  • I added automated test coverage as appropriate for this change
  • Commit is prefixed with (platform) if this change only applies to one platform (e.g. (android))
  • If this Pull Request resolves an issue, I linked to the issue in the text above (and used the correct keyword to close issues using keywords)
  • I've updated the documentation if necessary

…vity and SystemBarPlugin

- Android EdgeToEdge was introduced in Android 15 and should only be used from there on
- Add small comment to the condition
@codecov-commenter

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 61.43%. Comparing base (dd3fd35) to head (7364984).

Additional details and impacted files
@@           Coverage Diff           @@
##           master    #1962   +/-   ##
=======================================
  Coverage   61.43%   61.43%           
=======================================
  Files          24       24           
  Lines        4922     4922           
=======================================
  Hits         3024     3024           
  Misses       1898     1898           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@seamlink-aalves

seamlink-aalves commented Jun 24, 2026

Copy link
Copy Markdown
Contributor

This PR makes no sense for me. The definition of edgetoedge is to have the app extend to the full edge of the device. The configuration does not say edgetoedge from android 15. It should apply to all versions of android. It up to the developer of the application to manage the inserts of the app in this case.

What the option window.statusbar.visible = false; does is hide the status bar. In edge to edge I may want to show the status bar. It is also applies to all versions of android.

@seamlink-aalves

Copy link
Copy Markdown
Contributor

Adding to my previous comment, in PR that is being reverted here (#1902), I see that this was motivated by the comment from erisu.

That PR did not just try to re-implement StatusBarOverlaysWebView but make EdgeToEdge consistent through all versions of Android.

EdgeToEdge defaults to false. If the developer enables it, it should make the necessary changes in the webapp styling.

In my case, with the previous PR and EdgeToEdge enabled the insets are managed in the style of the application in both top and bottom. The style is the same through all version of android.

@GitToTheHub

GitToTheHub commented Jun 24, 2026

Copy link
Copy Markdown
Contributor Author

Correctly, this PR is motivated by erisu's comment on PR #1902. I looked through the edge-to-edge guide of Android and thought there is a preference flag or something introduced by Android 15, which is reflected by the Cordova preference AndroidEdgeToEdge. But the guide says only that edge-to-edge is a requirement since Android 15 and that it can be anabled on older versions by WindowCompat.enableEdgeToEdge(getWindow());. So if Google gives an example to enable edge-to-edge on previous versions I think it makes sense to give the possibility to enable it on pre Android 15 with the Cordova preference AndroidEdgeToEdge.

@breautek

breautek commented Jun 24, 2026

Copy link
Copy Markdown
Contributor

Yah I don't agree with reverting PR 1902.

Enabling this on pre Android 15 would create an issue on Android 7 where content is rendered behind the navigation bar, which should not happen, and results in parts of the page not being visible.

I think this is just a safe area inset issue... when in operating in edge to edge, the developer is going to have to be mindful of screen obstructions and accommodate appropriately.

But the guide says only that edge-to-edge is a requirement since Android 15 and that it can be anabled on older versions by WindowCompat.enableEdgeToEdge(getWindow())

Android is going to enforce E2E mode on modern API levels and moving forward. Cordova however makes opting into E2E completely optional by recreating the old "system" bars such as the status bar and positioning the webview as it would have on older API levels -- so while the app is technically operating in E2E fashion the webview itself sits within the safe content area and users don't have to worry about refactoring their app to handle safe area insets.

For users that DO opt into E2E mode, I would expect that would apply to all API levels reasonably possible. That is unless if there is a strong reason not support E2E on older devices, we should support it so that app developers can get a consistent behaviour look and feel across API levels. Natively, that is exactly what WindowCompat.enableEdgeToEdge(getWindow()) does.

E2E mode in the behavioural sense is not new ... ever since Android 5 (or 6, whenever Android gave us more control over the status bar) I've been using an "E2E" look 'n' feel by having the status bar an overlay on top of the webview, and using insets to pad content appropriately. So I don't see any reason why we couldn't support E2E mode for pre android 15.

@GitToTheHub

GitToTheHub commented Jun 24, 2026

Copy link
Copy Markdown
Contributor Author

E2E mode in the behavioural sense is not new ... ever since Android 5 (or 6, whenever Android gave us more control over the status bar) I've been using an "E2E" look 'n' feel by having the status bar an overlay on top of the webview, and using insets to pad content appropriately. So I don't see any reason why we couldn't support E2E mode for pre android 15.

Thanks that you explained everything in detail. I think also, to make development for the users not harder as it should be, this should be allowed on older APIs also. Maybe I can use some things you mentioned here for documentation.

@GitToTheHub

Copy link
Copy Markdown
Contributor Author

Android is going to enforce E2E mode on modern API levels and moving forward. Cordova however makes opting into E2E completely optional by recreating the old "system" bars such as the status bar and positioning the webview as it would have on older API levels -- so while the app is technically operating in E2E fashion the webview itself sits within the safe content area and users don't have to worry about refactoring their app to handle safe area insets.

Do you mean, when Android enforces edge-to-edge it is ok to use just cordova-android 15 and let the preference AndroidEdgeToEdge to be false and Google will not complain about it, when the Android target SDK level requirement is 36?

@GitToTheHub

Copy link
Copy Markdown
Contributor Author

I updated the documentation for AndroidEdgeToEdge on PR apache/cordova-docs#1502

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.

4 participants