Bug Report
Plugin(s)
@capacitor/browser 7.0.0
- Also reproduced on
@capacitor/browser 7.0.5
- Based on code inspection, the same issue appears to still exist in the current v8.x implementation.
Capacitor Version
@capacitor/core: 7.6.2
@capacitor/android: 7.6.2
@capacitor/cli: 7.6.2
@capacitor/ios: 7.6.2
Platform(s)
- Android (reproduced on physical devices)
- Not reproducible on iOS or Web
Current Behavior
Browser.open() works correctly the first time it is invoked.
After the Chrome Custom Tab is dismissed, calling Browser.open() again causes the Custom Tab to briefly appear and then immediately close, resulting in a visible flicker. Every subsequent invocation exhibits the same behavior.
While debugging, I traced the issue to the Android implementation in EventGroup.java. The lifecycle handling appears to incorrectly unregister listeners after the first BrowserControllerActivity lifecycle, causing the Chrome Custom Tab to close prematurely.
Expected Behavior
Browser.open() should consistently open a Chrome Custom Tab every time it is called, regardless of how many times it has been opened and dismissed previously.
Code Reproduction
- Call
Browser.open().
- Close the Chrome Custom Tab.
- Call
Browser.open() again.
- Observe that the Custom Tab briefly opens and immediately closes.
Other Technical Details
-
Browser.close() is not a valid workaround on Android, as the documentation explicitly states that it is supported only on Web and iOS.
-
The behavior is identical on @capacitor/browser 7.0.0 and 7.0.5.
-
I compared the Android implementation between v7.0.0 and v7.0.5 and found no changes related to this behavior.
-
Existing application workaround:
- On Android, replacing
Browser.open() with cordova.InAppBrowser.open(url, "_system") completely avoids the issue because it launches the system browser instead of using Chrome Custom Tabs.
- The application falls back to
Browser.open() only if cordova.InAppBrowser is unavailable.
Additional Context
This appears to be the same underlying issue discussed in:
While investigating, I identified the problematic logic in EventGroup.java where the event lifecycle handling causes listeners to be removed prematurely after the first browser session.
If useful, I can also submit a PR with the proposed fix or validate any candidate fix against our production application.
Bug Report
Plugin(s)
@capacitor/browser7.0.0@capacitor/browser7.0.5Capacitor Version
Platform(s)
Current Behavior
Browser.open()works correctly the first time it is invoked.After the Chrome Custom Tab is dismissed, calling
Browser.open()again causes the Custom Tab to briefly appear and then immediately close, resulting in a visible flicker. Every subsequent invocation exhibits the same behavior.While debugging, I traced the issue to the Android implementation in
EventGroup.java. The lifecycle handling appears to incorrectly unregister listeners after the firstBrowserControllerActivitylifecycle, causing the Chrome Custom Tab to close prematurely.Expected Behavior
Browser.open()should consistently open a Chrome Custom Tab every time it is called, regardless of how many times it has been opened and dismissed previously.Code Reproduction
Browser.open().Browser.open()again.Other Technical Details
Browser.close()is not a valid workaround on Android, as the documentation explicitly states that it is supported only on Web and iOS.The behavior is identical on
@capacitor/browser7.0.0 and 7.0.5.I compared the Android implementation between v7.0.0 and v7.0.5 and found no changes related to this behavior.
Existing application workaround:
Browser.open()withcordova.InAppBrowser.open(url, "_system")completely avoids the issue because it launches the system browser instead of using Chrome Custom Tabs.Browser.open()only ifcordova.InAppBrowseris unavailable.Additional Context
This appears to be the same underlying issue discussed in:
While investigating, I identified the problematic logic in
EventGroup.javawhere the event lifecycle handling causes listeners to be removed prematurely after the first browser session.If useful, I can also submit a PR with the proposed fix or validate any candidate fix against our production application.