1750317 - location bar search intermittently fails to reach search engine input

Status: RESOLVED FIXED

(Firefox :: Address Bar, defect, P3)

Description

[Optional]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:96.0) Gecko/20100101 Firefox/96.0

Steps to reproduce:

• type search string in location bar
• type return

Actual results:

• search engine page loads with partial search string as search entry
• returns results based on the partial string

Expected results:

Expect to see entire string searched as entered and confirmed in the location bar. I think this behaviour started with FFv95.

I titled intermittent because I can't replicate at will and haven't found dependencies. I searched for Firefox window anatomy to ensure I use common terms here, and when I typed "firefox address bar" in the location bar, DuckDuckGo came back with "firefox ad" and appropriate results. I immediately made other random searches and couldn't repeat the error. I'd guess this happens one in ten search attempts using the location bar for input.

It feels like something is lagging inside the process and a lot of other small things suffer the same way, like tab animations not loading until the action is ending, but I'm waiting things out with little evidence to share. Have also toggled "network.http.http3.enabled" from recent news, but didn't see any reaction to it.

Comment 1

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

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

Comment 2

[Jeronimo Torti (Please send NI request to Brindusa Tot)]

Hi,
I have tried to reproduce the issue on Windows 10, on Firefox Nightly 98.0a1 (2022-01-27) (64-bit) and Release 96.0.3 (64-bit) versions, but I was unable to reproduce this. Also not sure if I am understanding properly the issue. Could you answer the following questions in order to further investigate it?

1. Does this issue occur in the latest nightly version of firefox? Here is a link from where you can download it: https://www.mozilla.org/en-US/firefox/channel/desktop/

2. Does this issue happen with a new profile? Here is a link on how to create a new profile: https://support.mozilla.org/en-US/kb/profile-manager-create-remove-switch-firefox-profiles

Can you test the issue while in Safe Mode (Safe Mode disables add-ons, extensions and themes, hardware acceleration and some JavaScript stuff in order to exclude some possible reasons for problems). You can find helpful info here : https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode.

3. Does this issue occur with another search engine than Duck Duck go?

If you are still able to reproduce it, please, share further information with us screen recording, or more specific steps (i.e, the terms or specific search string you notice the issue)

I let the assigned component in order to get the dev team involved.
'Firefox-Address bar' team: if the component is not relevant please change it to a more appropriate one.

Regards,
Jerónimo.

Comment 3

[Optional]

I have not seen any activity or state that would serve as a trigger, only that I notice because I look at the search results and the search string is truncated from what I typed in. The desired term is always in the location bar as I typically watch that to ensure my spelling is correct. It's not even related to the length of the search term, long and short both botched. If I felt something was triggering, it happens frequently enough I would have sensed it by now. I am saving this ticket if anything new comes to mind.

It didn't happen until v95, at which point I thought it was a random glitch until happening more frequently with v96.

Because I can't recreate it at will, I see no reason to shotgun everything out there to judge if it has been magically healed. What would be the point? Would it be declared resolved if I went three weeks without an incident with nightly? Is that the goal? Isn't there a non-destructive mechanism to log events, that I could pull up and forward if it the truncate just occured? If I move to a new monthly and it's thankfully fixed, great, I got what I wanted and didn't spend any time on it. If developers don't want to know why, my depth of caring is always going to be a step down from that.

Comment 4

[Optional]

I do not use "Workona" extension.

Comment 5

[Optional]

Fair enough. I'm onto v97 now with no change, intermittent but present. I really do want FF programmers to succeed but I have little to offer here except to continue feeding my experiences.

After using FF for an extended period of wondering what's going on, I'm confident the DuckDuckGo search term fail is associated with lag and timing, and further, that smells like JS. With 4GB and a tired CPU it would be easy to write this off, but whenever I check resources FF isn't even close to pushing limits. Sometimes FF is completely idle by the time I check. A couple of days ago I had to laugh because a long search term submitted only the first few characters and completely abandoned multiple words, like typing "Little Red Riding Hood" and it went searching for "Lit."

