Searches from the address bar end up truncated
Categories
(Firefox :: Address Bar, defect, P1)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr68 | --- | unaffected |
firefox-esr78 | --- | unaffected |
firefox78 | --- | unaffected |
firefox79 | --- | unaffected |
firefox80 | blocking | verified |
People
(Reporter: jrmuizel, Assigned: bugzilla)
References
(Regression)
Details
(Keywords: regression)
This happened to me twice today. I'll type out something into the address bar to search for it and I'll only end up getting the first part of my search query
e.g. I type "not with standing clause" [Enter]
I get a Google search for "not with sta"
Reporter | ||
Comment 1•4 years ago
|
||
I can't reproduce with a fresh profile. I suspect it's something to do with the size of my history being larger.
Comment 2•4 years ago
|
||
I am also getting truncated search queries for searches made before search suggestions are produced. I'm also unable to reproduce it with a fresh profile. Using mozregression with my existing profile I narrowed it down to:
Last good revision: fca47cf383820aa9ac7f87c0733709a6bfabd1bb
First bad revision: 366f7bfe267cb4a7781c41cdb5a691d75c018622
Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=fca47cf383820aa9ac7f87c0733709a6bfabd1bb&tochange=366f7bfe267cb4a7781c41cdb5a691d75c018622
I believe that is accurate, but since it is a race there may be a false positive if I typed too slowly.
Comment 4•4 years ago
|
||
[Tracking Requested - why for this release]: Basic urlbar functionality
Updated•4 years ago
|
Updated•4 years ago
|
Assignee | ||
Comment 5•4 years ago
|
||
Jeff, I think you're right that this only affects users with large Places DBs.
The stack of patches in the regression window change the way we generate the first Urlbar result. In the past, it blocked on a Places DB lookup. With that stack applied, it does not, meaning it's generated much more quickly. This causes a race when the Places lookup is slow. Furthermore, that stack of patches was the first of two large stacks of patches that all work on the same thing. The second is in bug 1648468.
I wanted to land this stack separately from bug 1648468 so mozregression could find regressions more easily. To accomplish this, I added a bit of stopgap code to the stack at fault here to allow it to function without the changes in bug 1648468. The stopgap code is then removed in bug 1648468. The issue appears to be with the stopgap code; if UnifiedComplete is slow to returns its results, this truncation issue is triggered. In trying to make regressions easier to find, I appear to have created a new one...
I can't reproduce the issue in this bug, but Marco can. He applied the stack of patches for bug 1648468 and this issue appears to be resolved. I'm going to land bug 1648468. If this issue persists, I'll back out both bug 1648468 and the stack of patches implicated here.
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Comment 6•4 years ago
|
||
(In reply to Harry Twyford [:harry] from comment #5)
He applied the stack of patches for bug 1648468 and this issue appears to be resolved. I'm going to land bug 1648468. If this issue persists, I'll back out both bug 1648468 and the stack of patches implicated here.
This bug should depend on bug 1648468 if that fixes the issue.
Assignee | ||
Comment 7•4 years ago
|
||
Unfortunately one last test failure blocked the landing of bug 1648468. Fixing that test will require some outside input so it likely won't happen until Monday at the earliest. I've requested backout on bug 1645324 and its parent bug 1645521. I'll be sure to do some more testing with a larger Places DB before relanding them!
Comment 9•4 years ago
|
||
It's not because your profile is clogged up, it's probably because you just happened to be typing faster the first time. I'm able to reproduce it with a fresh profile to the same frequency as with my normal profile. The only way I can get it to search what I'm actually typing is by either typing more slowly or by pausing for a second before hitting enter. I type about 140 words per minute for these short bursts like entering a search query, that is way more than the urlbar can apparently handle now. Never had a problem before yesterday but now it's literally every search query unless I purposefully type at like 60 wpm or pause between typing and hitting enter.
Comment 10•4 years ago
|
||
by fresh profile I mean one with a default places db and not signed into firefox account.
Updated•4 years ago
|
Comment 13•4 years ago
|
||
Was this not caught by the existing test because the test wasn't inputting enough characters to trigger the race?
Comment 14•4 years ago
|
||
That test is for a completely different race bug.
Assignee | ||
Comment 15•4 years ago
|
||
The backout of bug 1645324 and bug 1645521 failed -- there was an additional patch that had to be backed out as well. The silver lining is that Drew was able to figure out the final test failure for bug 1648468 (see bug 1648468 comment 7 -- thanks Drew!). Bug 1648468 now passes try. I was also eventually able to reproduce this bug locally and verified that bug 1648468 fixes the issue on my machine as it did for Marco.
I'm going to revert to the plan I outlined in comment 5: land bug 1648468, and keep a close eye on this bug. If it's not resolved, then I'll back out both bug 1648468 and the patches that caused this bug.
Comment 26•4 years ago
•
|
||
I can reproduce 100% ; even on a machine I very rarely use (though also synced to my firefox account)
1- Open a new tab
2- Quickly type "this is a long new search" and immediately press enter; it must be all done before auto-completion activates
It will lead me to the page:
https://www.google.com/search?client=firefox-b-d&q=this+is+a+
"this is a" is all it would have searched for.
Assignee | ||
Comment 27•4 years ago
|
||
Can you reproduce on the latest Nightly? The issue has been fixed for me since midday yesterday. The offending patch was backed out in yesterday's Nightly, then was relanded with bug 1648468 for this morning's (EST) Nightly.
Comment 28•4 years ago
|
||
it's fixed for me too.
Comment 30•4 years ago
|
||
I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1652347 which is dupe of this, and it's fixed for me now.
Assignee | ||
Comment 31•4 years ago
|
||
Thanks for letting me know. I'll close as FIXED. For QA, here's the STR from bug 1652347:
STR:
- Focus into the awesome bar
- Type a search phrase like "search for nasa spacex"
- Press "Enter" quickly after finishing typing the phrase
In an affected build, you can also see that the text in the first Urlbar result does not keep up with what the user types.
Assignee | ||
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Comment 33•3 years ago
|
||
Issue is verified fixed on the latest 96.0a1 and 95.0b9 on windows 10 and ubuntu 20.04. The search phrase is no longer truncated and there have been no reports of this happening again.
Comment 34•3 years ago
|
||
Using 95 on Windows I am still having this issue when the computer is under heavy load (e.g. loading a lot of tabs at the same time, or another program is doing something CPU intensive).
Description
•