40609 - Import/Load bookmarks should be asynchronous

Status: RESOLVED INVALID

(SeaMonkey :: Bookmarks & History, enhancement, P3)

Description

[Timothy McClanahan]

I just managed to lock up the whole browser (had two windows open) by opening
'manage bookmarks' and importing a really large bookmarks file. Okay, so this
might not be ready for primetime - but it certainly shouldn't be possible to
lock up the browser by something the Manage Bookmarks does - right? Definitely
should be launched in a separate thread or process. This smells like Nav 4.x
technology - crash one thing, it takes everything else with it. :(

Might also want to look at other sections of the browser that perhaps need the
same treatment. What about opening preferences? If that crashes, what happens to
the browser? Multiple browser windows - if one crashes, do they all die as they
do in Nav 4.x? Definitely worth a look at the structure of what's going on!!

Comment 1

[Jeremy M. Dolan]

I think a better idea would be to just fix all the crashes, though, your point
taken =) Marking enhancement. Marking confirmed, in that, crashing bookmark
manager does indeed take out the whole mozilla platform.

Comment 2

[Blake Ross]

Removing enhancement designation; I don't consider this an enhancement, it's 
really a fundamental issue that I think should be fixed.

Comment 3

[don]

Restored "enhancement" severity and moved to "Future".

Give me a break!

Comment 4

[Blake Ross]

I still don't consider this as an enhancement, which is usually a request for a 
feature or an improvement on a feature.  The fact that one window - especially 
a subwindow like the manage bookmarks one - will bring down the entire app is 
an oft-complained about problem in both NS 4.x AND IE 5.x.  However, IE has 
fixed this problem in IE 5.5 (crashes only bring down the window in which they 
occur), and I think we should at least consider it.

In any case, I'll leave it as an enhancement, but I'm doubtful.

Comment 5

[Timothy McClanahan]

If this type of structure to Mozilla is allowed to be released, then as far as 
I'm concerned, the entire Mozilla project may well be a failure. Sure, we'll 
just make sure it doesn't crash. Right. Just like 4.x? Gimme a break! I just had 
another lockup - but it was another browser window, not something as 'small' as 
a bookmarks window. One browser window locked up all of them! This is hardly an 
'enhancement' request. If this kind of 'thinking' continues in this project, 
then long live IE & Opera.

Comment 6

[Blake Ross]

[e-mail], you're more than welcome (invited, in fact!) to fix 
this yourself if you so desire.

Comment 7

[Jesse Ruderman]

Mozilla would probably be slower if each window got its own process :(  On the 
other hand, Mozilla, like most browsers, is easy to crash or hang if you try.  
A pref would be neat, or an option to "open this link in a new process".

Note that with bug 32112 fixed, running mozilla.exe a second time is not 
sufficient to get a new process.  I actually like that feature (although with 
bug 50424 it can be annoying).

Comment 8

[Blake Ross]

Reassigning 79 Bookmarks bugs to Ben.  I was told this was going to be done 
shortly about two months ago, but it clearly hasn't been.  I think that's long 
enough for all these bugs to remain assigned to nobody.

Feel free to filter all this spam into the trashcan by looking for this string 
in the message body: ducksgoquack

Comment 9

[Marcia Knous [:marcia]]

Netscape Nav triage team: this is not a Netscape beta stopper.

Comment 10

[Jesse Ruderman]

See also bug 16959.

Comment 11

[Fabian Guisset]

Reporter, could you please check whether this still happens? Maybe the new
bookmarks manager fixed it.
Thanks.

Comment 12

[Kelly Price]

It's still freezing on Linux Build 2001060713 (moz 9.1).  This time it's when
closing up a tree of bookmarks.  I may have to build my own Bookmark manager in
Perl/Tk to avoid the problems, but it's still freezing the browzer and taking
100% CPU for a 102K boomkark file.

It should be reclassified as major. Added myself to CC.  

Comment 13

[Kelly Price]

Attachment: 103K bookmarks file

Comment 14

[Ben Goodger (use ben at mozilla dot org for email)]

Nothing has changed about the back end code that synchronously parses the HTML
file. Everything else has to wait while it does so. Yes, this is still a problem ;)

Comment 15

[Ben Goodger (use ben at mozilla dot org for email)]

Resummarizing. The same code that loads the standard bookmarks file at startup 
also imports. Paul Chen said he was going to look at this...

Comment 16

[Kelly Price]

I really down that import/load is the only culprit.  When I pharse through my
bookmark file (glad I backed it up here), and try to move a few things around,
everything slows down and i get 100% CPU load while Mozilla sorts things out for
a half-minute or so.

Comment 17

[Jesse Ruderman]

I think this bug just turned into a dup of bug 63000...

Comment 18

[Peter Trudelle]

mass-reassign bookmarks & open pref perf bugs from pchen to ben

Comment 19

[Andrew Hagen]

I'm setting this bug to depend on bug 63000. The reason is that the symptoms
talked about in this bug of crashing and hanging are unique.

Comment 20

[Tom Metro]

I encountered a similar lockup when importing a 2.17MB Netscape 7 bookmark file
into Firebird/0.6.1. After letting it set at 100% CPU utilization for 5 minutes
or so, I eventually killed the process.

The problem didn't appear to be repeatable, as after restarting I was able to
import the file. It still pegged the CPU at 100%, but only for about 1 and a
half minutes.

It's possible this was a memory allocation problem. My Firebird process was
consuming about 120 MB of VM (on a Windows NT system with 384 MB physical/1 GB
VM) with about 25 top-level windows open (with some of those containing 5 or 10
tabs each). I noticed on the successful import that I could see the memory usage
ramp up over the 1 and a half minutes. (Unfortunately my memory usage graph had
scrolled beyond the point where the original crash occurred, so I can't compare.)


On a side note, I'd recommend changing the summary of this bug to reflect the
lockup on import bug, and let bug 63000 make the case for an asynchronous
thread/process solution. The two are only indirectly related. The import bug
needs to be fixed, whether it crashes the whole browser or just the bookmark
manager.

Comment 21

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 22

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 23

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 24

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 25

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 26

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 27

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 28

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420

Comment 29

[Karsten Düsterloh]

Bookmarks are now stored in an sqlite database, the old infrastructure is gone.
Issues with the new system should be filed as new bugs.