Basically, I identify lag as slow rendering and slow response to my inputs, and everything has slowed since v95, noting that every rev claims smaller footprint and faster code. I can pop up only about 5 tabs now because FF bogs down trying to complete every tab and task before I can interact with any single page. I can load 25 tabs if I choose, but they'll all be unusable for 10 minutes and bog down once accessed. If I go to Youtube and pop up a dozen videos in new tabs, each tab played and closed gradually slows until things finally get squirrelly enough I need to quit and relaunch. Relaunching is actually an improvement to the original window because the tabs are restored by choice and FF doesn't seem to care about unaccessed tabs until I select them, so I can plow through remaining tabs without an issue. This has proven true on other sites, to the point where I launch new tabs until the mouse response starts to slow on links, then quit and relaunch without trying to view any tab, and everything remains speedy and stable. Why doesn't FF just behave that way when the tabs are created? Sites with insanely rotating ads are barely usable but my 10Mb throughput tests fine, so I blame those site's dependence on their ad servers.

Hovers, window controls, selecting or moving tabs, menu, all of it seems to pause as if every item is stacked in the same place, so a small issue on one tab becomes a traffic jam for everything. I can't select "Go back" to escape something bad as I never get the hover cue, which seems to be the way FF is programmed; FF may have been identical in the past but I never noticed because control response was immediate. One of the worst things is the busy animation on a tab, sometimes taking so long to activate that I assume I missed my selection or never made it to the control hover response, then the page decides to render three "go backs" past what I wanted, no doubt slowing things further. I no longer expect to use a ready tab with others incomplete as on-page selections may not respond until all tabs have finished rendering. Even then it may take a few seconds to render my selected tab after it claimed to be ready.

A particular site of crosswords, that seems to have a lot of badness in script or ad rendering and always did suck, now forces me to relaunch FF every third puzzle as it eventually slows to nothing and the OS won't even let me switch programs, worse case leading to a forced reboot. I find it odd that any application can slowly die and take the OS with it when it would be handier to just crash and get it over with. I'm sure that game site is a mess so I don't think it serves as evidence, but comparatively, it has gradually grown worse as if every browser update is slightly less capable of handling its mess.

PS: I just got a new mouse which should eliminate the possibility of multi-click fails, and I don't question the keyboard because search terms are always accurate in the location bar, as input. Is there a setting for FF to prioritize my active tab?

Comment 6

[Optional]

It's obvious to me now that the worse the lag grows the more frequent and larger the input chops become. I blame this bug report on my surprise when it started, but now it's the norm.

I'm just surprised that FF Linux on 4GB RAM has come to this; one application and a couple of tabs. It's getting laborious to launch anything beside FF. Script-heavy sites slowly grow unusable. Selections act on renders that haven't even started, tabs refresh after already closing, videos dump frames, and I need to relaunch after a stretch of activity before it dies. Chrome is sometimes better at sites where FF falls down, but FF is usually best.

This is what is, and I'm sad that the last two years have taken my old laptop from feeling reborn with eOS and a SSD, to in sight of unusable. There's life here if I'm patient. I found one life-sucking eOS daemon that I removed, but now I realize that the worst of "Isolated Web Co" are taking hundreds of MBs. One terrible simple game site launches up to 24 separate processes for a single tab, that I assume are related to advertising.

Unless there's a new event or process model on the horizon, feel free to close this as there will never be a solution beyond a new computer.

Comment 7

[Ansgar Wohl]

I was going to post a new bug report when I found this one.

I have the exact same problem since Firefox 95 or 96 (I'm not sure). I'm using macOS Monterey on an older Macbook from 2015.
When I enter something in the location bar and press the Return key too fast, only the first part of my search term is transmitted to the search engine. It happens often and is really annoying. In earlier versions of Firefox on the same Mac it never happened, so it must be a regression.

I can reproduce the problem with a brand new profile, however, since Firefox is faster without all my extensions and open windows, it's more difficult to trigger the bug. I can still reproduce it like this:

• Copy some longer text to the clipboard, e.g. " sometimes eats my search input".
• Enter "Firefox" in the location bar.
• Press Cmd-V and, with the other hand, immediately press Return.

In about 1 out of 3 attempts, you can see the long text appearing in the location bar for a split second, then it's gone and you see your search results for "Firefox". The location bar shows your search engine URL with the query "Firefox". The long text is gone. (The reason why the text in the clipboard should be not too short is that it's easier for the eyes to spot a longer text in the location bar. That way you can be sure that you really pressed Cmd-V first and then Return and not the other way round – in the latter case the observed behaviour would actually be correct.)

I guess if I tried this on a faster computer and with a new profile, it would be almost impossible to reproduce the bug.
But it's still there, and on my slow Mac, it's really annoying.

Comment 8

[Ansgar Wohl]

Yes, 1762635 is definitely the same bug.

