fix: separate local storage between WebView processes

[ItsChaceD]

Description

This PR implements localStorage isolation on Android API 28+ via setDataDirectorySuffix, bringing it into alignment with iOS behavior.

Due to Android system limitations, isolation can only be achieved by running the WebView in a separate :OSInAppBrowser process with a dedicated data directory suffix. This requires events to be propagated between the processes via broadcast receivers. To avoid a breaking change, we keep the class signatures the same and add a custom @RequiresEventBridgeRegistration annotation to proactively warn native library users of the new registration requirement.

Context

https://outsystemsrd.atlassian.net/browse/RMET-4918?atlOrigin=eyJpIjoiOWI4NWVmMDIwZDhhNDRmMGJhMTljMWFlNTQxYmFkZjIiLCJwIjoiaiJ9

Type of changes

• Fix (non-breaking change which fixes an issue)
• Feature (non-breaking change which adds functionality)
• Refactor (cosmetic changes)
• Breaking change (change that would cause existing functionality to not work as expected)

Platforms affected

• Android
• iOS
• JavaScript

[OS-pedrogustavobilro]

We should make sure plugins (OutSystems especially) document this change, wouldn't be surprised if it ends up breaking existing Android apps in some unexpected way, due to the many different ways people use InAppBrowser.

[OS-pedrogustavobilro]

Actually, doesn't this mean that existing apps that have cookies or local storage data for a certain webpage in InAppBrowser, will no longer have that data when they update the app to this version where the data directory changes?

[ItsChaceD]

You're right, it may break existing apps that use InAppBrowser.. However, if we leave the current behavior then it may be a security flaw because we shouldn't give the browser access to the main app's data. So we have 2 options:

1. "Always Isolated". This fixes the security bug and also currently the plugin behaves differently on both platforms, which can lead to bugs in the app's logic.. so it makes Android behavior match iOS. Storage will persist as normal after the first run.

Document a warning saying something like (Thanks AI for the docs help 😅):

Warning

Breaking Change (Android): Apps upgrading to this version will lose any existing localStorage or cookies previously stored by the InAppBrowser. This is because the WebView now runs in a separate process with its own data directory. Users may need to re-authenticate with websites that relied on persisted session data.

2. "Opt-in" Isolation. Keep the current shared behavior as default, but add an isolateStorage config option. Best for backwards compatibility and existing data, but not the best security practice.

If you think there will be a bigger impact on customers with the first approach, then we could maybe do "opt-in" for this version and then have it always isolated for the next major version. Thoughts?

[OS-pedrogustavobilro]

If this raises security concerns then I don't think we want an opt-in.

We should just be careful on releasing this and informing customers, to make sure impacts are minimized. Hard to say on how many customers could be impacted, due to the myriad of ways and webpages and use cases you can have for InAppBrowser.

[alexgerardojacinto]

I agree. For example, some customers try to use the InAppBrowser to perform login flows (which they shouldn't, but they do).

[OS-pedrogustavobilro]

Also @ItsChaceD FYI one of the tests is broken with your PR, it passes in main branch.

test_handleOpen_withValidURL_launchesWebView_when_browserPageNavigationCompleted_then_browserPageNavigationCompletedTriggered

It's hard to tell on the CI logs because of SonarCloud integration is broken. We should take a look at SonarCloud soon, it's been broken for too long now...

[OS-pedrogustavobilro]

Overall checked the code and tested and LGTM.

We'll still need to address #54 (comment) in the coming days, but yeah I'll re-review if changes are made because of that.