Master password reprompt opens new window even in unlocked extension

[bwbug]

Steps To Reproduce

The description below assumes that "Auto-fill on page load" has been disabled.

1. Enable "Master-password re-prompt" for a login item.
2. Launch the corresponding web page.
3. Ensure that the browser extension is unlocked.
4. Use Ctrl+Shift+L to auto-fill the credentials.

Expected Result

Browser extension viewport should open, and display a modal that prompts for the master password.

Actual Result

A new browser window is launched, which displays the browser extension UI with a modal prompting for the master password.

Screenshots or Videos

No response

Additional Context

The behavior might have been expected, if the browser extension had been locked (e.g., see #5384). However, since the extension was unlocked, there is no need to open a new browser window for the purpose of requesting the credentials.

Unnecessarily using a new browser window for this purpose introduces noticeable delays in opening and closing the prompt, thus degrading the user experience.

Operating System

Windows

Operating System Version

22H2

Web Browser

Chrome

Browser Version

117.0.5938.92

Build Version

2023.9.1

Issue Tracking Info

• [X] 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 your bug report.

I empathize with the concern you've brought up regarding a noticeable delay when attempting to trigger an autofill of a master password reprompt protected item.

Originally, acting to autofill any reprompt protected item through keyboard or context menu actions would not work at all. There was logic in place to guard against attempting to fill the item due to the necessity of protecting the access of the item through a MP reprompt. The work done to allow autofill of MP reprompt guarded items is effectively what you're concerned with in this bug.

So with that said, this is working as expected. As unfortunate as it may be to the UX, opening a new window is the only way we've found to facilitate securely entering the master password through the context of the extension. We don't have any way through the extension's API to facilitate opening the extension's popup programmatically. That behavior can only be done through user action, and is something that has historically been implemented purposefully (context on the Chromium team's decision for this)

I'm closing this ticket as this is working as expected, but please let me know if you have any questions or further issues that relate and we can continue the discussion from there.

[bwbug]

@cagonzalezcs Thank you for the explanation. I have just filed a different bug report that is also related to the new pop-up feature that you contributed, if you want to take a look:

Issue 6414: Browser launches with incorrect window dimensions/position after using Bitwarden

You might also want to have a look at Issues #6389 and #6401 (which have been closed, but which I believe should be re-opened, and merged with each other).

[zacjohnston]

I've experienced a similar change in behavior but I'm not sure if it's the same issue/same explanation.

My standard method of unlocking the extension in a new browser session was to wait until I needed to auto-fill a password, press Ctrl+Shift+L, then type the MP into the small extension window that opens.

Now doing the same thing opens an entirely new chrome window, which feels like much uglier/clunkier behavior than the sleek little extension window (which is still accessible if you manually click the icon?).

I don't understand why this change was necessary.

[bwbug]

@zacjohnston Previously, if attempting to use Ctrl+Shift+L while the extension was locked, Bitwarden would actually open a new browser tab in your current browser window (unless you were using Incognito mode, in which case it would open a new browser window — albeit a full-size one that used your default browser window dimensions and location). So you may be misremembering.

[zacjohnston]

@bwbug Nope, not misremembering. Perhaps it behaved differently for other systems for some reason, but I did this multiple times every day for over a year on both Linux and Windows. It was extremely noticeable and jarring when it changed to being a new Chrome window a few days ago.

In fact, the only times it would open a tab for me was in incognito mode, which was annoying enough that I usually made sure to unlock in the default browser first.

[bwbug]

@zacjohnston Not sure how you managed this, since @cagonzalezcs claims it can't be done. In case my memory was off, I just tested this by side-loading version 2023.8.3 in Chrome on a Windows 10 VM. With the vault logged out, and using Chrome in regular mode (not Incognito), Ctrl+Shift+L definitely opens a new tab in the browser. Also, note that the PR that implemented the recent change in behavior is titled Open login form used to unlock extension in a separate window instead of a tab.

Are you sure you're not thinking of the Ctrl+Shift+Y shortcut (which still works as it did previously)?

[cagonzalezcs]

I've experienced a similar change in behavior but I'm not sure if it's the same issue/same explanation.

My standard method of unlocking the extension in a new browser session was to wait until I needed to auto-fill a password, press Ctrl+Shift+L, then type the MP into the small extension window that opens.

Now doing the same thing opens an entirely new chrome window, which feels like much uglier/clunkier behavior than the sleek little extension window (which is still accessible if you manually click the icon?).

I don't understand why this change was necessary.

@zacjohnston

As mentioned by @bwbug, we are unfortunately limited in how we can programmatically open the extension popup window. If I could facilitate your described workflow, I would definitely have opted to open it in that manner instead of in a new window.

The decision to open the unlock view in a new window instead of a tab was made to avoid the sudden and complete context switch that was occurring when a user attempted to auto-fill on a tab with a locked/logged out extension. Equally, we were seeing a variety of issues present when users attempted to unlock their extension from an incognito mode window which opened the unlock view in a new tab. These fix resolved those two issues in conjunction.

Originally, we also implemented this with the trimmed down popup view that you can facilitate through the extension. However, an important issue was pointed to with opening the window using that method. When opening windows through the extension as a popup as opposed to a normal window, the URL for the window would be removed entirely. This appears to be done by design in all browsers.

We are concerned with potential spoofing of the window opening action, and the one of the easiest "non-technical" ways to verify that you are entering your master password into our extension is by viewing the URL of the page. Below you can see the two type of windows that an extension can programmatically open. You'll see that the regular popup window does not contain the URL in place.

This is why we went ahead with the "uglier/clunkier" UX of a full window instead of a popup window.

[zacjohnston]

@cagonzalezcs thanks for the detailed explanation, I see it's an unfortunate constraint.

[KiitoX]

Using a regular window instead of a popup has serious drawbacks in my opinion, and does not resolve potential spoofing on Firefox. With just a few add-on icons in the toolbar, the page URL and extension badge are almost completely hidden: And even with more than sufficient spacing, the add-on name in the badge stays elided:

As noted, popups opened by extensions are displayed without URL bar. Arguably this is not great, but it is a meaningful differentiator to popups opened by "regular" pages. These must always show the URL and whatever appropriate badging, and also cannot open a moz-extension:// URL.

Using the extension popup leaves open that another extension spoofs the popup as such, but the separate window has just the same problem.

Now I understand that we would like to eliminate that vector, but the extension URL is simply not usable for verification of trust at this point, especially for "non-technical" users.

[Mukhilm]

I am using the latest version of the extension (2023.9.2) in chrome on Ubuntu. I've noticed after the change to the behavior to open a new window for master password re prompt logins the new window opens even when I am already logged into a site. This will keep opening a new window every time I click a link on a web page like amazon, facebook etc, which makes these sites practically unusable. The reprompt window should not be opening up on sites I've already logged into. I've had to disable the autofill since it breaks site usability.

[cagonzalezcs]

@Mukhilm

The issue you're experiencing is a known issue, and is fixed within an upcoming release. A work-around and explanation of the issue can be found within this comment..

@KiitoX

Truly, thank you for the feedback on this. I've spoke with our team regarding your comment and have pushed up a PR that has these windows opening as popup type windows rather than normal type windows.

Our concerns regarding spoofing still exist, but we're looking at mitigating that in a different manner given that the URL itself does not provide a very effective way of solving the problem, and how many issues are appearing when these windows open as normal type windows.

We still have some approvals and QA that are being worked on for this ticket, but we're hoping to have the change within the upcoming release.

[fiskfisk33]

Couldn't there simply be a setting to use the old behaviour?

[bwbug]

@fiskfisk33 Why would you want the old behavior instead of the behavior that is being implemented in PR #6600?

[Jamie4224]

@bwbug An example is this issue: https://github.com/bitwarden/clients/issues/6707#issuecomment-1784177023

[bwbug]

@Jamie4224 But your edit in that comment says that #6600 did fix your issue, so it's still not clear why anybody would prefer the old behavior to the behavior in #6600...

[fiskfisk33]

@fiskfisk33 Why would you want the old behavior instead of the behavior that is being implemented in PR #6600?

I meant the old behaviour where it opened up the extension dropdown instead of a new window.

[cagonzalezcs]

@fiskfisk33

As mentioned by @bwbug on this comment, that was not how master password re-prompt or unlocking from an autofill action would work.

Originally, master password re-prompt would fail silently as opposed to opening a new tab or window to facilitate the behavior. Equally, unlocking the extension from an autofill action (keystroke or context menu) would open a new tab entirely which was a jarring context switch for users.

You can still use Ctrl+Shift+Y instead if you prefer to unlock the extension without a popout window in place. Aside from that, thank you for the feedback and we will keep it in mind while continue to work towards a better user experience.

[scottwillmoore]

@cagonzalezcs

I could've sworn that Ctrl+Shift+L used to open the extension drop-down, not a new tab. Anyway, given that Ctrl+Shift+L did open a new tab, it appears to have been updated to open a new window (#5384, #6600).

But, I don't understand why the extension drop-down cannot be used? You explained above that it was due to the extension API not allowing you to open the extension drop-down? However, if this is the case, why does Ctrl+Shift+Y still allow you to open the extension drop-down? Can Ctrl+Shift+L not use the same process?

Also, I understand that the new behavior (open in a new window) is more obvious, but I think I would prefer the old behavior (open in a new tab)...

• With a full-screen window on MacOS with Firefox, a new window takes you out of full-screen. In addition, I use the extension Sidebery, and the side-bar covers 80% of the new window due the the dimensions that you have set.

• Also, if users use a tiling window manager the new window approach would also be annoying and ugly for them.

It would be great if you could make the extension drop-down work, otherwise at least provide experienced users the option to use a new tab instead of a new window.

[zacjohnston]

@scottwillmoore

I could've sworn that Ctrl+Shift+L used to open the extension drop-down

I also could have sworn so, and was happy to see an apparent return to this old behaviour, but I realize now reading #6600 that it was actually just a minimal popup type window, as opposed to a normal type browser window with the URL bar/bookmarks/etc.

I wasn't aware this distinction existed so I mistook the popup window for the similar-looking extension drop-down.

[cagonzalezcs]

But, I don't understand why the extension drop-down cannot be used? You explained above that it was due to the extension API not allowing you to open the extension drop-down? However, if this is the case, why does Ctrl+Shift+Y still allow you to open the extension drop-down? Can Ctrl+Shift+L not use the same process?

To make a long story short, Ctrl + Shift + Y triggers a specific extension command that opens the popup through a distinct user action. However, opening the popup through other programmatic means is not possible, even if you try to tie that behavior to a separate user action.

I provided a bit more historical context for these questions on the following comment: https://github.com/bitwarden/clients/issues/6414#issuecomment-1765405255

I'll re-iterate, if we could open the popup to facilitate this behavior we would go with that approach without hesitation. Currently that is not possible to do.

With a full-screen window on MacOS with Firefox, a new window takes you out of full-screen. In addition, I use the extension Sidebery, and the side-bar covers 80% of the new window due the the dimensions that you have set.

Please feel free to file a Github Issue for this problem, and the Autofill team can look into a resolution for it.

Also, if users use a tiling window manager the new window approach would also be annoying and ugly for them.

I appreciate this concern, but given that these types of windows are meant to be temporary in purpose, it seems like a nitpick to keep in consideration. If users find the popout window aesthetically unpleasing, they can opt to avoid using them entirely by using Ctrl + Shift + Y or by clicking the extension icon instead and facilitate their interactions with the extension through the extension popup instead.

It would be great if you could make the extension drop-down work, otherwise at least provide experienced users the option to use a new tab instead of a new window.

Thank you for the suggestion, we will continue to work to refine and improve this behavior over time. I can bring this up with our team, however, choosing to fragment the user experience for this type of workflow is a design-specific decision that is out of my hands.