Skip to content

migrate to v3 manifest #366

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 35 commits into from
Mar 31, 2025
Merged

Conversation

patgmiller
Copy link
Contributor

@patgmiller patgmiller commented Mar 23, 2025

Closes #320 #336

patgmiller and others added 16 commits March 22, 2025 20:44
…vice worker

remove mythril from helpers, no access to window
update for storage api changes
chrome.browserAction => chrome.action.
@patgmiller
Copy link
Contributor Author

@maximbaz @erayd here's the PR for the v3 manifest

@patgmiller
Copy link
Contributor Author

I've tested in chrome (Version 134.0.6998.119 (Official Build) (arm64)) and firefox (134.0 (aarch64))

@maximbaz
Copy link
Member

maximbaz commented Mar 23, 2025

Thanks! Some testing, admittedly without actually looking at the code yet:

  1. I don't experience any popups on gravatar.com logins... I suppose you have fixed it?
  2. Open page that requires basic auth => detached popup opens => close this detached popup without selecting anything => this popup won't ever reappear, it's no longer possible to login to website with basic auth.
  3. When I created a password entry eviltester.com, it shows up in the popup on https://testpages.eviltester.com/styled/auth/basic-auth-test.html before I press the link in the bottom, but once I press the link in the bottom and detached popup opens, the entry is not there (as if it doesn't match the domain). If I create a password entry testpages.eviltester.com instead, then it shows up in both places.

@Jassob
Copy link

Jassob commented Mar 24, 2025

I've installed the extension and will start testing it both in Firefox and Chrome on x86_64.

Is there any specific work flows I should look for? I'm mainly using Ctrl+Shift+L and Ctrl+Shift+F.

@maximbaz
Copy link
Member

maximbaz commented Mar 24, 2025

Any bit of testing helps to build confidence, if you spot something weird in your usage, please report back. If you otherwise want to try whatever functionality is easy to test (copy to clipboard, edit passwords, etc), please do it 🙏

@patgmiller I wonder if we should update the part in background.js that handles Ctrl+G? Whatever code is there is probably not working anymore, as it tries to inject basic auth credentials into request?

I'm contemplating whether removing Ctrl+G entirely is a good idea 🤔 If yes now is the best time ever to do it - this shortcut was after all primarily added to enable basic auth flow. But I just don't know if and how many people (ab)use this to use browserpass as a bookmark manager, and whether we should keep it because of that...

@patgmiller
Copy link
Contributor Author

@patgmiller I wonder if we should update the part in background.js that handles Ctrl+G? Whatever code is there is probably not working anymore, as it tries to inject basic auth credentials into request?

I'm contemplating whether removing Ctrl+G entirely is a good idea 🤔 If yes now is the best time ever to do it - this shortcut was after all primarily added to enable basic auth flow. But I just don't know if and how many people (ab)use this to use browserpass as a bookmark manager, and whether we should keep it because of that...

@maximbaz At the very least I would remove the blocking auth part of that shortcut so that it only opens the url in new tab. At that point the updated flow would automatically take over. There's no reason to try and inject anything, I did a lot of experimenting with inject script while trying to make stuff work, later to learn all "error" responses block extension script injection, makes perfect sense. In this case, needs auth is the response to a 400 error (either 401 or 403 depending).

I can't speak to usage case for Ctrl+G though I can see how some people might like to keep it. It's your call really, I'll support whatever you decide.

@patgmiller
Copy link
Contributor Author

patgmiller commented Mar 25, 2025

Thanks! Some testing, admittedly without actually looking at the code yet:

  1. I don't experience any popups on gravatar.com logins... I suppose you have fixed it?

Yes, sorry I mentioned it, but I also quickly submitted the PR.

  1. Open page that requires basic auth => detached popup opens => close this detached popup without selecting anything => this popup won't ever reappear, it's no longer possible to login to website with basic auth.

I'll look at it, I have an idea what it might be.

  1. When I created a password entry eviltester.com, it shows up in the popup on https://testpages.eviltester.com/styled/auth/basic-auth-test.html before I press the link in the bottom, but once I press the link in the bottom and detached popup opens, the entry is not there (as if it doesn't match the domain). If I create a password entry testpages.eviltester.com instead, then it shows up in both places.

Thanks for the feedback, I'll test it against this example specifically, that's what I need, different approaches to break it 😉

@maximbaz
Copy link
Member

I can't speak to usage case for Ctrl+G though I can see how some people might like to keep it. It's your call really, I'll support whatever you decide.

OK let's not remove the functionality, but make it a noop, do nothing else except opening a tab. For bonus points, if it's easy and we have infrastructure for this, it would be very nice to show a deprecation warning for this, e.g. something like when people press Ctrl+G or Ctrl+Shift+G, popup says something like "Ctrl+G and Ctrl+Shift+G shortcuts are deprecated and will be removed in future version. You no longer need to open websites that require basic auth using these shortcuts, open websites normally and Browserpass will open a popup for you to choose the credentials.".

