Search suggestion for Amazon and wikipedia can timeout - Detangle fetching of local and remote suggestions
Categories
(Firefox :: Search, defect, P3)
Tracking
()
People
(Reporter: muirpablo, Unassigned)
References
Details
Attachments
(7 files, 4 obsolete files)
checked with
Windows 10 64bit
Using
Firefox Release 77.0.1
Firefox Beta 78
Firefox Nightly 79.0a1
steps#1 (affects all firefox versions)
- Go to about:preferences#search
- Enable "add search bar in toolbar"
- Set amazon as default engine
- Search "laptop" in address bar
- delete the "p" from laptop
steps2 (affected in beta and nightly)
- Set amazon as default engine
- type each leeter of the word "facebook" slowly in urlbar
- delete and type the word facebook fast.
Actual results
-with steps#1 : Search results only show if you delete the P
-with steps#2 : search results only show if you type slowly, if you type fast you dont get results.
Expected result
Search result should be shown when you input laptop, or type facebook fast in url bar.
Comment 2•5 years ago
|
||
what did you enable/disable in urlbar preferences, could you please attach a log from about:support?
(In reply to Pablo from comment #0)
- Enable address bar in toolbar
What does this mean, did you mean search bar? The Address Bar can't be removed nor disabled.
Hi marco
sorry for that
I Enabled in options > Search > "add search bar in toolbar"
and set amazon.com as default engine
Comment 5•5 years ago
|
||
I've just tried reproducing this, but I can't. Pablo, please could you try getting a browser console log with browser.search.log turned on, and with XHR selected in the browser console (top-right)?
Sure mark,
the 11console-export-2020-6-24_13-42-26 is everything that console gave me
the last line would be removing "P" in search bar in toolbar.
the line above the last one would be with the "P"
also attached screenshot. I will attach the one from address bar in a bit
002console-export-2020-6-24_14-3-13 is the export for the problem in megabar.
creating new profile, setting amazon as default in about:preferences
and then typing fast, "facebook" , in megabar, which does not bring any results.
| Reporter | ||
Comment 10•5 years ago
|
||
Comment 11•5 years ago
|
||
Comment 12•5 years ago
|
||
Comment 13•5 years ago
|
||
Comment 14•5 years ago
|
||
| Comment hidden (off-topic) |
| Comment hidden (off-topic) |
| Comment hidden (off-topic) |
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Comment 18•5 years ago
|
||
Been able to reproduce this, it looks like Amazon suggestions are quite slow sometimes and hitting the 500ms timeout after which we ignore them
https://searchfox.org/mozilla-central/source/toolkit/components/search/SearchSuggestionController.jsm#22
Marco do you know about the reason for the timeout? it seems like if we get the results no real reason not to show them
| Comment hidden (off-topic) |
Comment 20•5 years ago
|
||
(In reply to Dale Harvey (:daleharvey) from comment #18)
Marco do you know about the reason for the timeout? it seems like if we get the results no real reason not to show them
This timer predates me, it was added in 2006. The only reasoning I found is that local and remote suggestions are handled by this same code, to keep things "responsive" it was decided that if remote suggestions take too long (or don't arrive at all), we'll at least provide local suggestions sooner.
Updated•5 years ago
|
Comment 22•5 years ago
|
||
This may affect quite a few users, we don't know, but bug 1663949 pointed out how it could affect users from Argentina, thus I suspect it's a lot more common than we expect.
We should have some kind of per-engine timeout telemetry (TBD), and likely the best path forward for the urlbar may be to detangle search history and search suggestions fetching, so remote can have a longer timeout.
Comment 23•5 years ago
•
|
||
Another possibility may be to change the API to accept a callback, rather than return an array of results. Then the callback would be invoked as soon as some result is available, but not before local results are, so dedupe would work the same.
Basically wait for local results, as soon as they arrive start sending results out through the callback, when remote results arrive dedupe them and keep pushing them through the callback.
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Comment 24•5 years ago
|
||
Comment 25•5 years ago
•
|
||
Hi, I noticed that to get suggestions from amazon or wikipedia I have to click outside of the megabar once and then click on the megabar again. This happens in private mode too. Might it be related to this issue or should I open a new bug?
Updated•5 years ago
|
Comment 26•5 years ago
|
||
Imo yes, but it depends. Those 2 actions are both requests to get suggestions, and it looks like the first doesn't go through, the second does. It's totally possible that the first one timed out.
Does that happen every time, or is it intermittent/rare? Where are you based?
We know from Pablo, for example, that Argentina is suffering this problem more often.
One test you can try to check, is to create a browser.search.suggest.timeout integer preference, set it to 5000.
After you typed the first search wait for a few seconds, to check if results arrive or not.
If the problem is gone away with the larger timeout, it is this bug.
Comment 27•5 years ago
•
|
||
(In reply to Marco Bonardo [:mak] from comment #26)
Does that happen every time, or is it intermittent/rare? Where are you based?
It happens every time. I'm also based in Argentina, some kilometers away from Pablo.
One test you can try to check, is to create a browser.search.suggest.timeout integer preference, set it to 5000.
If the problem is gone away with the larger timeout, it is this bug.
I set it up and the issue went away, so no need for a new file, thanks for the prompt answer.
Updated•4 years ago
|
| Reporter | ||
Comment 29•4 years ago
•
|
||
It still happens, noticed this during nightly 90.0a1 testing, after clicking on one offs sometimes the suggestions don´t appear for amazon and wikipedia
Comment 30•4 years ago
|
||
yes, we didn't change anything, yet.
Comment 32•3 years ago
|
||
The severity field for this bug is set to S4. However, the following bug duplicates have higher severity:
- Bug 1663949: S3
- Bug 1710654: S3
- Bug 1713140: S3
:standard8, could you consider increasing the severity of this bug to S3?
For more information, please visit auto_nag documentation.
Updated•3 years ago
|
Description
•