-
Notifications
You must be signed in to change notification settings - Fork 60
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
migrate to v3 manifest #366
Conversation
…vice worker remove mythril from helpers, no access to window update for storage api changes chrome.browserAction => chrome.action.
… troubleshoot alarm to clear clipboard. browserpass#320
…redential provision not yet implemented. browserpass#320
…r inject / scripting, browserpass#320
I've tested in chrome ( |
Thanks! Some testing, admittedly without actually looking at the code yet:
|
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. |
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 I'm contemplating whether removing |
@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 |
Yes, sorry I mentioned it, but I also quickly submitted the PR.
I'll look at it, I have an idea what it might be.
Thanks for the feedback, I'll test it against this example specifically, that's what I need, different approaches to break it 😉 |
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.".
I know you know, but just to be super explicit here, |
Both of these items are at least be improved, if not fixed. See if you can break them.
@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?
|
…ce of url open shortcut, browserpass#320
@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. |
…n user, and proceed only based on confirm, browserpass#320
@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 |
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. |
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. |
ah, got it that makes sense. sounds great! I shouldn't need much longer I feel like it's really close 🤞🏻 |
modal window content resize is well underway and will also address it for notificaitons #336 Chrome dialog redrawchrome-modal-window-resize.webmFirefox dialog redrawfirefox-modal-window-resize.webmError notification redrawchrome-modal-window-resize-on-notification.webm |
@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;
} |
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:
This is basically when the user is on the manage chrome extension page, 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 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. |
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... |
…h one to keep or remove, browserpass#320
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. |
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. |
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! |
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 😁 ) |
Can do 🙂
I just tested this, and it is NICE! Much more user-friendly than the launch-from-hotkey method we had previously. |
@maximbaz Are you still on Wire? |
There was a problem hiding this 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; |
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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"); |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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); |
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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.
However, when I run this in Firefox (137.0 (aarch64)
) I get the following
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
?
Closes #320 #336