Repository navigation
fix(android): separate local storage between WebView processes - #106
Conversation
There was a problem hiding this comment.
Note about marking this as a breaking change / major version in the Capacitor plugin: Either the squash-commit needs to have a BREAKING CHANGE: <describe breaking change> in the commit footer so that semantic-release does the major version bump (should try a dry-run locally on main just to check), or we do a manual release.
Plus (not applicable to this PR specifically) we should create a 3.x branch before this PR is merged, but as for releasing patches in 3.x, I'm not sure how to approach this (2.x is going to latest-7, would 3.x go to latest-8, and where would 4.x go to if we do Capacitor-9 related breaking changes in a 5.x?), because up until now we've had one major version per Capacitor major version, think this will be the first plugin to break this rule. Maybe this needs to be brought up to the team internally, but mentioning it here because I think we haven't had this dicussion.
There was a problem hiding this comment.
I added the exclamation mark just in case, but will also add it to the footer of the squashed commit.
As far as the versioning, you bring up a valid point. I think in this case, we should just create a 3.x branch and merge this there along with any other Capacitor 9 upgrades we will do in the upcoming weeks. This "bug" wasn't reported by any customer / user except internally so I don't believe it is very urgent.
For future breaking changes, it will probably be a case-by-case basis, but if we target only 1 release of a major version per year for Capacitor.. then we will probably eventually run into scenarios where we will have to break the rule, especially if its an urgent bug fix or something
There was a problem hiding this comment.
I added the exclamation mark just in case
Exclamation mark won't work, because semantic-release in this repo is following Angular Commit convention, not conventional commits, where there's no "!"; I'd say probably it's best not to have one.
As far as the versioning, you bring up a valid point. I think in this case, we should just create a 3.x branch and merge this there along with any other Capacitor 9 upgrades we will do in the upcoming weeks. This "bug" wasn't reported by any customer / user except internally so I don't believe it is very urgent.
Not sure I follow. If we want to bring this fix to OutSystems, we need to update the Capacitor plugin and use it on ODC.
There was a problem hiding this comment.
Sorry I meant to advocate for making the 3.x branch, but only merge this change to main. That way it is only included with the next major release which will likely be with the other Capacitor 9 upgrades. I don't think this needs to make it into the current version since it's not as urgent and might be weird for us to be making 2 major releases for a single Capacitor version unless it's necessary, especially since there isn't a precedent and then we'd be releasing another major release right after.
I will bring it up to the team to see their thoughts because I think it is an important discussion
There was a problem hiding this comment.
Per internal discussions we're fine with raising the major version now, just keep in mind the initial comment I made that I think is still relevant regarding how to do the version bump + (and I don't think we discussed this with the team, or maybe we did and I forgot) should we keep maintaining 3.x after releasing 4.x?
There was a problem hiding this comment.
Yes I will add the BREAKING CHANGE: in the commit footer.
As far as maintenance goes for 3.x, I don't think it's absolutely necessary if we don't have the bandwidth as users can upgrade to 4.x and keep the same behavior by simply disabling isIsolated. However, it also wouldn't hurt to just cherry pick all of the changes to 3.x to be safe. In the past we have always just supported the current version and one previous major version, so if we follow that pattern then maybe we maintain it until 5.x comes out.
There was a problem hiding this comment.
The one doubt I have is what npm tag would 3.x go to? because we have been using latest-Y where Y is the capacitor framework major version that the plugin version is compatible with. Since there'd be two (3.x and 4.x), unsure where that would go
But this isn't something that we need right now I guess. As long as we have 3.x branch, we can set the rest up any other time if we find it's better to have those two versions, along with 2.x as well (for Cap 7 until later this year).
ItsChaceD
changed the title
ItsChaceD
changed the title
# [4.0.0](v3.0.3...v4.0.0) (2026-05-14) ### Bug Fixes * **android:** separate local storage between WebView processes ([#106](#106)) ([7447bf6](7447bf6)) ### BREAKING CHANGES * **android:** Android `openInWebView` now isolates WebView storage by default on Android 28+. Apps that need to share the main app WebView's `localStorage` or cookies must set `android.isIsolated` to `false`.
This PR updates the Android library to
2.0.0and documents the relevant fix for isolatinglocalStorageon Android.Context: OutSystems/OSInAppBrowserLib-Android#54
MABS 12 Capacitor (BUILD 3)
Steps to reproduce:
The new page includes the setting for IsIsolated and then a toggle for showing an iframe of a website where you can change some stored values like background color, font type, etc... Then there is a button for going to the same URL on the WebView. If storage is isolated then the values won't persist, but if it's toggled off or you are testing on an older device, then the values will be the same as the iframe.