489038 - Selecting and/or deleting tags in the Library causes Firefox 3.5b4pre to hog the CPU and become unresponsive

Status: RESOLVED WORKSFORME

(Firefox :: Bookmarks & History, defect, P2)

Description

[Brian Carpenter [:geeknik]]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4pre) Gecko/20090418 Shiretoko/3.5b4pre Firefox/3.0.8
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4pre) Gecko/20090418 Shiretoko/3.5b4pre Firefox/3.0.8

I went to History -> Show All History and then expanded the tags section and went to select a tag so that I could delete orphaned tags and Firefox became unresponsive and I looked in Task Manager and Firefox was using 100% of the CPU. I tested this in safe mode and got the same results.


Reproducible: Always

Steps to Reproduce:
1. History -> Show All History
2. Expand Tags Section in the Library
3. Select A Tag
Actual Results:  
Firefox hogs the CPU and becomes unresponsive.


Expected Results:  
Firefox should not hog the CPU or become unresponsive.


XP SP3, 3ghz Core2Quad Q9450, 4GB DDR. Places.sqlite is 70MB.

Comment 1

[Brian Carpenter [:geeknik]]

I have noticed that if you click on the word tags in the left hand panel and don't expand it, you can click on the tags in the right top panel with none of the performance problems you get if you expand the tags in the left hand panel.

Comment 2

[Brian Carpenter [:geeknik]]

I had thought this was limited to orphaned tags, but there is a performance issue even with tags that are associated with a bookmark.

Comment 3

[Susie Day]

I've just had the same problem - in addition to getting a non-responsive script error (each time i tried it with a different script and line number):

A script on this page may be busy, or it may have stopped responding. You can stop the script now, or you can continue to see if the script will complete.

Script: file:///C:/Program%20Files/Mozilla%20Firefox%203.1%20Beta%203/components/nsTaggingService.js:70

===

Script: file:///C:/Program%20Files/Mozilla%20Firefox%203.1%20Beta%203/components/nsTaggingService.js:220

==

Script: chrome://browser/content/places/editBookmarkOverlay.js:1030

===

I only get this error if I first try to delete a large number of tags (I tried 200), and then it appears even when I try and delete one tag.  If I then shut the Library, and re-open it, I can delete tags again without a problem.

It does delete some of the tags, even though it gives the error, and I think if I left it alone it would delete them all.

Comment 4

[Dietrich Ayala (:dietrich)]

Confirmed on Mac: Open the Library, double click on a tag with a few items, no immediate response, beachball appears, eventually tagged URLs are visible.

P2 because it's not primary UI. This should block the 3.5 release.

Comment 5

[Dietrich Ayala (:dietrich)]

(In reply to comment #1)
> I have noticed that if you click on the word tags in the left hand panel and
> don't expand it, you can click on the tags in the right top panel with none of
> the performance problems you get if you expand the tags in the left hand panel.

I was able to reproduce the problem either way.

Comment 6

[Marco Bonardo [:mak]]

Mh this bug is confusing.
Comment 1 talks about selecting a tag in the left pane, does this involve other steps like delete or anything?
comment 3 talks about removing a large number of tags, and looks completely unrelated to comment 1, looks more like "remove large number of bookmarks" bug.
comment 4 is about double clicking a tag in the right pane in a big profile (right?)

what's this bug about?

Comment 7

[Marco Bonardo [:mak]]

And i can't reproduce comment 1 issue with provided steps with either small or big profile. How big is your places.sqlite? Do you have any particular add-on or toolbar?

Comment 8

[Marco Bonardo [:mak]]

I can't reproduce comment 4 either, in a debug build with your profile it takes about a seconds to open the tag here, but always open it. With an optimized build it takes less than a second (but more than "immediate").

Comment 9

[Dietrich Ayala (:dietrich)]

doing a bunch of investigation related to this in bug 490664.

Comment 10

[Dietrich Ayala (:dietrich)]

narrowed it down, and the tag delay is almost entirely in sql land.

Comment 11

[Marco Bonardo [:mak]]

i have found a bunch of sql queries caused by treeView.js::isContainer, calling into hasChildren (for a query node). those are fast queries, but are a lot.
The above patch gives a sense of more snappiness, and is the way to go, but adding with some sql cleanup so that we execute far less queries.

Comment 12

[Tracy Walker [:tracy]]

I can't reproduce this with a new profile nor an old crufty one.

Comment 13

[Dietrich Ayala (:dietrich)]

fwiw, i found a bunch of optimizations in this code path, while trying to resolve this:

bug 490664 (reviews in progress)
bug 492794 (needs review marco)
bug 492796 (needs review marco)
bug 492797 (wip patch)
bug 492799 (fixed trunk)
bug 492802 (fixed trunk)
bug 492804 (fixed trunk)
bug 492805
bug 493636 (needs review marco)

i still think there's a core query issue, but i can't reproduce every time. sometimes it beachballs, sometimes it doesn't. maybe swapping to disk...

Comment 14

[Mike Beltzner [:beltzner, not reading bugmail]]

I don't think this blocks, and a lot of those fixes look safe enough to take on a stability branch. Let's keep this in queue for that sort of work, but take it out of the critical path for 3.5

Comment 15

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Dietrich, is qawanted still valid? I tried to reproduce the problem but wasn't lucky too.

Comment 17

[Peter Gerdes]

To answer question asked in Bug 497055 it is slow regardless of whether it is selected via the left pane or double click in right pane.

Comment 18

[Nathan J. Yoder]

My laptop's specs:
Windows SP XP 2
P4 2.2Ghz
512 MB ram
Firefox 3.5.1

I can confirm having this same problem, even with a completely new profile with no added extensions (bookmarks were imported via json).  When clicking on a tag in the left hand pane in the bookmark organizer window, Firefox hangs for quite some time while it loads.  Curiously, if I use sqlite manager to create manual queries to find tagged bookmarks, it is quite fast.

After talking to mak on IRC, it seems that having a large number of bookmarks tagged by Stumble Upon ("SU" tag) without the user's knowledge, is the culprit.  Personally, I have only tagged a few dozen bookmarks in total, with about 10 tags total.  However, with Stumble Upon discreetly tagging everything, it has created this slowness problem.

Using Firefox 3.6 alpha 1 solves this problem and tags load at a good speed.

Comment 19

[Marco Bonardo [:mak]]

I'm thinking if we should add a preventive maintenance task to get rid of badly tagged things (pages that are tagged but are not actually bookmarks).

The above comment is a confirm that the Tsnappiness work done above is working good, i have a JSON backup from Nathan's profile, and i guess i can generate a public one with random data, seeing what is inside this one. That could tell us more also about which fix had the most effect on the issue.

Comment 20

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Is this really a regression or happened all the time along since we have switched to sqlite? Even until I cannot reproduce I cannot even check for a window.

Comment 21

[(mostly gone) XtC4UaLL [:xtc4uall]]

Is this still an Issue for anyone on Trunk?
Can the regressionwindow-wanted KW be removed?

Comment 22

[Brian Carpenter [:geeknik]]

I'm not sure this is an issue any more. I am not able to reproduce this on the latest nightly build.

Comment 23

[Marco Bonardo [:mak]]

I think Firefox 4 should have made this less than a problem, if there is still some issue caused by add-ons like StumbleUpon, I'd like to have a separate report filed for considering a maintenance task.
Reopen if you can reproduce slow tags deletion in Firefox 4 and that is not caused by add-ons, please.