1722313 - Browser hangs in s consuming 1 cpu when trying to open bookmarks window

Status: RESOLVED WORKSFORME

(Firefox :: General, defect)

Description

[dootpehr]

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

Steps to reproduce:

Open private window.
Open google maps page.
Use keyboard shortcut to open bookmarks window (Ctrl+Shift+O) or use menu to invoke it.

It happens only in case of normal startup. In safe mode window appears. But in case of normal startup with all addons explicitly shown in addons tab being disabled those steps still hang application up.
Issue is reproduced on windows 7 x64. 32-bit ubuntu version doesn't fail.
Issue is reproduced on newly created profile. A link to dropbox file with screen capture video (bug report with attached 20MB file failed to be submitted):

https://www.dropbox.com/s/yefk7craangs6eh/capture_Mon_Jul_26_17.10.31.mkv?dl=0

Partial support text:
Name: Firefox
Version: 90.0.2
Build ID: 20210721174149
Distribution ID:
Update Channel: release
User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:90.0) Gecko/20100101 Firefox/90.0
OS: Windows_NT 6.1 7601
Launcher Process: Enabled
Multiprocess Windows: 2/2
Fission Windows: 0/2 Disabled by default
Remote Processes: 4
Enterprise Policies: Inactive
Google Location Service Key: Found
Google Safebrowsing Key: Found
Mozilla Location Service Key: Found
Safe Mode: false

Crash Reports for the Last 3 Days

Firefox Features

Name: DoH Roll-Out
Version: 2.0.0
ID: [e-mail]

Name: Firefox Screenshots
Version: 39.0.1
ID: [e-mail]

Name: Form Autofill
Version: 1.0.1
ID: [e-mail]

Name: Picture-In-Picture
Version: 1.0.0
ID: [e-mail]

Name: Reset Search Defaults
Version: 2.0.0
ID: [e-mail]

Name: Web Compatibility Interventions
Version: 23.1.0
ID: [e-mail]

Name: WebCompat Reporter
Version: 1.4.2
ID: [e-mail]

Remote Features

upgradeDialog: (upgradeDialog-defaultEnabled)

Remote Processes

Type: Web Content
Count: 1 / 8

Type: Privileged About
Count: 1

Type: Extension
Count: 1

Type: Preallocated
Count: 1

Add-ons

Name: Amazon.com
Type: extension
Version: 1.3
Enabled: true
ID: [e-mail]

Name: Bing
Type: extension
Version: 1.3
Enabled: true
ID: [e-mail]

Name: DuckDuckGo
Type: extension
Version: 1.1
Enabled: true
ID: [e-mail]

Name: Google
Type: extension
Version: 1.1
Enabled: true
ID: [e-mail]

Name: Wikipedia (en)
Type: extension
Version: 1.1
Enabled: true
ID: [e-mail]

Actual results:

Main process locked consuming 1 CPU. After being killed and launched again application doesn't have any crash information on support tab.

Expected results:

Actually a bookmarks management window should appear.

Comment 1

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

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

Comment 2

[dootpehr]

I did a clean install of firefox on another windows 7 machine. Bug doesn't reproduce.
My copy of firefox was initially installed as 32-bit application in 2014 as version 27.0.1. After updates it still resides in Program Files (x86) but is now a 64-bit version. This is the only thing that makes a difference.

Comment 3

[Pablo]

I was able to reproduce (not as a crash) on release + beta + nightly, tested this with :
Release 90.0.2 64bit
Beta 91.0b7 64bit
Nightly 92.0a1 64bit

using:

Windows7 64bit : affected
Windows 10 : NOT affected
Ubuntu 20 64bit : NOT affected
Mac 10.15 : NOT affected

In my windows 7, the firefox windows stops responding, I waited more than a minute and it still kept not responding. It was not giving me a crash.
then i tried the 32bit distribution on windows7 and it froze, not responding for more than 30 seconds, it finally gave me the bookmarks but the whole map went black.

-In my machine, the window kept not responding even in normal browsing mode, no need to go into private mode.
-also after i closed firefox and launched again with the same profile, it still kept freezing when I tried to do the same steps.

i will set the bug as new.

Comment 4

[dootpehr]

Using Pablo's suggestion I was patient and after 23 minutes 29 seconds and an out of memory warning on a machine with 16 GB of RAM bookmarks window was shown.

Comment 5

[dootpehr]

Repeating the test. Resource monitor shows changes in firefox process commit size. Changes are made back and forth in large steps with a little ever growing overhead and growing step size (started from 4 GB, now 7 GB). That leads to out of memory warning. Process working set remains unchanged.

Comment 6

[dootpehr]

After 27 minutes and 3 seconds firefox showed bookmarks management window again. At the end process changed commit size in 9 GB steps. After ending the operation subsequent calls of invoking problematic window were executed instantly. Process commit size remained more than 8 GB.

Comment 7

[dootpehr]

After update my copy of firefox still freezes under described conditions. Yet I tried to recreate such state on other windows 7. I installed 49.0.1 x32 standalone copy, then updated it to latest version with platform change to x64. Obtained copy doesn't reproduce bug. I guess that my system which is quite old is in a state that is not easy to replicate. I was lucky that someone could confirm the bug. But I doubt that it can easily fixed.

Comment 8

[Pablo]

My system kind of old. it is an intel core i5 3570k with windows7 64bit installed less than 6 months ago.
It is also using the integrated Intel HD4000 graphics card.
I hope this information helps to the devs when they take a look at the problem.

regards

Comment 9

[dootpehr]

Bug is not reproduced on version 94.0.2. I'll keep an eye on this issue as a precaution. Still it deserves to be marked as resolved. But the interface doesn't give me correct option for a resolution type. It's unclear for me why is that so.

Comment 10

[dootpehr]

Firefox is updated to v95.0. Behaves correctly. Looks safe.

Comment 11

[dootpehr]

[Tracking Requested - why for this release]:

I don't know what is right status for this bug now. I set it to "unaffected" for v96. If it was in fact intentionally fixed then, please, edit the status.