Closed Bug 1532039 Opened 5 years ago Closed 4 years ago

The switch to search bar is too slow

Categories

(Firefox :: Search, defect, P3)

65 Branch
defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: kukadlo, Unassigned)

Details

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

Steps to reproduce:

I have separate address bar and search bar in the toolbar.

I left-mouse click into the search bar, preparing to edit the content of it, and hit Ctrl+A to select the whole old search phrase.

Actual results:

The currently viewed web pages gets selected instead.

It takes about 150-300ms to firefox to finally switch the cursor into the search bar after the click, while I usually hit the Ctrl+A within 100ms after click (I'm just used to snappy fast UI, I'm not even trying to be fast, if I would try to be fast, I would be probably in 30-80ms range).

Expected results:

The search bar should catch Ctrl+A lot more sooner after the click (ideally within 10ms on 3+ GHz CPU).

Also it's not Ctrl+A related, even the ordinary typing does catch up slowly, sometimes when I have the search bar empty, I start typing the search phrase immediately after clicking the search bar, and instead of entering search phrase, I end up editing the form in the current web.

Component: Untriaged → Search
Component: Search → Toolbars and Customization

Based on comment #0 this is specific to the search bar (ie I assume the same thing doesn't happen in the location bar). Dale, why did you move this?

Reporter: can you use the profiler ( https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Reporting_a_Performance_Problem ) to share a profile link of what happens when you click in the search bar?

Component: Toolbars and Customization → Search
Flags: needinfo?(kukadlo)
Flags: needinfo?(dharvey)

Sorry new to triage here, I thought the Search component mostly refererred to the backend / SearchService and the UI would come under toolbars, please move the stuff back if I get it wrong and will figure out where the boundary is, cheers

Flags: needinfo?(dharvey)
Priority: -- → P3

Will try to also collect and add profiler data, but while checking it more thoroughly, I have find something.

I use notebook with touchpad and when I use touchpad "click", it of course takes some delay before the whole click action is detected (simple touch can be also start of cursor movement, so it's after losing touch and some debounce delay the click event is produced by the touchpad driver). Don't know how to measure it precisely, but by a feel I would say it takes somewhere between 40-80ms, sometimes slightly over 100ms.

So part of the delay is in the touchpad driver, and it may be in extreme cases the "Ctrl+A" from keyboard comes maybe even milliseconds before the click-event, not sure about that, hopefully you can tell from the profiler data such nuances (whether the action at least came in the correct order).

Still I can recall the firefox is somehow more prone to demonstrate this, like there's sometimes extra 50ms before the bar is active.. or maybe I rarely use this kind of combination of actions in other SW.

address bar vs search bar - hard to tell, it feels like there actually is some difference, like +20-30ms on the search bar, but it's varying a lot (after initial click into both they seem to act quite identically, but the first click after some time of just browsing is sometimes slightly slower).

Flags: needinfo?(kukadlo)

Peter, is this still an issue? Would you still be able to try the profiler?

Flags: needinfo?(kukadlo)

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

Peter, is this still an issue? Would you still be able to try the profiler?

somehow slipped off my mind and got swamped by other issues, but I'm now at Firefox 75.0, and I don't remember similar feel as described in original issue, i.e. didn't happen to me in last 3-4 months.

... trying it few times now, I realized that when I click into the search bar (or into location bar), the content is already pre-selected (not sure if that's default or if I flipped some option to get this), which makes the original scenario of click + Ctrl+A void.

But the reaction time feels now good, just like I would expect it (when using touch-to-click, the delay seems reasonable).

So it seems either my setup was affected year ago by something, or there was some actual change done on the firefox side of things, but the current setup feels ok. (or maybe it was some badly written ad script of some page slowing it down, as even in current version, if I let some complex page open for few days or a week or so, sometimes it gets really slow and unresponsive and all kind of event driven JS becomes acting weird ... usually just closing the tab, or restarting whole firefox then helps and it works well for couple of days, so I guess some script written in very ineffective way could slightly hamper overall UI response times).

I guess we can close this at this moment, as I can't reproduce it any more. If I will run into it again, I will [re]open the issue.

Flags: needinfo?(kukadlo)
Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → WORKSFORME

Thank you for the response, I'm glad it is better now.

You need to log in before you can comment on or make changes to this bug.