-
Notifications
You must be signed in to change notification settings - Fork 117
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
FXVPN-32 add message (and fix bug involving lists and shared strings) #10045
Conversation
bca3988
to
3bf28f4
Compare
"type": "message", | ||
"conditions": { | ||
"min_client_version": "2.25.1", | ||
"enabled_features": ["webExtension"], |
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.
++localProxy
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.
Actually, we just removed the localProxy
feature in PR #10058 since it's no longer something that the client can toggle (it's just a service that happens to exist on Windows and Linux). The "feature" still gets reported through the web extension, but it's value just checks if the corresponding serivce is running.
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.
Hmm, maybe that was a mistake and I should put it back as an un-toggle-able feature.
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.
@lesleyjanenorton , were you suggesting adding localProxy
in addition to webExtension
?
(I'm looking for the name of a feature that will be the thing we "flip on" to make this go live for users - to be clear this is not a user-toggleable thing.)
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.
we just removed the localProxy feature in PR #10058 since it's no longer something that the client can toggle
@oskirby Does this mean that the proxy will be available by default on Windows in v2.25? If yes, we should put it back behind the 'localProxy' feature flag.
I'm looking for the name of a feature that will be the thing we "flip on" to make this go live for users - to be clear this is not a user-toggleable thing.
@mcleinman Let's sort this out in the office hours meetings. Previously this was 'localProxy' and 'webExtension'.
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.
To summarize a zoom discussion: I'm not in favor of adding a localProxy
feature flag back. The proxy, being a windows/systemd service required administrative privileges to start and stop and the client UI does not hold such privileges... to make this controllable by a feature flag it would have to be managed through the daemon and that is a lot of work for not a lot of gain.
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.
Updated per our meeting
This is reviewable - I've put it on draft as a reminder to not merge it before #10065. |
Taking off draft as #10065 is merged |
I removed the feature trigger (as it no longer is accurate) and I updated the version to something far in the future (so this message won't accidentally get shown) - I've updated the follow-up ticket as appropriate. |
"name": "Try the Firefox extension", | ||
"type": "message", | ||
"conditions": { | ||
"min_client_version": "3.25.1", |
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.
So that QA can start testing this we could do "env": "staging",
instead.
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.
Thanks, I thought I was forgetting one. I've updated this, and will update that follow up ticket in a moment.
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.
Probably good enough to merge. Just a few nits.
@@ -0,0 +1,3 @@ | |||
((api) => { | |||
api.urlOpener.openUrlLabel('downloadFirefox'); |
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.
As a minor nitpick requiring the URL to be defined by label in the client binary is probably unnecessary, we could just put it into this file as api.urlOpener.openUrl('https://foo.bar/baz/...')
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.
I don't like that to change the URL we would have to change the client, which kind of makes the addon system unnecessarily brittle.
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.
I was following convention here, though I don't love it either.
That said, nearly all addon changes take client work (for non-English languages), as we need to release new client versions to get updated translations - a brand new addon without a client update wouldn't be translated.
Since it's a nit, I'm going to leave this for now. If we want to change the convention, let's do it for all addons at once.
@@ -0,0 +1,3 @@ | |||
((api) => { | |||
api.urlOpener.openUrlLabel('downloadExtension'); |
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.
Same comment as for downloadFirefox.js
this could done directly as api.urlOpener.openUrl('https://foo.bar/baz/...')
This PR cannot be merged into#10065 was merged.main
before #10065 is merged intomain
, to ensure we don't add bad translation IDs.Description
This adds the in-app message and notification for the web extension.
Notes:
strings.yaml
file, as we now have enough strings that we don't need those samples.Testing
This code will not be seen until 2.25.1. Thus, you need to change the
conditions
block. Given that QA will not be able to test this after merging tomain
, we need at least one other VPN engineer to test this code. To test:To test:
./3rdparty/i18n/en/addons/strings.xliff
:How to implement and test add-ons
section of./docs/Components/Addons/index.md
.webExtension
feature. Hard quit and relaunch the app.Reference
FXVPN-32
Checklist