1872517 - Google search suggestions not showing up

Status: NEW

(Firefox :: Search, defect, P3)

Description

[[:DeepChirp]]

Attachment: test.har

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:121.0) Gecko/20100101 Firefox/121.0

Steps to reproduce:

Since I am in mainland China, I must use a proxy to access Google.

Under the same network configuration, when I use Google search in the address bar of Firefox, no search suggestions are displayed; but when I use Google search in the address bar of Microsoft Edge, search suggestions are displayed. No matter which browser I use, search suggestions will always appear for pages I search on Google.

I tried Firefox's troubleshooting mode, but it didn't work.

The HAR file in the attachment is a request for search suggestions I got when I entered Test in the Google search box in private mode. Although the version is 115, it should not be affected. The following is the json file returned by the server.

)]}'
[[["test",0,[512,650,67]],["teste",0,[512,650,67]],["testing",0,[512,650,67]],["test speed",0,[512,650,67]],["testosterone",0,[512,650,67]],["tester",46,[512,650,67],{"lm":["https://encrypted-tbn0.gstatic.com/licensed-image?q\u003dtbn:ANd9GcS_EOIi824ErTghnkqfjzgNv02JE_F54OmbBX55cU_1wE0OaxXF3OYLg29e3zrE-iqVtxt9oMQwXR13jPI__g1T92orAlxU\u0026s\u003d19","https://encrypted-tbn0.gstatic.com/licensed-image?q\u003dtbn:ANd9GcS0r5U98-CU6XCtlRCf36GywKUy4lTpOedKdCQZ5zdIxz5g9rJmon-uoZs-RYyUtTu4yUE3TskQmfqF-_QvDlUb2RMEQh6p\u0026s\u003d19","https://encrypted-tbn0.gstatic.com/licensed-image?q\u003dtbn:ANd9GcQUO0KLluvYcT-OU1TLE9aUs7TrUwWFFzAAyfOz5etS-78NXNHWZzZn4iS1q-CBpvl205yFDbzu1XX2Z0qmZQ2nFHMRENM\u0026s\u003d19"],"zh":"tester","zi":"乔恩·特斯特 \u2014 美国参议员","zp":{"gs_ssp":"eJzj4tTP1TcwM0tOKTBg9GIrSS0uSS0CADT-Bco"},"zs":"https://encrypted-tbn0.gstatic.com/images?q\u003dtbn:ANd9GcT7SkUvQ_bApcKE-_7Fh_OPHly7aEeiXHxLlKcQcw4FwfX9pisvnlcmtf9spQ\u0026s\u003d10"}],["textbook",0,[512,650,67,10]],["testo",46,[512,650,67,199,465],{"lm":[],"zh":"Testo","zi":"Testo SE","zp":{"gs_ssp":"eJzj4tZP1zc0MijPzrEoV2A0YHRg8GItSS0uyQcAThYGew"},"zs":"https://encrypted-tbn0.gstatic.com/images?q\u003dtbn:ANd9GcQ1XP2y7H_xH6c4jeWxbOz2vAqzXjUFGYjKvKEql4o7\u0026s\u003d10"}],["testimony",0,[512,650,67]],["testosterone 中文",0,[512]]],{"ag":{"a":{"40024":["","",1,20]}},"k":1,"q":"_WR2ptU3x7cSjxuKzAyC5k-CTB4"}]

Comment 1

[[:DeepChirp]]

Attachment: Snipaste_2023-12-31_12-06-23.png

Comment 2

[[:DeepChirp]]

Attachment: Snipaste_2023-12-31_12-07-50.png

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Firefox::Address Bar' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:adw, could you have a look please?

For more information, please visit BugBot documentation.

Comment 5

[Daniel Bodea [:danibodea]]

I wonder if the lack of suggestions is caused by your proxy. Which exact proxy are you using? what location are you setting it up for? THanks!

Comment 6

