Adding Opensearch search engine does not work for translate.google.com
Categories
(Firefox :: Search, defect, P3)
Tracking
()
People
(Reporter: alice0775, Unassigned)
References
(Regression)
Details
(Keywords: nightly-community, regression)
Steps to reproduce:
- Open https://translate.google.com/
- Click "Add Search Engine" from page actions menu in location bar
Actual Results:
Download Error
Nightly could not download the search plugin from: https://translate.google.com/opensearch.xml?hl=en_US
Expected Results:
The search engine is successfully added.
OR
If not allow , browser should not offer "Add Search Engine" in page actions menu and standalone SearchBar icon badge.
Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=8fe4738543cbff085e7d43da5ece4c80f4181291&tochange=f8343d64ab6f3a66fbc7d47484758725cb0335c2
Updated•4 years ago
|
Updated•4 years ago
|
Comment 1•4 years ago
|
||
Definitely CORS related. The actual error code from the failure is:
NS_ERROR_DOM_CORP_FAILED
Although that makes no sense since it's downloading from the same domain? /opensearch.xml?hl=en
Updated•4 years ago
|
Comment 2•4 years ago
|
||
Tom, would you be able to help us here? It appears related to bug 1594748.
The loading is initiated from here: https://searchfox.org/mozilla-central/rev/9043e515e9608cc55b252a40cb2dfb6f767bcffd/toolkit/components/search/OpenSearchEngine.jsm#86,103,111-119
Comment 3•4 years ago
|
||
(In reply to Mark Banner (:standard8) from comment #2)
Tom, would you be able to help us here? It appears related to bug 1594748.
Sure, but I have some questions and want to ensure I understand this correctly.
The loading is initiated from here: https://searchfox.org/mozilla-central/rev/9043e515e9608cc55b252a40cb2dfb6f767bcffd/toolkit/components/search/OpenSearchEngine.jsm#86,103,111-119
If it's related to CORP it's probably related to browser.tabs.remote.useCORP
. Re-SAB needs that because the COEP header requires the CORP header to be enabled.
(In reply to Mike Kaply [:mkaply] from comment #1)
Definitely CORS related. The actual error code from the failure is:
NS_ERROR_DOM_CORP_FAILED
Although that makes no sense since it's downloading from the same domain? /opensearch.xml?hl=en
Hi Mike, could you elaborate more on where you found this error code? I didn't find this error while reproducing this issue.
I enabled the MOZ_LOG for the nsHttp and didn't find this error while reproducing this issue.
Moreover, I saw "loadListener: request failed!" and it's because request.requestSucceeded
is false
. However, from the MOZ_LOG that I recorded with setting it to nsHttp:5, that's because Necko/HttpChannel gets 403 from the server. (Note: it cab be because we didn't send expected request headers or body to the server)
Comment 4•4 years ago
|
||
(In reply to Tom Tung [:tt, :ttung] from comment #3)
If it's related to CORP it's probably related to
browser.tabs.remote.useCORP
. Re-SAB needs that because the COEP header requires the CORP header to be enabled.
I tested FF73 and:
- Couldn't reproduce while
browser.tabs.remote.useCORP
isfalse
(by default) - Could reproduce while
browser.tabs.remote.useCORP
istrue
(while other reSAB related prefs arefalse
).
(The pref has been removed at https://phabricator.services.mozilla.com/D66861 since FF76)
Anyway, I wonder if it's because we are using the wrong principal for initiating the request so that it's treated as cross-origin?
Comment 5•4 years ago
|
||
I debugged it and set a break point here:
and checked the status code.
It's:
2152924172 which is 0x8053040c
Updated•4 years ago
|
Comment 6•4 years ago
|
||
(In reply to Mike Kaply [:mkaply] from comment #5)
Thanks! However, statusCode
is 0
on the current Nightly when it fails on my Mac. (I put the reason that I understood on comment #3)
I suspect that it means there are at least two issues here. One is caused by browser.tabs.remote.useCORP
since 73 and the other is something that happens after 73. The latter one changes the signature and makes the response get blocked at an earlier phase. So that before the latter one gets resolved, I couldn't verify if the former one is resolved.
To find the latter issue, if I change the criteria for bisection/mozregression to "succeed or statusCode
is 2152924172 when it fails" (which means the bad case is statusCode
is 0
when it fails), I got https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=23c4c99d0c1f2cee22eeb6b5f78f85781546b391&tochange=f9fc9427476eb418b9032257f116ad614f0ae5b2
Note, for the issue made by bug 1594748, I suspect it's because the LoadingPrincipal for the request is a system principal and the check for CORP should probably allow the system principal response to pass.
Comment 7•4 years ago
|
||
I filed two tickets.
- bug 1703464 handles the regression from CORP
- bug 1703466 handles the regression from Sec-Fetch-*
After applying the patch in bug 1703464 and disabling the Sec-Fetch-* headers, I am able to add the search engine by doing the steps in STR.
Comment 8•4 years ago
|
||
Hi Alice0775,
I am able to add open search engine at https://translate.google.com/ on the lastest Nightly after both bug 1703464 and bug 1703466 are resolved. Would you mind helping me to check if that also works on your side? If so, then I guess we can close this bug. Thanks in advance!
Reporter | ||
Comment 9•4 years ago
|
||
Yes, I can successfully added the google translate engine on Nightly89.0a1(20210413214314)
Updated•4 years ago
|
Comment 10•4 years ago
|
||
verified fix on windows10 64bit, ubuntu 20 and MacOs 10.15 using firefox nightly 89.0a1
Updated•4 years ago
|
Description
•