Does this issue occur in the latest nightly version of firefox? Here is a link from where you can download it: https://www.mozilla.org/en-US/firefox/channel/desktop/

Yes

Does this issue happen with a new profile? Here is a link on how to create a new profile: https://support.mozilla.org/en-US/kb/profile-manager-create-remove-switch-firefox-profiles

Yes

Can you test the issue while in Safe Mode (Safe Mode disables add-ons, extensions and themes, hardware acceleration and some JavaScript stuff in order to exclude some possible reasons for problems). You can find helpful info here : https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode.

Still reproducible.

Does this issue occur with another search engine than Duck Duck go?

Yes, I have just changed my search engine to Bing and it "works" the same way.

Comment 9

[Optional]

Just testing something without a conclusion as yet, but I put up a permanent search field and I haven't had an input disrupted since. I continue to watch this. I'm not using the search field and simply typing my searches in the location field as before. I'm thinking there might be a readiness with the search field open that requires a laggy decision from the location field without.

I don't want to moan more about bloat, but with v98 I definitely lost more potentially open tabs. I'm doing my best to adapt my habits. It doesn't look like RAM, it feels more like my slow processor can't hide the buffering going on any longer, when interface is regarded as real time.

Comment 10

[Cristian Baica [:cbaica], Release Desktop QA]

I have re-tested this again on 2 separate machines with different computer specs, but I was unable to reproduce the issue (in more than 20 tries). The performed search was always done for the full phrase that was inserted in the address bar.

Could you maybe provide us with some information regarding the CPU model and how much RAM your machine has, so we could search some similar hardware or maybe set up a similar spec VM?

Comment 11

[Optional]

(In reply to Cristian Baica [:cbaica], Release Desktop QA from comment #10)>
Thank you for testing, and for your curiosity.

CPU model and how much RAM your machine has, so we could search some similar hardware or maybe set up a similar spec VM?
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:96.0) Gecko/20100101 Firefox/96.0

Dual-Core Intel® Core™2 Duo CPU T9300 @ 2.50GHz
NVIDIA Corporation G86M [Quadro NVS 135M] (rev a1)
4.0 GB memory
471.5 GB storage (SATA SSD)

elementary OS 5.1.7 Hera
Built on Ubuntu 18.04.6 LTS
Linux 4.15.0-175-generic
GTK 3.22.30

I just disabled <Performance/Use recommended performance settings/Use hardware acceleration when available> because I read it might improve displayed colour space.

Nothing to brag about and why I keep writing like my night must come. My process monitor never indicates pushing the RAM limit and I can launch a few things simultaneously, but CPU is constantly maxing out with Firefox alone. When that happens, often, everything is full stop until the browser catches up first. I suspect nothing is wrong there, just behaving efficiently with the given priorities. What feels like lag, swapping, and thunking seems to be a CPU shortcoming, trying to keep up. CPU1 and 2 are in lockstep with no special applications, and as I was writing this the CPU maxed out with no other user activity, probably the open game tab gulping down a fresh ad because the network spiked at the same time. I try to overload things to test search but it never fails on demand, only random when least expected, but I have definitely typed search entries that appeared as typed then watched them disappear from the results, so I know it's not my input.

It just happened to me right now. I thought I'd check my Yoda sensibilities so I opened a sixth tab to search, a tenuous thing. I also had Chrome, Document Viewer, Thunderbird, and System Monitor running for no free rides. The cursor moved when I was typing, ick, so I re-cursored the location field and retypedyoda quote my night must come

I looked, realized I had messed up highlighting and failed to overwrite my first failure, an insert instead. The input field actually readyoda quote my night must come https://duckduckgo.com/?t=ffab&q=yoda+quote+mu&ia=weband I hadn't punched enter as I was on a roll.

Well, duh. So, I swipedhttps://duckduckgo.com/?t=ffab&q=yoda+quote+mu&ia=webthen backspace and enter to search onlyyoda quote my night must comeand search results came back like the previous failed input that I didn't bother searching, as if I hadn't made the deletion. Now I know it's not edit-style dependent. I'd guess related to the speed I hit backspace and enter at a critical moment.

An aside about my previous comment: recently had two words of three chopped off so having the discrete search field up is unrelated.

For the curious, Yoda said "Soon will I rest, yes, forever sleep. Earned it I have. Twilight is upon me, soon night must fall."

Comment 12

[Ansgar Wohl]

