67358 - ftp:// bookmarks start FTP urls

Status: RESOLVED FIXED

(SeaMonkey :: Sidebar, defect)

Description

[(not reading, please use [e-mail] instead)]

nbaca has a profile that causes 100% cpu usage.

bienvenu has tracked it down to an ftp url in bookmarks.

this profile has the sidebar visible, with the bookmarks sidebar open.

we run the ftp url, to see if it has children.  since ftp has 100% cpu bugs,
this causes mail to appear to use 100% of the CPU.

it appears we are running the url to determine the children (or if the url has
children).  ftp uris are well known to be a container.

ideally, we would only run the ftp url when we selected the bookmark.

I'll attach the stack trace that bienvenu got that will help you track it down.

Comment 1

[(not reading, please use [e-mail] instead)]

Attachment: stack trace, thanks to bienvenu

Comment 2

[Alec Flett]

fixing summary/keywords

I'm still a bit confused - you mean that the bookmark is NOT open, but ftp still
fires? or is it trying to open it up because localstore.rdf is persisting its
"openness"

Comment 3

[David :Bienvenu]

No, I don't think the ftp bookmark was open; we think that ftp urls are
automatically run because they're "wellKnown" as containers, so the url is run
to see if it has children. If you poke around in the stack trace, you can see it
happening. I set a breakpoint on the newURI method for the ftp protocol, and
then brought up a window with a sidebar and the bookmarks sidebar open.

Comment 4

[Alec Flett]

yeah, talked with seth. it's not that they are 'well known', it's just that
every element in the tree is asked "do you have children?" and in the case of
ftp, it needs to run a URL to know that for sure. 

I thought what I need to do was make sure that nsHTTPIndex::GetTarget() does not
kick off a url, but judging by the stack trace, we are in fact calling
GetTargets() which is bad - it maybe that something broken is going on in the
template builder.

given that:
- this is probably a difficult problem to fix
- has probably existed for months
- has only been exposed recently by ftp taking up 100% CPU
- the 100% cpu problem has to be fixed anyway

I'm pushing this one out. it would be nice if we didn't try to make an ftp
connection, but there are biggeer issues.

Comment 5

[Doug Turner (:dougt)]

part of this problem will be solved by 65220, but we should still avoid trying
to open ftp connections if we don;t have to.

Comment 6

[Paul Chen]

nav triage team:

As dougt points out, 65220 is fixed, so this is less of an issue, though it 
should be fixed eventually. Marking future.

Comment 7

[Paul Chen]

nav triage team:

Forgot to add nsbeta1-

Comment 8

[Arun Prasannan (polar)]

This bug is being marked EXPIRED as it has seen no activity in a very long time.

If you think that the issue reported might still be relevant, please test with a recent release of SeaMonkey and if the problem persists feel free to re-open the report. Thank you.

http://www.seamonkey-project.org/

Comment 9

[Mark Banner (:standard8)]

Bulk reopening incorrectly expired bugs - no activity does not constitute no bug - these need proper checking.

Comment 10

[Philip Chee]

Fixed by the fix in Bug 65220