Investigate how to handle web channels not working for custom Mozilla Accounts server (due to webext manifest filters)
Categories
(Firefox for Android :: Accounts and Sync, task)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox131 | --- | fixed |
People
(Reporter: jonalmeida, Assigned: jonalmeida)
References
Details
Attachments
(1 file)
|
Bug 1907619 - Create a url pattern for matching using the sender url r=willdurand,#android-reviewers
48 bytes,
text/x-phabricator-request
|
Details | Review |
When using a custom Mozilla Server and signing-in, we use web channels to communicate over the OAuth token to the browser chrome. This works fine for this list of supported domains, but not when your custom server is something else.
This affects developers as well who typically host an FxA/Mozilla server on localhost:3030 and cannot proceed through a sign-in flow because there is no web channel communication happening.
|
Assignee | |
Comment 1•1 year ago
|
||
markh made an interesting observation/suggestion offline: this doesn't affect desktop users because there, the web channel doesn't run in a web extension. Maybe it's time to move web channels to GeckoView.
|
|
Assignee | |
Comment 2•1 year ago
|
||
(In reply to Jonathan Almeida [:jonalmeida] from comment #0)
When using a custom Mozilla Server and signing-in, we use web channels to communicate over the OAuth token to the browser chrome. This works fine for this list of supported domains, but not when your custom server is something else.
This affects developers as well who typically host an FxA/Mozilla server on
localhost:3030and cannot proceed through a sign-in flow because there is no web channel communication happening.
So it turns out that this is already implemented! Kudos to jackyzy, of course. What I'm investigating now, is why were we not seeing the extension work correctly?
(In reply to Jonathan Almeida [:jonalmeida] from comment #1)
markh made an interesting observation/suggestion offline: this doesn't affect desktop users because there, the web channel doesn't run in a web extension. Maybe it's time to move web channels to GeckoView.
In bug 1616635, we have in fact taken explicit steps to disable the FxAccountsWebChannel.sys.mjs from running in GeckoView since we are relying on the webext solution.
If we can sort out if there is a bug in the override, then we can continue to rely on that flow without having to expose a new API from the engine. There is an argument though that one can make, sharing the same web channel code between the two platforms would be more manageable. We would still run into things like bug 1857021 because we need to connect the port messages to the FxaAccountManager.
|
|
Assignee | |
Updated•1 year ago
|
|
|
Assignee | |
Comment 3•1 year ago
|
||
I'm going to close this as works for me. The real bug to fix here is the red herring, so that we don't go down this route again.
|
|
Assignee | |
Comment 4•1 year ago
|
||
(In reply to Jonathan Almeida [:jonalmeida] from comment #3)
I'm going to close this as works for me. The real bug to fix here is the red herring, so that we don't go down this route again.
Nope, I was wrong. In my testing I had the <all_urls> in the web extension content_scripts.matches which allowed the extension to run, but that isn't how it should work. I suspect that something in Manifest V3 changed the behaviour here and we didn't notice this regression, but this has yet to be proved.
|
|
Assignee | |
Comment 5•1 year ago
|
||
Hey Will, would you be a good person to ask about comment 4? Is the behaviour in our manifest.json expected to work or could something have changed as part of MV3?
If you're not sure, would appreciate some help in knowing which direction I could look at next. Thanks!
|
|
Assignee | |
Comment 6•1 year ago
|
||
Will and I investigated this together offline and found the cause of this is because of the match patterns in the content script, do not like the port that is on the URL, so we have to strip it and create a new pattern that seems to work better.
|
|
Assignee | |
Comment 7•1 year ago
|
||
When matching against a url, we need to remove the port as referenced
here for localhost servers to work. This was not a problem for
most applications since they typically had a publicly accessible
domain.
We unfortunately do not have a good test environment for javascript
in our Android Components or Fenix layers.
|
||
Comment 10•1 year ago
|
||
(In reply to Jonathan Almeida [:jonalmeida] from comment #6)
Will and I investigated this together offline and found the cause of this is because of the match patterns in the content script, do not like the port that is on the URL, so we have to strip it and create a new pattern that seems to work better.
The inability to match when port numbers are present is a known issue - bug 1362809.
Description
•