At the very least I would remove the blocking auth part of that shortcut so that it only opens the url in new tab.

I know you know, but just to be super explicit here, Ctrl+G opens in the current tab and Ctrl+Shift+G opens in a new tab :)

@patgmiller
Copy link
Contributor Author

Both of these items are at least be improved, if not fixed. See if you can break them.

  1. Open page that requires basic auth => detached popup opens => close this detached popup without selecting anything => this popup won't ever reappear, it's no longer possible to login to website with basic auth.

@maximbaz this could also happen if someone forgets they already have a window detached popup open, do we need to add a 15 min timeout to close window anyway?

  1. When I created a password entry eviltester.com, it shows up in the popup on https://testpages.eviltester.com/styled/auth/basic-auth-test.html before I press the link in the bottom, but once I press the link in the bottom and detached popup opens, the entry is not there (as if it doesn't match the domain). If I create a password entry testpages.eviltester.com instead, then it shows up in both places.

@patgmiller
Copy link
Contributor Author

basically give a bit to resolve this because it's causing problems with filling the passwords at the moment.

@maximbaz false alarm ☝🏻 , it was a red herring and not what was causing my issue. I also went back through history. I found that exact log present during all of my videos and even @CarloWood's screenshot of the logs. If I think back over this and my last PR (add / edit) I can recall it being there too now. So I'd like to find it, but don't think it should hold anything up anymore.

I've just about got my work to warn about the non https protocol for auth requests and will push that shortly.

@patgmiller
Copy link
Contributor Author

@maximbaz so here's what I didi. I've adjusted the modal dialog to also use the style class to have warning / error like the notifications. Here's what it will look like if the user ends up on an auth request with out https

Screenshot 2025-03-29 at 12 16 41 PM

@patgmiller
Copy link
Contributor Author

Currently the only thing I have not done is to increase the height of the window when the modal dialog opens and the window is too small. I will still try and get to it, later today or tomorrow but if not I'll defer to you on if you decide not to hold up the PR for it.

I have tested that the async auth request is still working in both chrome and firefox after my latest changes as well as the other features to fill fields, copy secrets, add and edit, and confirmed that the clipboard is reset after copying password or username.

@maximbaz
Copy link
Member

That's fantastic!

Just to clarify, I wrote about the deadline mostly to avoid harming your motivation and to give you assurance that I do not intend to repeat our experience with dragging the PRs for too long - for my sake, I'm perfectly happy to wait for your sign-off, it doesn't have to be tomorrow :) If you would like to get that piece done, let's get it in, and don't worry or feel like you have to rush anything - we all, watching this PR and related issue, feel nothing but gratitude for your work, and we will give you whatever time you need.

@patgmiller
Copy link
Contributor Author

ah, got it that makes sense. sounds great! I shouldn't need much longer I feel like it's really close 🤞🏻

@patgmiller
Copy link
Contributor Author

patgmiller commented Mar 31, 2025

modal window content resize is well underway and will also address it for notificaitons #336

Chrome dialog redraw

chrome-modal-window-resize.webm

Firefox dialog redraw

firefox-modal-window-resize.webm

Error notification redraw

chrome-modal-window-resize-on-notification.webm

@patgmiller
Copy link
Contributor Author

@maximbaz okay that should be it. we probably need a final round of testing and you might want to go over my changes since your last review.

Please note this change, I needed to switch back to the user agent approach, since i ran into some errors accessing the url in certain situations.

/**
 * returns true if agent string is Chrome / Chromium
 *
 * @since 3.10.0
 */
function isChrome() {
    const ua = navigator.userAgent;
    const matches = ua.match(/(chrom)/i) || [];
    if (Object.keys(matches).length > 2 && /chrom/i.test(matches[1])) {
        return true;
    }
    return false;
}

@maximbaz
Copy link
Member

Thanks! Could you please share one or few examples where user agent check is necessary? It would help to know this if some support tickets arise, or if we try to find a third approach later for whatever reason.

@patgmiller
Copy link
Contributor Author

Thanks! Could you please share one or few examples where user agent check is necessary? It would help to know this if some support tickets arise, or if we try to find a third approach later for whatever reason.

This one was the most prominent:

Uncaught (in promise) Error: Cannot access a chrome:// URL background.dist.js:497

This is basically when the user is on the manage chrome extension page, chrome://extensions/?id=..., and attempts to decrypt the secret. In this case what I remembered was the difference between the two approaches is with the user agent approach they could at least decrypt their secret, but with the URL method they could not.

