Browser launches with incorrect window dimensions/position after using Bitwarden in Incognito mode

[bwbug]

Steps To Reproduce

1. Open a browser in regular (non-Incognito) mode.
2. Customize your browser window dimensions, position, and state (maximized or not maximized).
3. Close and relaunch the browser to confirm that the preferred window dimensions, position and state are remembered.
4. Open an Incognito browser window (and confirm that the window dimensions, position, and state are still correct).
5. While in Incognito mode, use Bitwarden in a way that triggers the prompts implemented in PR 5384 or PR 5621 (e.g., use Ctrl+Shift+L for an item that has "Master password re-prompt" enabled, or lock the browser extension and use Ctrl+Shift+L on any website).
6. Close the browser.
7. Re-launch the browser, either in regular mode or in Incognito mode.

Expected Result

The customized browser window dimensions that had been set in Step 1 should till be remembered, restoring the browser window to the preferred dimensions, position and state.

Actual Result

The browser window always opens as a non-maximized, small window, with a position and dimensions that mimic the browser extension viewport.

Screenshots or Videos

No response

Additional Context

Actions taken in the browser extension should not affect how the browser behaves next time that it is launched. This is not only counter-intuitive, but creates a lot of extra work for the user to repeatedly have to manually correct the dimensions and position of the browser window.

If an incognito window is resized or repositioned, then the new settings are not saved when the browser is closed. However, the browser window that is launched for purposes of prompting for Bitwarden credentials is a regular window (not Incognito mode), so its reduced dimensions are saved and re-used the next time the browser is launched. Thus, if browsing in Incognito mode, there is no way to fix the problem without leaving Incognito mode, opening a regular browser window, manually fixing the location and size of the window, and then returning to Incognito mode.

To solve the problem, the miniature browser window that pops up to prompt for Bitwarden credentials should be launched as an Incognito browser window, not a regular window. At the very least, this should be the behavior if the browser extension process the triggered the pop-up was running in the context of an Incognito browser window.

Operating System

Windows

Operating System Version

22H2

Web Browser

Chrome

Browser Version

117.0.5938.92

Build Version

2023.9.1

Issue Tracking Info

• I understand that work is tracked outside of Github. A PR will be linked to this issue should one be opened to address it, but Bitwarden doesn't use fields like "assigned", "milestone", or "project" to track progress.

[cagonzalezcs]

@bwbug

Thank you for the bug report. This is a good callout, and while reading your post I'm positive that this bug is happening as described. I haven't replicated it yet, but I'm pretty sure it'd be easy to do knowing what I know about how browsers work. I'll work on replicating it after writing this post.

Now with that said, this "bug" comes from how browsers "remember" window dimensions for the most recently opened window at the start of a fresh browsing session. Our extension is effectively opening a new window and resetting those values, and if another window is not opened before the session/app is closed, then yes it will treat our window's position and dimensions as the initial window's dimensions on launch.

This isn't something that is easy to avoid, to be honest. It's possible that if we were able to leverage the chrome.windows.open api with a window type of popup, that we could avoid this cached window behavior. However, as I mentioned in another issue, we're concerned with potential spoofing of those opened windows, so we're not inclined to leverage those window types.

Beyond that, the suggestion you made here was to launch the window from the incognito session rather than from the main browser session. That's something we've explored as well.

What needs to be kept in mind is that when browsing with an incognito session, by default any browser extensions that are active run as if they were running in the main browsing context, not the incognito context. By default extensions run in a spanning mode that shares the single process.

You can modify the extension to run in a split mode, which facilitates the approach that you're discussing. However, in effect it forces two different instances of the extension, one for the incognito mode and one for the main browsing context. This has many implications, the most significant of which would be inconsistencies in synced data between the two instances. It also presents a significant performance impact due to the overhead of having two identical processes running side by side.

I'll keep this issue open for now to facilitate feedback and discussion. I'll also try to look into the problem a bit when possible.

[bwbug]

@cagonzalezcs Thank you for your response.

I had thought this would be a simple matter of setting createData.incognito = true.

I'm not sure I fully understand the limitations that you are describing. If I run the browser extension in an Incognito window and manually launch a second Incognito window, why would this not create the same issues that you are concerned with (e.g., inconsistencies in syncing) — in any case, the pop-up window used for unlocking will close itself immediately, so there would be no opportunity to create vault changes that result in sync issues.

Be that as it may, as an alternative approach, would it be possible to read the current window dimensions before creating the pop-up, and then restoring these values to the cache after the pop-up closes?

If that is not possible, then as a last resort, I would suggest either a user-settable option for disabling the resizing of the pop-up window (so that the new window takes on the default dimensions, instead of mimicking the browser extension viewport), or simply disabling the resizing automatically for any session that is running in Incognito mode. This would in essence make the behavior identical to the previous behavior (prior to PR 5384 and 5621) for users who browse in Incognito mode.

[bwbug]

@cagonzalezcs

I'll keep this issue open for now to facilitate feedback and discussion.

Since it has been a week, I am wondering if you have any comments or responses to the suggestions/question in the post above?

In addition, going back to the original impetus for these recent PRs, can you (or anybody else reading this) explain why it is that the keyboard shortcut Ctrl+Shift+Y can open the browser extension pop-up viewport to the unlock page, but evidently, the Ctrl+Shift+L shortcut cannot do the same?

[cagonzalezcs]

@bwbug

Sorry for the incredibly late reply, last week I was on vacation and the week before I was pushing pretty hard on getting another project ready for review by the team.

So I was completely right in saying that the issue would be fixed by setting these windows to be a popup type rather than a normal type. We have a PR in place that addresses the issue in this thread, which should be going in for the upcoming release.

In addition, going back to the original impetus for these recent PRs, can you (or anybody else reading this) explain why it is that the keyboard shortcut Ctrl+Shift+Y can open the browser extension pop-up viewport to the unlock page, but evidently, the Ctrl+Shift+L shortcut cannot do the same?

So there appears to be a bit of history to this kind of request including resistance to allowing developers to open the the popup bubble programmatically. At some point, it was decided to allow extension developers the ability to facilitate a shortcut for opening the popup. However, there is no in production API that facilitates the same behavior with different methodologies or events.

Now that said, there is an API that is currently in development for Chromium browsers that could facilitate the behavior. However, that API is still in active development and only available in dev channels. Also, it is only going to be available within manifest v3 so Bitwarden will need to put in the effort to fully migrate to that version of extension before we can use it in any regard. Equally, I'm not entirely sure how support will work for Firefox and Safari, there could be a bit of a time gap before those browsers implement a similar method for programmatically opening the popup.

So with all that said, as I mentioned the PR above should resolve this issue. For now I'm closing this thread. If any further issues arise, please let me know and we can reopen this issue.