1692189 - Adding Opensearch search engine does not work for translate.google.com

Status: VERIFIED FIXED

(Firefox :: Search, defect, P3)

Description

[Alice0775 White]

Steps to reproduce:

1. Open https://translate.google.com/
2. 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

Comment 1

[Mike Kaply [:mkaply]]

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

Comment 2

[Mark Banner (:standard8)]

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

[Tom Tung [:tt, :ttung]]

(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

[Tom Tung [:tt, :ttung]]

(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 is false (by default)
• Could reproduce while browser.tabs.remote.useCORP is true (while other reSAB related prefs are false).

(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

[Mike Kaply [:mkaply]]

I debugged it and set a break point here:

https://searchfox.org/mozilla-central/rev/4fa18c26fa907f38d56b599571b9846af1506f3c/toolkit/components/search/SearchUtils.jsm#74

and checked the status code.

It's:

2152924172 which is 0x8053040c

Comment 6

[Tom Tung [:tt, :ttung]]

(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

[Tom Tung [:tt, :ttung]]

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

[Tom Tung [:tt, :ttung]]

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!

Comment 9

[Alice0775 White]

Yes, I can successfully added the google translate engine on Nightly89.0a1(20210413214314)

Comment 10

[Pablo]

verified fix on windows10 64bit, ubuntu 20 and MacOs 10.15 using firefox nightly 89.0a1