[[:DeepChirp]]

(In reply to Daniel Bodea [:danibodea] from comment #5)

I wonder if the lack of suggestions is caused by your proxy. Which exact proxy are you using? what location are you setting it up for? THanks!

I think not. I'm using X-ray, and the server's address is in the United States. The server was created by myself. Mainly, using the same proxy, Microsoft Edge will display. And my Android version of Firefox also uses the same proxy, but can also display search suggestions.

Comment 7

[Daniel Bodea [:danibodea]]

I could reproduce a similar issue using a different proxy set to US in Nightly v123.0a1 and ESR v115.6.0esr. I would install a VPN addon and set it to US, then I would open a new tab and write "@google " to force search in Google, then write "Test". No suggestions would show up. this would only reproduce in the first few tries of a newly created profile.

Please also answer these questions:

1. Does this issue always happen in your case?
2. Does it only happen in the case of Google?
3. What add-ons are you using? Any that might influence Searching?
4. Are u using the latest ESR version? ESR v115.6.0esr?
5. Could you try whether this reproduces in a newly created profile? (info here)
6. Is there anything else that you suspect could be related to your issue?

Thank you for your contribution!

Comment 8

[[:DeepChirp]]

(In reply to Daniel Bodea [:danibodea] from comment #7)

I could reproduce a similar issue using a different proxy set to US in Nightly v123.0a1 and ESR v115.6.0esr. I would install a VPN addon and set it to US, then I would open a new tab and write "@google " to force search in Google, then write "Test". No suggestions would show up. this would only reproduce in the first few tries of a newly created profile.

Please also answer these questions:

1. Does this issue always happen in your case?
2. Does it only happen in the case of Google?
3. What add-ons are you using? Any that might influence Searching?
4. Are u using the latest ESR version? ESR v115.6.0esr?
5. Could you try whether this reproduces in a newly created profile? (info here)
6. Is there anything else that you suspect could be related to your issue?

Thank you for your contribution!

Thank you for your response. Now, I will give you a reply.

1. Yes.
2. Yes.
3. I used more than ten extensions. However, I have tried disabling them all or using "troubleshooting mode", but it has not been helpful.
4. I tried using this version, but it didn't help.
5. I tried creating a new profile, but it didn't help.
6. Mainly, under the same network configuration, using other browsers, or using Firefox on Android, the search suggestions are normal. At the same time, search suggestions can also be displayed when searching on Google pages. So I think there is a problem with the way Firefox gets search suggestions, or it is unable to parse the returned json file correctly.

Comment 9

[Daniel Bodea [:danibodea]]

I am at a loss here considering I can't consistently reproduce it beyond the reproduction in comment 2. I am open to suggestions in the hope of reproducing it as the reporter does. Please "need info" me if I can further help with testing.

Comment 10

[Mark Banner (:standard8)]

Does your proxy require you to be signed in or need cookies? We currently don't send cookies for search suggestions, so I'm wondering if that might be an issue here.

If not, do you think you could use the Network pane of the Browser Toolbox to inspect what is happening with the network connections when you type in the address bar?

Comment 11

[Daniel Bodea [:danibodea]]

Closing report due to insufficient information.
Feel free to reopen it if the issue still occurs or reappears and more information can be provided.
Thank you for your contribution!

Comment 12

[[:DeepChirp]]

Sorry for forgetting this question for so long. I found that when Firefox requests search suggestions, it says NS_BINDING_ABORTED and that's why it can't get search suggestions. I have disabled all extensions and cleared the cache, but the problem still exists. I will attach the screenshot and the har file.

Comment 13

[[:DeepChirp]]

Attachment: Snipaste_2024-09-14_12-47-20.png

Comment 14

[[:DeepChirp]]

Attachment: Snipaste_2024-09-14_12-47-35.png

Comment 15

[[:DeepChirp]]

Attachment: browser_Archive [24-09-14 12-48-01].har

Comment 16

[Marco Bonardo [:mak]]

Does it work if you type in the Google input field? Will it return suggestions then in a popup before pressing Enter?
We still suspect the proxy may be related, but maybe it's because Firefox tries to load suggestions without any cookies or cache, for privacy reasons.
Is it possible for you to share information about the proxy you are using, or is it a private one?

Comment 17

[[:DeepChirp]]

(In reply to Marco Bonardo [:mak] from comment #16)

Does it work if you type in the Google input field? Will it return suggestions then in a popup before pressing Enter?
We still suspect the proxy may be related, but maybe it's because Firefox tries to load suggestions without any cookies or cache, for privacy reasons.
Is it possible for you to share information about the proxy you are using, or is it a private one?

If you mean typing in the address bar in Firefox, search suggestions never appear. However, when searching on Google's web pages, suggestions can be displayed.
I built a proxy myself, a private proxy, using Xray-core, which does not require cookies for verification but UUID (see https://xtls.github.io/config/inbounds/vless.html). But I don't know what information is needed. If you have other questions about the proxy, you can continue to ask me.
I'm using curl to get search suggestions without cookies and cache, but it seems to work fine (except for the Chinese encoding issue).

> curl -H "Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2" "https://www.google.com/complete/search?client=firefox&channel=fen&q=Test"
["Test",["test","testosterone ","testosterone","testflight","testflight","test ipv6","testicle","test your vocabulary","testament ","test internet speed"],[],{"google:suggestsubtypes":[[512],[512],[512],[512],[512],[512],[512],[512],[512],[512]]}]

Comment 18

[saiteTimedOut]

Same problem here. I use a transparent proxy config, and tun0 is used for proxy traffic (which means Firefox may not know the presence of a proxy). It seems that TCP RST packets was sent immediately after Server Hello, but when type in Google input field or using curl, there's no problem.

$ curl -H "Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2" "https://www.google.com/complete/search?client=firefox&channel=fen&q=Test" --connect-to ::[2607:f8b0:4008:805::2004]:443 -v
* Connecting to hostname: 2607:f8b0:4008:805::2004
* Connecting to port: 443
*   Trying [2607:f8b0:4008:805::2004]:443...
* Connected to 2607:f8b0:4008:805::2004 () port 443
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: none
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / x25519 / id-ecPublicKey
* ALPN: server accepted h2
* Server certificate:
*  subject: CN=www.google.com
*  start date: Aug 12 07:19:41 2024 GMT
*  expire date: Nov  4 07:19:40 2024 GMT
*  subjectAltName: host "www.google.com" matched cert's "www.google.com"
*  issuer: C=US; O=Google Trust Services; CN=WR2
*  SSL certificate verify ok.
*   Certificate level 0: Public key type EC/prime256v1 (256/128 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 1: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 2: Public key type RSA (4096/152 Bits/secBits), signed using sha384WithRSAEncryption
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://www.google.com/complete/search?client=firefox&channel=fen&q=Test
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: www.google.com]
* [HTTP/2] [1] [:path: /complete/search?client=firefox&channel=fen&q=Test]
* [HTTP/2] [1] [user-agent: curl/8.10.0]
* [HTTP/2] [1] [accept: */*]
* [HTTP/2] [1] [accept-language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2]
> GET /complete/search?client=firefox&channel=fen&q=Test HTTP/2
> Host: www.google.com
> User-Agent: curl/8.10.0
> Accept: */*
> Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
> 
* Request completely sent off
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
< HTTP/2 200 
< date: Tue, 17 Sep 2024 02:08:12 GMT
< pragma: no-cache
< expires: -1
< cache-control: no-cache, must-revalidate
< content-type: text/javascript; charset=GB2312
< content-security-policy: object-src 'none';base-uri 'self';script-src 'nonce-SxzNT6txPksHCrrdipAHcA' 'strict-dynamic' 'report-sample' 'unsafe-eval' 'unsafe-inline' https: http:;report-uri https://csp.withgoogle.com/csp/gws/xsrp
< accept-ch: Sec-CH-Prefers-Color-Scheme
< content-disposition: attachment; filename="f.txt"
< server: gws
< x-xss-protection: 0
< x-frame-options: SAMEORIGIN
< alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000
< accept-ranges: none
< vary: Accept-Encoding
< 
* Connection #0 to host 2607:f8b0:4008:805::2004 left intact
["Test",["test","testosterone ","testosterone","testflight","test innovators","test your vocabulary","testflight","testament ","test internet speed","test ipv6"],[],{"google:suggestsubtypes":[[512],[512],[512],[512],[512],[512],[512],[512],[512],[512]]}]

Comment 19

[saiteTimedOut]

Attachment: wireshark_firefox.png

Packets captured when typing in the address bar of Firefox using Google.

Comment 20

[saiteTimedOut]

Attachment: wireshark_curl.png

Packets captured when curl -H "Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2" "https://www.google.com/complete/search?client=firefox&channel=fen&q=Test" --connect-to ::[2607:f8b0:4008:805::2004]:443 -v

Comment 21

[Chris Bellini (:cbellini)]

:rjesup, is this something that might getting blocked on the network side of things?

Comment 22

[Randell Jesup [:jesup] (needinfo me)]

Valentin, kershaw - can you look at this?

Comment 23

[Valentin Gosu [:valentin] (he/him)]

Hi, there does seem to be a problem here, but I'm not sure why Firefox would reset the connection.
Could you reproduce it once more with this list of instructions to get a decoded pcap? Thanks!

Open cmd

1. execute set SSLKEYLOGFILE=%TEMP\keys.txt
2. execute echo %SSLKEYLOGFILE%
3. then execute "C:\Program Files\Mozilla Firefox\firefox.exe" (or whatever your Firefox path might be)
4. Start Wireshark.
5. Set the keylogfile in wireshark to the path returned in step 2 (Step 8 of https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA14u000000wkvECAQ&lang=en_US%E2%80%A9 for instructions on how to do that)
6. Go to about:logging and start logging
7. Reproduce the bug
8. Stop logging and stop wireshark
9. Upload the profiler log.
10. Go to wireshark, write click on the reset connection, and click follow TCP stream.
11. Select all packets, and go to File > Export selected packets
12. Upload wireshark capture here and profiler link.

Thanks!

Comment 24

[saiteTimedOut]

Attachment: google_reset.pcapng

Packets captured when typing in the address bar of Firefox using Google, decrypted using keys.txt

Comment 25

[saiteTimedOut]

Attachment: Firefox 2024-09-25 21.28 profile.json.gz

Comment 26

[Valentin Gosu [:valentin] (he/him)]

Thanks!

Comment 27

[Valentin Gosu [:valentin] (he/him)]

Looking at the logs, it seems all of the google search requests are cancelled

2024-09-25 13:29:18.177146240 UTC - [Parent Process 2894: GeckoMain]: D/nsHttp nsHttpChannel::Cancel [this=767a9adafa00 status=804b0002, reason=XMLHttpRequestMainThread::CloseRequest]
2024-09-25 13:29:18.177164062 UTC - [Parent Process 2894: GeckoMain]: D/nsHttp 767a9adafa00 called from script: resource://gre/modules/SearchSuggestionController.sys.mjs:357:35

The pcap shows that the connection is terminated via a TCP reset sent from the client side before the TLS connection is actually established.

I think we need to figure out why the request gets canceled from SearchSuggestionController.sys.mjs

Comment 28

[Mark Banner (:standard8)]

(In reply to Valentin Gosu [:valentin] (he/him) from comment #27)

I think we need to figure out why the request gets canceled from SearchSuggestionController.sys.mjs

The only reason SearchSuggestionController would call abort, is if there's a second search coming in whilst the previous search is still ongoing.

This would be the case if the user types something, pauses for a short time (50ms), and then types something else. This would then cancel any previous search and start a new connection.

Comment 29

[Mark Banner (:standard8)]

Forgot to add that in the address bar context, SearchSuggestionController.stop() is only called from SearchSuggestionController.fetch().

Comment 30

[Valentin Gosu [:valentin] (he/him)]

024-09-25 13:29:03.359 ⁃ nsHttpChannel ⁃ 767a99b90e00 ⁃ finished ⁃ status=804b0002 ⁃ http-status=n/a ⁃ url=https://www.google.com/complete/search?client=firefox&channel=fen&q=tes
2024-09-25 13:29:07.002 ⁃ nsHttpChannel ⁃ 767a99b8f000 ⁃ created ⁃ status=n/a ⁃ http-status=n/a ⁃ url=https://test6.ustc.edu.cn/
2024-09-25 13:29:07.036 ⁃ nsHttpChannel ⁃ 767a99b8fa00 ⁃ finished ⁃ status=804b0002 ⁃ http-status=n/a ⁃ url=https://www.google.com/complete/search?client=firefox&channel=fen&q=test
2024-09-25 13:29:08.275 ⁃ nsHttpChannel ⁃ 767a9adac800 ⁃ created ⁃ status=n/a ⁃ http-status=n/a ⁃ url=https://www.google.com/search?client=firefox-b-d&q=
2024-09-25 13:29:08.308 ⁃ nsHttpChannel ⁃ 767a99b8be00 ⁃ finished ⁃ status=804b0002 ⁃ http-status=n/a ⁃ url=https://www.google.com/complete/search?client=firefox&channel=fen&q=test
2024-09-25 13:29:09.328 ⁃ nsHttpChannel ⁃ 767a9ada8200 ⁃ created ⁃ status=n/a ⁃ http-status=n/a ⁃ url=https://www.google.com/search?client=firefox-b-d&q=
2024-09-25 13:29:09.363 ⁃ nsHttpChannel ⁃ 767a9ada8c00 ⁃ finished ⁃ status=804b0002 ⁃ http-status=n/a ⁃ url=https://www.google.com/complete/search?client=firefox&channel=fen&q=test+h
2024-09-25 13:29:11.916 ⁃ nsHttpChannel ⁃ 767a9adaa000 ⁃ created ⁃ status=n/a ⁃ http-status=n/a ⁃ url=https://www.google.com/search?client=firefox-b-d&q=
2024-09-25 13:29:11.950 ⁃ nsHttpChannel ⁃ 767a9adabe00 ⁃ finished ⁃ status=804b0002 ⁃ http-status=n/a ⁃ url=https://www.google.com/complete/search?client=firefox&channel=fen&q=test+he
2024-09-25 13:29:14.014 ⁃ nsHttpChannel ⁃ 767a9812b400 ⁃ created ⁃ status=n/a ⁃ http-status=n/a ⁃ url=https://www.google.com/search?client=firefox-b-d&q=
2024-09-25 13:29:14.049 ⁃ nsHttpChannel ⁃ 767a9adad200 ⁃ finished ⁃ status=804b0002 ⁃ http-status=n/a ⁃ url=https://www.google.com/complete/search?client=firefox&channel=fen&q=test+hel
2024-09-25 13:29:15.637 ⁃ nsHttpChannel ⁃ 767a9adaaa00 ⁃ created ⁃ status=n/a ⁃ http-status=n/a ⁃ url=https://www.google.com/search?client=firefox-b-d&q=
2024-09-25 13:29:15.672 ⁃ nsHttpChannel ⁃ 767a9adae600 ⁃ finished ⁃ status=804b0002 ⁃ http-status=n/a ⁃ url=https://www.google.com/complete/search?client=firefox&channel=fen&q=test+hell
2024-09-25 13:29:15.765 ⁃ nsHttpChannel ⁃ 767a9adb2200 ⁃ finished ⁃ status=0 ⁃ http-status=101 ⁃ url=https://push.services.mozilla.com/
2024-09-25 13:29:17.537 ⁃ nsHttpChannel ⁃ 767a9adadc00 ⁃ created ⁃ status=n/a ⁃ http-status=n/a ⁃ url=https://www.google.com/search?client=firefox-b-d&q=
2024-09-25 13:29:17.571 ⁃ nsHttpChannel ⁃ 767a9adafa00 ⁃ finished ⁃ status=804b0002 ⁃ http-status=n/a ⁃ url=https://www.google.com/complete/search?client=firefox&channel=fen&q=test+hello

They do get cancelled because of that, but the last one also gets cancelled - and there's not requests coming after that one.

Comment 31

[Mark Banner (:standard8)]

:saiteTimedOut It looks like the requests in the suggestions are being cancelled, maybe because of further typing. Would you be able to get logs where there's a clear pause for a second or two after typing test ?

Comment 32

[saiteTimedOut]

Attachment: google_reset_2.pcapng

This time, I paused for around 5 seconds after typing "test"

Comment 33

[saiteTimedOut]

Attachment: Firefox 2024-10-07 20.22 profile.json.gz

Comment 34

[Mark Banner (:standard8)]

Valentin would you be able to take a look at the logs here?

Comment 35

[Valentin Gosu [:valentin] (he/him)]

I see the following in the profile:

LogMessages — (nsHttp) sending progress and status notification [this=7847b3bcec00 status=4b000c progress=0/0]
LogMessages — (nsHttp) nsHttpChannel::Cancel [this=7847b3bcec00 status=804b0002, reason=XMLHttpRequestMainThread::CloseRequest]
LogMessages — (nsHttp) 7847b3bcec00 called from script: resource://gre/modules/SearchSuggestionController.sys.mjs:357:35

4b000c is NS_NET_STATUS_TLS_HANDSHAKE_STARTING

In the pcap, I see the TLS connection being established:
8 1.267530968 2607:f8b0:4008:80a::2004 2001:20::1 TLSv1.3 1235 Server Hello, Change Cipher Spec
Followed by the client resetting it during the TLS handshake:
9 1.267558643 2001:20::1 2607:f8b0:4008:80a::2004 TCP 60 60766 → 443 [RST] Seq=664 Win=0 Len=0

@Reporter, could you try using mozregression to find when this bug was introduced? https://mozilla.github.io/mozregression/quickstart.html

Comment 36

[[:DeepChirp]]

Attachment: Snipaste_2024-11-21_10-50-59.png

Sorry for late reply. I have tested and found that the 2022-11-06 version is good, but the 2022-11-07 version is bad.

Comment 37

[[:DeepChirp]]

The pushlog_url

Comment 38

[Valentin Gosu [:valentin] (he/him)]

Could this be caused by bug 1798861?

Comment 39

[Marco Bonardo [:mak]]

(In reply to Valentin Gosu [:valentin] (he/him) from comment #38)

Could this be caused by bug 1798861?

It sounds like a real possibility based on the timing and the sympthoms. As Mark said it's expected that when a new search starts, the previous one will be aborted. Though it looks like we're aborting also the current one, and I wonder why it would only happen in this specific case.
I actually suspect bug 1798861 uncovered an already existing bug.

Looking at the code, SearchSuggestionController.stop() is invoked by .fetch(), that is invoked by UrlbarProviderSearchSuggestions._fetchSearchSuggestions(. stop is also directly invoked by UrlbarProviderSearchSuggestions.cancel

(on a side note, we seem to create a new controller for every search, that feels sub-optimal)

There's a couple cases where a query is canceled:

• if the selection in the urlbar panel is changed while typing (like by pressing down), then results are frozen. I assume this is not the case, though maybe there's a selection bug due to some unexpected timing.
• when the view gets closed. I actually wonder if there is some problem with the used IME.

So, a couple things to try:

1. try temporarily setting browser.urlbar.loglevel to All and reproduce the bug? It should print a bunch of logging to the browser console, having that attached here as a .txt may be useful. You can restore the pref after it.
2. Could you please try setting browser.urlbar.keepPanelOpenDuringImeComposition to true and check if the problem persists?

Comment 40

[[:DeepChirp]]

Attachment: console-export-2024-11-21_19-27-51.txt

Thank you for your prompt response. I have provided the necessary logs. For browser.urbbar.keepPanelOpenDuringImeComposition, regardless of whether I set it to true or false, problems will occur.

Comment 41

[Marco Bonardo [:mak]]

hm I see a bunch of SearchSuggestionController found an unexpected string value: HTTP request timeout SearchSuggestionController.sys.mjs:645:17
The default timeout is 500ms, it's possible in this case it takes longer? Let's try with 2s.
Could you please go to about:config, create a new Numerical pref, name it browser.search.suggest.timeout and set its value to 2000 (or even larger in further tests). Does a larger value help?

Comment 42

[[:DeepChirp]]

(In reply to Marco Bonardo [:mak] from comment #41)

hm I see a bunch of SearchSuggestionController found an unexpected string value: HTTP request timeout SearchSuggestionController.sys.mjs:645:17
The default timeout is 500ms, it's possible in this case it takes longer? Let's try with 2s.
Could you please go to about:config, create a new Numerical pref, name it browser.search.suggest.timeout and set its value to 2000 (or even larger in further tests). Does a larger value help?

Yes, after changing the settings, search suggestions are working fine.

I think it is necessary to increase the timeout value. Because of the Chinese network, people have to use a proxy, which can easily exceed 500ms.

Comment 43

[Marco Bonardo [:mak]]

I'll pass over the request to Mark for a decision about that.
I think at a minimum we could make the pref visible in about:config.
We may also evaluate an increase, though it's hard to guess what a good value would be. Likely we can try to increase to 1s and add some telemetry to check how many timeouts we get.

Comment 44

[Valentin Gosu [:valentin] (he/him)]

It seems here the timeout causes the request to be cancelled. Just bumping the timeout doesn't actually fix the issue, right?

Comment 45

[Marco Bonardo [:mak]]

(In reply to Valentin Gosu [:valentin] (he/him) from comment #44)

It seems here the timeout causes the request to be cancelled. Just bumping the timeout doesn't actually fix the issue, right?

The timeout here is just an nsITimer we manage in Search code, if the request takes to long we just give up and return no results earlier, then the query "finishes" because all the providers are done, and we just cancel whatever is left (and the actual network abort happens here).
I think the issue is just our timeout is too short in this case.

Comment 46

[Marco Bonardo [:mak]]

My suggested path forward here is to:

• expose the pref, so it's visible in about:config
• bump up the value to 1s
• If we can detect the user has modified settings to include a Proxy, then we could artificially double the timeout
• Add telemetry to measure how often we hit the timeout

Comment 47

[Mark Banner (:standard8)]

I agree that comment 46 seems a reasonable way forward. Though are there any address bar / search bar downsides to bumping the default to 1 second?

Comment 48

[Marco Bonardo [:mak]]

(In reply to Mark Banner (:standard8) from comment #47)

I agree that comment 46 seems a reasonable way forward. Though are there any address bar / search bar downsides to bumping the default to 1 second?

Off-hand, more dangling connections (though we likely correctly cancel on next search so may not be a problem), potentially perceived performance concerns (suggestions will appear delayed and possibly push down other results in a more visible way). Though I suspect not getting suggestions may be a worse situation.
The current timeout was a best guess anyway, it was not satisfying any specific requirement.