Closed Bug 1766405 Opened 3 years ago Closed 3 years ago

Firefox sometimes temporarily "freezes" when opening a new tab and writing into the location bar

Categories

(Firefox :: Address Bar, defect, P2)

Firefox 100
defect
Points:
8

Tracking

()

RESOLVED INVALID

People

(Reporter: bugzilla.david, Unassigned)

References

Details

(Keywords: hang, papercut)

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

Steps to reproduce:

Context:

  • I am using Firefox Developer Edition Version 100.0b9 (64-bit).
  • My system is Windows 11.
  • I have multiple tabs open.
  • I am logged into my Firefox account for syncing.
  • It makes no difference whether I am using Firefox in troubleshooting mode or not.
  • This bug resurfaced even after a fresh install of Windows on my machine (during which I formatted the harddrive).

What did I do?

  1. I open a new tab (usually by hitting Ctrl+T). A new tab opens and the location bar is auto-focused.
  2. I start typing.

This is where Firefox sometimes seems to freeze to some extent (I will present more details in "What happened?").

From here on out, I can take three paths, each resulting in a different outcome:

(A) I complete typing my query and hit Enter right away.

(B) I wait for Firefox to catch up before completing my query and hitting Enter.

(C) I move my mouse before completing my query and hitting Enter.

Actual results:

After going through steps 1 and 2 as descriped above, sometimes (usually about every 10th to 20th attempt, sometimes much more often - I could not identify a pattern) the following occurs:

After a random amount of characters entered (usually 1-3) into the location bar, all further characters will not be displayed. Also no suggestions will be shown below the location bar.

(A) If I nevertheless complete my query and hit Enter right away, Firefox will remain frozen for a few seconds (I'd say 2-20), and then execute my query using only those (usually 1-3) characters that were displayed in the location bar. Usually this takes me to a website I have frequently visited in the past starting with those letters.

In other words: Firefox seems to just "forget" all characters entered after the freeze starts, then autocomplete the few characters I entered before the freeze and then take my Enter as a confirmation of the suggested autocompletion (which I never saw).

(B) If I decide to wait for Firefox to catch up, I'll have to wait for about 2-20 seconds. I know Firefox has caught up when suddenly suggestions appear below the location bar. I can then proceed to enter and submit my query without problem.

(C) This is the strangest thing: As soon as I move my mouse the tiniest bit the freeze ends immediately and I can proceed entering and submitting my query. I have tested this about 10-20 times now, waiting different amounts of time before moving the mouse to make sure it is actually the mouse movement triggering Firefox to wake up. I am now sure of it.

Expected results:

Firefox should not freeze mid-entering my query into the location bar.

P.S.: I just remembered... I am pretty sure I also ran into this bug when I was not logged into my Firefox account (and thus syncing was inactive).

P.P.S.: When filling in the form, there were three form fields (I believe they were titled "What did you do?", "What happened?" and "What did you expect to happen?"). When submitting the form these three form fields were automatically merged and renamed (which I don't think I was informed about).

Therefore, my reference to "What happened?" actually refers to the section "Actual results".

Component: Untriaged → Performance
Keywords: hang
Product: Firefox → Core

I just experienced an instance that did not fit into the three cases described before (A, B, C):

(D)
I open a new tab. The location bar get's auto-focused.
I enter my query.
Again no suggestions are shown below the location bar. However, this time all entered characters are being displayed in the bar.
I submit my query by hitting Enter. Nothing happens.
I then move my mouse.
My query is executed immediatly - correctly (!).

So, all in all, from what I can tell, this is the pattern if the bug occurs:

For a query to be processed, two things must have happened:

  • I must have hit Enter at some point.
  • Firefox must have "awoken" at some point.
    The order of those two events does not matter. The query will be executed, as soon as the second one of those two events has occurred.

The query will be executed using exactly those characters that are visible in the location bar at the time. It does not matter, whether I entered more characters than visible or not.

If this (sometimes partial) query can be auto-completed, it will be.

(What I do not know as of yet: What happens if I start typing a query, then hit Enter, then proceed typing before waking up Firefox by moving the mouse?)

I am sorry for this piecemeal bug submission. This bug is very inconsistent and occurs unpredictably, which makes it hard for me to test.

Just guessing, what's your monitor refresh rate? We've recently seen reports where some background work was not happening because the browser was busy rendering at 250Hz or so.
Also, how reproducible is this? If you can manage to capture a profile of it using https://profiler.firefox.com/ , that would be super useful.

Flags: needinfo?(bugzilla.david)

Thank you for looking into this!

I am sorry, if some or most of the information I am sharing is irrelevant. My knowledge about hardware is very limited.

Most of the time I am using a two monitor setup. One is the notebook's display, the other an external monitor. Both can achieve a 60Hz refresh rate. Currently, the external monitor is set to 60Hz - the notebook's display is set to 59.94Hz (as I just found out).

Both monitors are 4K. Idk if this is relevant. My thought is, that maybe this might still fit your guess: The refresh rate might be 4x lower (60Hz instead of 250Hz), but there are 4x more pixels to render to than is the case with FullHD.

My notebook is a Lenovo P1 Gen2:
CPU: Intel Core i7-9750H CPU @ 2.60GHz
RAM: 32 GB
GPUs: Intel UHD Graphics 630, NVIDIA Quadro T1000

According to the NVIDIA Control Panel Firefox was configured to prefer integrated graphics (I have altered this setting to prefer the NVIDIA graphics card now).

I very rarely use my notebook on its own, without the external monitor plugged in. I am currently not sure if I ever ran into this bug when doing so.

Regarding your second question: Sadly, I haven't yet found a way to trigger this bug. If I do find a way, I'll make sure to capture a profile of it.

Flags: needinfo?(bugzilla.david)

Thank you. So then this is probably unrelated to those recent issues I was referring to.

Unfortunately we probably won't be able to do much about this problem without having a way to reproduce it, or at least a profile of it happening.

I do agree that it's super weird that moving the mouse is enough to interrupt this dazed state.

Have there been other reports of similar performance issues with the URL bar recently?

Component: Performance → Address Bar
Flags: needinfo?(dao+bmo)
Product: Core → Firefox

(In reply to Markus Stange [:mstange] from comment #7)

Have there been other reports of similar performance issues with the URL bar recently?

Not that I know. standard8 took a quick look at sumo and wasn't seeing anything there either. We can let this go through regular triage and see if someone else has ideas.

Flags: needinfo?(dao+bmo)

Bug 1765298 is very similar including the report that moving the mouse fixes it...

See Also: → 1765298

A short update on this: I haven't run into this bug for quite a few days now. I don't think, I changed anything. It might have been fixed in a recent update.

The severity field is not set for this bug.
:adw, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(adw)
Severity: -- → S2
Points: --- → 8
Flags: needinfo?(adw)
Priority: -- → P2
Keywords: papercut

Since the bug isn't reproducible for the user anymore, I'll close it as invalid.
Please feel free to reopen it again if the bug is still reproducible on your end.

Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.