Adding in the edge to edge behavior that comes standard with cordova-android to our OutSystems branch.

[OS-kepatotorica]

Platforms affected

Android

Motivation and Context

Description

This is bringing a more legacy appearance to applications running in edge to edge, unless they specifically opt into edge to edge mode. This will be combined with our native shell and a new plugin that will automatically inject css variables with inset values that will allow users to go edge to edge and do with the edges what they want.

Testing

I tested several versions of android with and without the new flag, and tested against an OutSystems application.

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

[chaodin]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scanner	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues
✅	Code Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[tafelnl]

See ionic-team/capacitor#8121 and ionic-team/capacitor#8180 (comment) for feedback on this approach

[OS-kepatotorica]

See ionic-team/capacitor#8121 and ionic-team/capacitor#8180 (comment) for feedback on this approach

For the approach that you linked, I see a few problems. One, we will have an inconsistent user experience between people using different versions of the webview. Two, padding is being applied automatically instead of passing the responsibility on to users for a truly edge-to-edge experience. Three, removes control from the web developer to make their webview look how they would like. Four, if a user is developing an app on a new webview version and decides to use the env variables to provide custom styling, the app they release could have double handling of the insets on devices running older versions of the webview, as the env variables still exist with values, albeit incorrect values, but they are still there.

We went with a different approach that is more closely aligned with what Apache has decided to do on their side. We use a Cordova preference AndroidEdgeToEdge to determine if an app should be drawn in a legacy fashion, instead of having a breakpoint on a webview version. Not only that, but we also decided to inject CSS variables that have the correct values if a user decides to run in edge-to-edge mode. The combination of these two things means that we enforce a more predictable look across different devices, as well as give web developers the ability to style their content as they see fit without worrying about incorrect inset values that are provided by the environment.

Long term we will remove the CSS injection in favor of just using the env CSS variables, but since we can't force users to update anything our goal is to reduce breaking changes, and provide a path forward for consistent behavior across devices.

[tafelnl]

Thank you for taking the time to look at the other approach!

One, we will have an inconsistent user experience between people using different versions of the webview.

You mean that users with a chromium version below m140 will not have full edge to edge support right? I agree that that is suboptimal indeed. But since chromium is an evergreen browser and thus the majority of users will have the most recent version, I think this is a non-issue. Or at the very least the pros will outweigh the cons IMO

Two, padding is being applied automatically instead of passing the responsibility on to users for a truly edge-to-edge experience.

This is only true for users with a webview version < m140. For webview >= m140 (and if the meta tag viewport-fit=cover is present), it will be the developers responsibility to make sure edge-to-edge is working correctly. So this works exactly the same as how it works on iOS and web out-of-the-box already

Three, removes control from the web developer to make their webview look how they would like.

Again, this is only the case for webview version < m140. Maybe you misunderstood the code where these insets are not consumed from webview version >= m140? That is checked in this line. If the webview support it, the insets are not consumed and passed on to the webview.

Four, if a user is developing an app on a new webview version and decides to use the env variables to provide custom styling, the app they release could have double handling of the insets on devices running older versions of the webview, as the env variables still exist with values, albeit incorrect values, but they are still there.

This is not the case luckily. If a webview version < m140 is found, the insets are consumed. So the webview insets will always be 0px. On the other hand, for webview version >= m140, the insets will be correctly passed through and be set correctly,

---

I'm not sure about breaking changes, as I'm not sure how it works currently. If currently the approach is to use var(--safe-area-inset-*) it's a fair point to keep it that way. But even then there might be ways to deprecate that approach and advocate for the native approach

[OS-kepatotorica]

Thank you for taking the time to look at the other approach!

One, we will have an inconsistent user experience between people using different versions of the webview.

You mean that users with a chromium version below m140 will not have full edge to edge support right? I agree that that is suboptimal indeed. But since chromium is an evergreen browser and thus the majority of users will have the most recent version, I think this is a non-issue. Or at the very least the pros will outweigh the cons IMO

Two, padding is being applied automatically instead of passing the responsibility on to users for a truly edge-to-edge experience.

This is only true for users with a webview version < m140. For webview >= m140 (and if the meta tag viewport-fit=cover is present), it will be the developers responsibility to make sure edge-to-edge is working correctly. So this works exactly the same as how it works on iOS and web out-of-the-box already

Three, removes control from the web developer to make their webview look how they would like.

Again, this is only the case for webview version < m140. Maybe you misunderstood the code where these insets are not consumed from webview version >= m140? That is checked in this line. If the webview support it, the insets are not consumed and passed on to the webview.

Four, if a user is developing an app on a new webview version and decides to use the env variables to provide custom styling, the app they release could have double handling of the insets on devices running older versions of the webview, as the env variables still exist with values, albeit incorrect values, but they are still there.

This is not the case luckily. If a webview version < m140 is found, the insets are consumed. So the webview insets will always be 0px. On the other hand, for webview version >= m140, the insets will be correctly passed through and be set correctly,

I'm not sure about breaking changes, as I'm not sure how it works currently. If currently the approach is to use var(--safe-area-inset-*) it's a fair point to keep it that way. But even then there might be ways to deprecate that approach and advocate for the native approach

I can't provide all the context to why we want to go this direction for our fork, but we have some reasons around why this is our preferred path. I am going to close this PR due to an issue with the cherry-picks. Here is the new one: #28. For our purposes, though, we will be keeping the injected CSS variables. We are also trying to keep this fork as closely aligned to the base as possible, which uses the preference based edge to edge. I do appreciate your feedback though, and thank you for taking a look!