1716188 - Setting browser.urlbar.maxRichResults to 0 introduces a delay when searching

Status: UNCONFIRMED

(Firefox :: Address Bar, defect, P3)

Description

[phurtive]

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

Steps to reproduce:

When browser.urlbar.maxRichResults is set to 0 on two different computers both computers introduced a delay when executing a search from the URL bar. The setting was toggled back and forth between 0 and default (10) to compare the speed on both computers. On one computer, the delay was shorter, ~300ms; on the other, ~600ms. The delay was consistent across various searches. The default search engine has no bearing either. I tried DuckDuckGo, Google and Bing. The delay was the same (for each computer) regardless of what was searched. I searched simple keywords like "test", "cats" and "dogs" and longer searches like "peanut butter and jelly" in addition to URLs, I tested www.google.com and www.duckduckgo.com, among others. The delay was consistent.

Actual results:

Both computers introduce a delay when browser.urlbar.maxRichResults is set to 0. The delay occurs after the search is entered. The browser does not immediately try to access the typed webpage/keywords, but instead has a brief delay, and then searches. Setting browser.urlbar.maxRichResults back to default (or anything greater than 0) removes the delay. The delay does not occur if a search is performed with Ctrl+Enter, presumably because the browser is not having to decide if the search is a keyword or a URL (it is being told it is a URL in that case). Because of this, I believe the delay is caused by the browser having to decide if a search is a keyword or URL since the rich results field is disabled. Usually, when the rich field is on by default, the predicted top result is highlighted and pressing "Enter" on it means the browser is being told what it is and not having to decide. So when disabled, it is instead having to decide after the fact, causing the delay.

Expected results:

Setting browser.urlbar.maxRichResults to 0 should not have an impact on search speed. Although it is considered a tweak and not a default setting, it is the only method to completely prevent the rich results field from displaying. There are situations where the rich results field is not desired so it is necessary to be able to disable it this way, and doing so should not have an impact browsing performance. I believe something will have to be done with how the browser decides something entered is a search or a URL without causing delays.

Comment 1

[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 revert this change in case you think the bot is wrong.

Comment 2

[Drew Willcoxon :adw]

I think I can reproduce this but it's hard to tell. For me it's not obviously slower, and the fact that the panel opens and closes when maxRichResults > 0 adds some visual distraction that makes a one-after-the-other comparison hard. We'd need to spend some time investigating this.

Comment 3

[Marco Bonardo [:mak]]

(In reply to Drew Willcoxon :adw from comment #2)

the fact that the panel opens and closes when maxRichResults > 0

This must be a recent regression anyway, it was reported by users in bug 1629303, but they didn't file a bug for it yet.

Comment 4

[Drew Willcoxon :adw]

I meant that in normal usage (when maxRichResults > 0), when you type something and hit enter to do a search, the panel opens and closes (as expected). But when you set maxRichResults to zero, the panel doesn't open at all. So for me at least, it's hard to do a simple visual comparison between the two to determine which one takes longer. The extra visual "noise" in the normal case might make it seem quicker, at least for me.

We'd need to do a timed comparison to see whether/how much the two cases differ.

[Edited to fix maxRichResults > 0 in normal usage, sorry!]

Comment 5

[Rares Doghi, Desktop QA]

I tried to reproduce this issue on our end but without success, its either a very small difference or not at all. Its very hard to tell. Maybe someone from our dev team can reproduce it on their end.

Comment 6

[-]

[redacted - mhoye]