However this morning, when I attempt to duplicate the issue I can decrypt the secret just fine using either approach. So it is possible I was hitting some other use case due to whatever state the changes were in at the time.

I remember wondering if it had to do with chrome-extension:// and host permissions but didn't feel like chrome-extension://*/* was an appropriate host permission request. So I double checked the gobridge host permission manifest and that has the same permissions as ours "host_permissions": ["http://*/*", "https://*/*"],. So I doubt that is the issue.

In the end, because some chrome urls are blocked, I felt that though the url approach more simple, it could potentially be more error prone. But at the moment, I feel like keeping a reference to both until it can be said for sure what issues each might have.

@maximbaz
Copy link
Member

I see, thanks! I think since browserpass is not expected to work on special pages anyway, maybe it's better to ship with the simpler url based approach, and wait to see whether anyone hits an actual issue 🤔 I just worry about long rabbit hole issues due to people changing their user agents...

@patgmiller
Copy link
Contributor Author

Okay, switched it back to simple url approach but left the other commented out for reference with a comment that if issues arise we can revisit/remember the discussion.

@maximbaz
Copy link
Member

Just to confirm, is there anything else you want to do, or is it ready for merge?

@patgmiller
Copy link
Contributor Author

Just to confirm, is there anything else you want to do, or is it ready for merge?

Nothing else needs to be done, I'd say it's ready to merged.

@maximbaz maximbaz merged commit ba67b7d into browserpass:master Mar 31, 2025
@erayd
Copy link
Collaborator

erayd commented Mar 31, 2025

Wow, I have missed a lot here! Just saw a security alert on the Browserpass release accounts, went to check what it was, and found all this. Looks like I have been missing GitHub notifications for this repo for a while; that is now rectified.

Apologies for my absence, and thank you very much indeed @patgmiller and @maximbaz for getting the v3 update over the line!

@maximbaz
Copy link
Member

Hello 👋 I've just submitted the extensions to Mozilla (has already been approved) and Google.

Even thought it's already merged, if you'd like to do a code review at any point, it will be very appreciated 🙂 We can take all the improvements in the next PR!

Also the README needs to be updated, with all the new permissions and the new way of handling modal HTTP auth (just realized this as I went through the exercise of submitting justifications to Google 😁 )

@erayd
Copy link
Collaborator

erayd commented Mar 31, 2025

Even thought it's already merged, if you'd like to do a code review at any point, it will be very appreciated 🙂 We can take all the improvements in the next PR!

Can do 🙂

...the new way of handling modal HTTP auth...

I just tested this, and it is NICE! Much more user-friendly than the launch-from-hotkey method we had previously.

@erayd
Copy link
Collaborator

erayd commented Mar 31, 2025

@maximbaz Are you still on Wire?

Copy link
Collaborator

@erayd erayd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice job - thank you, @patgmiller!

@@ -89,13 +89,91 @@ chrome.commands.onCommand.addListener(async (command) => {
}
});

let currentAuthRequest = null;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This could use a comment explaining why it isn't a race condition (i.e. that the onAuthRequired listener prevents it getting stepped on).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good question, I wondered near the end of this task if I shouldn't adjust functionality to follow your original approach using something similar to authListeners[tabId];. I will do some additional investigation / research on this and get back to you about it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Potentially relevant: #374 where multiple popups get shown for the same tab

document.execCommand("copy");
async function copyToClipboard(text, clear = true) {
if (helpers.isChrome()) {
await setupOffscreenDocument("offscreen/offscreen.html");
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does Firefox not support clipboard from offscreen? If it does, IMO it would be sensible to unify this and have all browsers use the same code path for it, rather than making Chrome-specific exceptions.

Copy link
Contributor Author

@patgmiller patgmiller Apr 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Firefox doesn't support chrome.offscreen api, see also this #366 (comment)


try {
// use for debugging only, since dev tools does not show extension storage
await chrome.storage.local.get(console.dir);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does Firefox work with this now? When originally implemented in Browserpass, this API had problems in Firefox (race conditions IIRC, although it has been a long time since I last looked at it).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I recall correctly I did this because at the time, when I first started working on the v3 migration, the chrome developer tools didn't show the Extension Storage in Dev Tools.

Screenshot 2025-04-06 at 7 12 22 PM

However, when I run this in Firefox (137.0 (aarch64)) I get the following

Screenshot 2025-04-06 at 7 10 50 PM

Though I'm not sure I follow which part you're asking about. Could you be more specific about which function you're questioning? chrome.storage.local or console.dir?

@patgmiller patgmiller mentioned this pull request Apr 1, 2025
@patgmiller patgmiller deleted the 320-migrate-v3-manifest branch April 6, 2025 15:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

Migrate to manifest v3
4 participants