Closed Bug 1301917 Opened 4 years ago Closed 4 years ago
Firefox hangs briefly when bookmarks are edited
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:49.0) Gecko/20100101 Firefox/49.0 Build ID: 20160907153016 Steps to reproduce: Create a new bookmark for a page by pressing Ctrl-D. Hit backspace a few times and type to edit the bookmark text. After editing for a few seconds, Firefox hangs and becomes unresponsive for several seconds (5-10 seconds). After closing the bookmark editing popup, a few moments later the freeze happens again for about the same duration. Actual results: As described above; I was able to reproduce this phenomenon on several versions of Firefox and tried a few things (e.g. Places Maintenance) to alleviate it. My personal places file is quite large (21 MB). Here's what I found so far. -Firefox 47: Does not have the bug. -Firefox 50 Developer Edition: Does not have the bug. -Firefox 48 and 49 beta: DO have the bug. I tried experiments with these versions to see what might help. My results were: -Running places maintenance: No improvement. -Trying to run Firefox with add-ons disabled: No improvement. -Removing places.sqlite* files and starting over with no bookmarks: SOLVES the problem. (But then my bookmarks are gone.) -Using a bookmarks.html backup to let Firefox 48/49 to regenerate the places file with my bookmarks: EXHIBITS the problem again. -Creating a new Firefox profile and regenerating the places from a bookmark backup: EXHIBITS the problem again. Expected results: My conclusion is that something was introduced in version 48 that caused issues with editing the bookmarks. Version 47 and earlier, and the Developer Edition 50, do not have the problem, as far as I can tell, but version 48 and 49 (non-developer) do have the issue. Also, it does not seem to be caused by add-ons.
(In reply to echuber2 from comment #0) > My personal places file is quite large (21 MB). That's not large, mine is about 70MB. It shouldn't be a problem. Do you have Sync enabled? Is multi-process enabled? Does disabling these temporarily help? It would be great if you, or someone else who can reproduce the slowdown, could find an actual regression range using http://mozilla.github.io/mozregression/. That would point out the actual changeset that caused the slowdown. Just by looking at the list of changes that made 48, I don't see any change that could have caused this in Bookmarks code.
Marco, do you think it's reproducible if the reporter share his places file?
The bookmarks.html file could be enough according to comment 0, but I couldn't reproduced hangs in this dialog, so I can't tell off-hand. Eventually I'm available to receive a copy of it through private mail.
I did not have multiprocess enabled. I was preparing to try mozregression, however, it seems that something with sync may have been the issue. This seems to have resolved the problem: -Deactivated Sync. -Closed Firefox. -Removed places* and all bookmark backup directories from profile. -Put a bookmarks.html backup in the profile directory. -Restarted Firefox and allowed it to regenerate places. -Reset my Sync account (fresh password, old content deleted from server) -Synced and tested; problem seems fixed in 48 release. Thank you for your help. If it happens again in the future I'll try mozregression and see if I can narrow down the regression range. As it stands I can no longer reproduce the issue.
ni Mark just as a heads up.
If you visit about:sync-log, you might find some error logs from around the time you were having problems. If so, would you be able to upload them?
Flags: needinfo?(markh) → needinfo?(echuber2)
The problem has been back for a while and I've been able to run mozregression. First a few notes: -The problem seems to have gotten worse with newer versions of Firefox, as recreating the places file from bookmark backups or creating a new Sync account no longer relieve the problem. It returns almost immediately. -I can reproduce the problem on Linux and Windows. -Reproducing the problem intentionally does not produce a sync error log. I ran mozregression on Windows with good 47, bad 50, and this was the final result: 25:28.38 INFO: Narrowed inbound regression window from [63f11876, b2c38c67] (3 r evisions) to [63f11876, 6a623b9d] (2 revisions) (~1 steps left) 25:28.38 INFO: Oh noes, no (more) inbound revisions :( 25:28.38 INFO: Last good revision: 63f11876b0b8ed6f49c697e5072da6eaeddbf2e0 25:28.38 INFO: First bad revision: 6a623b9d45990722da19fc864c7ef820821bd4b0 25:28.38 INFO: Pushlog: https://hg.mozilla.org/integration/fx-team/pushloghtml?fromchange=63f11876b0b8ed6f49c697e5072da6eaeddbf2e0&tochange=6a623b9d45990722da19fc864c7ef820821bd4b0
Status: RESOLVED → UNCONFIRMED
Flags: needinfo?(echuber2) → needinfo?(markh)
Resolution: WORKSFORME → ---
We've fixed a similar sounding problem in Firefox 51 (bug 1303831) - please let us know if the problem persists after you get the 51 upgrade.
The Firefox 51 beta seems to have fixed the problem, from what I can tell. I'm using 51.0b14 now with no issue.
(In reply to echuber2 from comment #9) > The Firefox 51 beta seems to have fixed the problem, from what I can tell. > I'm using 51.0b14 now with no issue. Awesome, thanks for testing and getting back to us!
Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago → 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1303831
I'm still running 51.0b14 but the issue seems to be creeping back again gradually. I'm hoping it isn't, but just in case, the culprit might still be lurking somewhere in the regression window above.
You need to log in before you can comment on or make changes to this bug.