(In reply to Cristian Baica [:cbaica], Release Desktop QA from comment #10)

I have re-tested this again on 2 separate machines with different computer specs, but I was unable to reproduce the issue (in more than 20 tries). The performed search was always done for the full phrase that was inserted in the address bar.

Could you maybe provide us with some information regarding the CPU model and how much RAM your machine has, so we could search some similar hardware or maybe set up a similar spec VM?

I have just reproduced this bug on a Mac with a 2.7 GHz Ivy Bridge Core i7 with 16GB RAM. It's really easy to reproduce if you run a few instances of something like "yes > /dev/null" in the background.

I have also taken the time to do a bisection with mozregression, and to my astonishment, the bug is rather old. The last good nightly is the one from 2020-10-15. I have tried everything to reproduce the bug there, even encoded some HD videos in the background – the bug absolutely never happens there. On the same machine, you can easily reproduce the bug with the nightly from 2020-10-16. I switched back and forth between the two builds and I could definitely confirm the finding.

I guess the reason why this hasn't been noticed until now is that the location bar has become slower for some reason in FF 95 or 96, and now the bug that slipped in on 2020-10-16 is triggered (on older machines) even if you don't have a 100% CPU load.

Unfortunately, I could not get a more exact result from mozregression, because taskcluster builds are only available for the previous year and this bug is older. Still, it must be something that was checked in on 2020-10-16.

Comment 13

[Optional]

Thank you, I admire your acumen. Virtual or not, I'm glad it proofed on a machine that should be a notch more impressive than what I'm driving.

I saw something new yesterday, after a badly aimed swipe on copy, where a I deleted the tail end of a manually pasted link while watching, then enter. After a server error I looked up and the part I had just deleted had returned. I hadn't touched the mouse or cursor since the edit, having used the keyboard to tidy it up. Maybe the location field thing in general has nothing to do with search and it's only coincidental that's were the majority of keyboard entry happens.

Comment 14

[Cristian Baica [:cbaica], Release Desktop QA]

Setting the bug to 'new'. Thank you Ansgar for reproducing and finding the regression range.

Based on your provided dates, i believe this is the range:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=3a9fcbf00f37714e083b447a059ad543e50eee71&tochange=ac431d6e63f0fe54b7670e7c072da5352cd35092

Comment 15

[Ansgar Wohl]

Attachment: sample_patch

Thanks Cristian for the link to the regression range. I was able to identify the following change as the culprit:

https://hg.mozilla.org/mozilla-central/rev/0b6cb70fd50350497730beb217c8fa19a598f280

It seems that in UrlbarEventBufferer.jsm, the search result array is no longer copied in onQueryResults. Instead the results are directly accessed from the queryContext. Therefore waitingFirstResult becomes false too early and the Return key event is not deferred, resulting in the truncated search string.

I have attached a minimal patch that fixes this bug by reverting this (in my opinion unnecessary) part of the changeset. The patch is not supposed to be commited as is, I only think it might help the person who will properly fix the issue.

Comment 16

[Ansgar Wohl]

Maybe the author of the commit that caused the issue can have a look at this?

Comment 17

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

Set release status flags based on info from the regressing bug 1647925

Comment 19

[Marco Bonardo [:mak]]

Thanks everyone, taking for investigating the provided information.

Comment 20

[Ansgar Wohl]

Is there anything more I can do to get this fixed more quickly? This bug is extremely annoying on older machines and applying the provided patch to every new Firefox version oneself isn't really a viable workaround.

Comment 22

[Ansgar Wohl]

This bug has been reported 8 months ago, the exact regression has been found 6 months ago, and a minmal working patch has been provided. I did invest a few hours of my time for that – I don't usually have the Firefox source code lying around somewhere. Fixing this bug with the help of the information provided should be trivial, at least it seems so.

4 months ago, I have asked if I could help with anything more to finally get this bug fixed.

Nothing happened. Probably we could wait for a few more releases and the bug still would not be fixed.

Is it too much to ask that at least a brief explanation be given here as to where the problem lies?

Comment 23

[Ansgar Wohl]

Unfortunately, after 12 months, this bug is still not fixed and it still drives me crazy, and it looks like noone is going to fix it even though I have provided a patch 9 months ago.
I'm sorry to pester you, but I'll have to try again to move things forward. If there's a reason that I just don't see why this cannot be easily fixed, it would be really nice if that reason could be stated here.

Comment 24

[Marco Bonardo [:mak]]

I'm sorry this slipped through the cracks, I will find some time later this week to look back at it.

Comment 25

[Marco Bonardo [:mak]]

From a quick analysis I think the problem is that the queryContext gets filled with results before the controller and the view are notified of those results, onQueryResults is called later. So ideally it should be sufficient to add another state to distinguish when some results were notified.
That seems to just add a bit of delay that is probably allowing some additional input events to arrive, I'm not sure it will solve the problem completely, but it seems worth it, and definitely it's the original intent. Adding an automated test for it may not be trivial though, I'll have to play with it a little bit.

Comment 26

[Marco Bonardo [:mak]]

Attachment: Bug 1750317 - Address bar may cut the search string in rare circumstances. r=adw

The bug covers a case where, usually due to a busy system, events may be
delayed causing the urlbar bufferer to handle Enter before the current context
has notified any result to the view. In that case we may serve a partial
search string.
The patch makes the events bufferer wait for the onQueryResults notification
rather than just relying on results being present in the context object

Comment 27

[Marco Bonardo [:mak]]

Thank you again for your investigation, that helped a lot figuring out the problem.

Out of curiosity, did you uncheck the Search Engines option in the Address Bar section of Preferences / Privacy And Security?

Comment 28

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/9660e48a4f82
Address bar may cut the search string in rare circumstances. r=adw

Comment 29

[Stephan Sokolow]

"Rare" is a matter of perspective.

On my old CPU and with my Firefox bogged down with anti-tracking extensions and Tree Style Tabs, I'm almost constantly forgetting to stop before pressing Enter to wait for the popup to update and then cursing when DuckDuckGo searches for only part of what I typed or I accidentally search DuckDuckGo for eb thing rather than searching eBay for thing.

Comment 30

[Stephan Sokolow]

(In reply to Stephan Sokolow from comment #29)

"Rare" is a matter of perspective.

On my old CPU and with my Firefox bogged down with anti-tracking extensions and Tree Style Tabs, I'm almost constantly forgetting to stop before pressing Enter to wait for the popup to update and then cursing when DuckDuckGo searches for only part of what I typed or I accidentally search DuckDuckGo for eb thing rather than searching eBay for thing.

Clarification: Thank you VERY much for this fix.

(Sorry I had to send two e-mails to make that clear. I just woke up and I'm not firing on all cylinders yet.)

Comment 31

[Marco Bonardo [:mak]]

(In reply to Stephan Sokolow from comment #29)

On my old CPU and with my Firefox bogged down with anti-tracking extensions and Tree Style Tabs, I'm almost constantly forgetting to stop before pressing Enter to wait for the popup to update and then cursing when DuckDuckGo searches for only part of what I typed or I accidentally search DuckDuckGo for eb thing rather than searching eBay for thing.

While this is likely to help, we don't know if it's the only race condition we may have, so your real-world testing will be very useful, please let us know once this fix is available in a build you can use.

Comment 32

[Stephan Sokolow]

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

(In reply to Stephan Sokolow from comment #29)

On my old CPU and with my Firefox bogged down with anti-tracking extensions and Tree Style Tabs, I'm almost constantly forgetting to stop before pressing Enter to wait for the popup to update and then cursing when DuckDuckGo searches for only part of what I typed or I accidentally search DuckDuckGo for eb thing rather than searching eBay for thing.

While this is likely to help, we don't know if it's the only race condition we may have, so your real-world testing will be very useful, please let us know once this fix is available in a build you can use.

Will do. Does Mozilla publish any beta or developer channel releases via Flatpak that I could switch to in order to get my hands on it more quickly without having to port my customized sandboxing settings to Firejail?

Comment 33

[Marco Bonardo [:mak]]

There is an unofficial flatpak here I think https://firefox-flatpak.mojefedora.cz/
The patch has not been merged to Nightly yet, it will be the day after this bug is marked as resolved.

Comment 34

[Stephan Sokolow]

Hmm. Different AppID means I'll have to rename a bunch of files to migrate my profile and manifest overrides back and forth between them, which is more annoying than just setting a boolean to tell Developer Edition to not use a separate profile was back in the pre-sandboxed days, but I'll consider it.

Comment 35

[Serban Stanca [:SerbanS]]

https://hg.mozilla.org/mozilla-central/rev/9660e48a4f82

Comment 36

[Adrian Florinescu [:aflorinescu]]

Unfortunately, even with comment 12 proposal, we're not hitting the issue reliably in order to properly verify it, marking as qe- for now.