Lag in initiating the Add bookmark folder dialog in Library when there are too many bookmarks in the same folder is now much more prominent
Categories
(Firefox :: Bookmarks & History, defect)
Tracking
()
People
(Reporter: aoia7rz7l, Unassigned)
References
(Regression)
Details
(Keywords: regression)
Prerequisite:
Approximately >10,000 bookmarks/folders in Other Bookmarks. This was just barely noticeable with >500 bookmarks in the same folder when I tried to reproduce the issue inside a VM, but this might be easier to spot on a lower-end machine.
STR:
- Open the Library.
- Navigate to the Other Bookmarks folder that has >10,000 bookmarks.
- Click on
Organize > Add Folderat the top left of of the Library window (This also happens withAdd Bookmarkalthough it's not as obvious). - Notice the way the Add bookmark (folder) dialog is initializing before the
New Bookmark/Folderentry appears in the Library window.
Expected Behavior:
Users should not be able to perceive the lag in initiating the Add bookmark (folder) dialog.
Actual Behavior:
User can clearly perceive the lag in initiating the Add bookmark (folder) dialog when there are too many bookmarks in the same folder, because the dialog shows multiple fields when initiating. This also means that the Add bookmark folder dialog is no longer centered relative to the Library window once it is initialized.
Mozregression returned
Last good revision: b276c24696ee9bd643a90dd3470c4798b696be18
First bad revision: f59c8eb211e42eec668f14d0b99074992580e092
Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=b276c24696ee9bd643a90dd3470c4798b696be18&tochange=f59c8eb211e42eec668f14d0b99074992580e092
FWIW the lag also seemed to be present in ESR 102 so I don't think that's the main issue here. IMO this is probably related to the new flexbox layout, similar to how bug 1795901 made the Name input field in the Add bookmark folder dialog unnecessarily long.
|
||
Comment 1•2 years ago
|
||
Setting Regressed by field after analyzing regression range found by mozregression in comment #0.
|
|
||
Comment 2•2 years ago
|
||
:jsudiaman, since you are the author of the regressor, bug 1786322, could you take a look? Also, could you set the severity field?
For more information, please visit auto_nag documentation.
|
||
Comment 3•2 years ago
|
||
(In reply to aoia7rz7l from comment #0)
FWIW the lag also seemed to be present in ESR 102 so I don't think that's the main issue here. IMO this is probably related to the new flexbox layout, similar to how bug 1795901 made the
Nameinput field in the Add bookmark folder dialog unnecessarily long.
Sorry to ask, but I'm trying to understand this better. If the lag was also present in 102, how can it be regressed by bug 1786322? Or re you saying the cause is different?
Could you please take a profile (as shown on https://profiler.firefox.com/) that includes the issue, so we can check where time is being spent.
Could you please also tell how much is that lag, are we speaking about a few seconds, many seconds, minutes?
Apart from that, I wonder if bug 1812083 may have helped here, though it will only be available to test in Firefox 112 (setting browser.bookmarks.editDialog.delayedApply.enabled to true in about:config) or in Firefox 113 (current Nightly). If you have a chance to test one of those versions it may be useful.
(In reply to Marco Bonardo [:mak] from comment #3)
Sorry to ask, but I'm trying to understand this better. If the lag was also present in 102, how can it be regressed by bug 1786322? Or re you saying the cause is different?
Could you please also tell how much is that lag, are we speaking about a few seconds, many seconds, minutes?
The amount of lag (in seconds) in 102 and 109 were identical. For example, with only 4 bookmarks (the default Mozilla Firefox folder) the dialog loaded instantaneously. With ~500 bookmarks it took maybe around 0.1 seconds to initiate. And with >10,000 bookmarks it's around 1.0-1.5 seconds. This lag is much more visually perceivable because the dialog now shows multiple fields when initiating, and I ran mozregression based on this visual difference.
Apart from that, I wonder if bug 1812083 may have helped here, though it will only be available to test in Firefox 112 (setting
browser.bookmarks.editDialog.delayedApply.enabledto true in about:config) or in Firefox 113 (current Nightly). If you have a chance to test one of those versions it may be useful.
I can confirm that the issue is not reproducible once I flipped browser.bookmarks.editDialog.delayedApply.enabled to true.
|
|
||
Comment 5•2 years ago
|
||
(In reply to aoia7rz7l from comment #4)
The amount of lag (in seconds) in 102 and 109 were identical. For example, with only 4 bookmarks (the default
Mozilla Firefoxfolder) the dialog loaded instantaneously. With ~500 bookmarks it took maybe around 0.1 seconds to initiate. And with >10,000 bookmarks it's around 1.0-1.5 seconds. This lag is much more visually perceivable because the dialog now shows multiple fields when initiating, and I ran mozregression based on this visual difference.
Ah I see, it's probably something related to bug 1753920, I added a comment there covering the visual flicker.
(In reply to aoia7rz7l from comment #4)
I can confirm that the issue is not reproducible once I flipped
browser.bookmarks.editDialog.delayedApply.enabledto true.
That's good, it will be the default in Firefox 113+
Description
•