Moz has a feature where file/network directories added as bookmarks are opening, and dynamically add content from the network. This works in the bookmark manager, and if you add, say, ftp://ftp.netscape.com/ to the personal toolbar it works there too (ie the BM looks like a folder on the toolbar), but doesn't work from the bookmarks menu. The comment in bug 36224 hints that this used to work. Note that actually selecting files from this interface won't work - my gopher patches include a fix for that, but it should still be possible to follow the directories. You also need to have the trailing / on the directory.

http://bonsai.mozilla.org/cvslog.cgi?file=mozilla/xpfe/browser/resources/content/navigatorOverlay.xul has: 1.68 rjc%netscape.com Apr 16 2000 Aggregate in "rdf:httpindex". 1.75 waterson%netscape.com Apr 26 2000 Remove rdf:httpindex datasource from menus. r=rjc I can't find a bug on this - what was the reason for the removal? Adding this back doesn't seem to have any problems (in a quick test)

Because: 1. It makes the Mac explode when you have menus that get nested as deeply as your filesystem structure allows it to be. 2. When do you fetch the submenus? If you wait until the person mouses over the cascade, then you might time-out waiting for the FTP server at the other end to respond. If you do it ``up front'' before the menu is dropped, you create a ton of network traffic and probably make the main menu come up a lot slower. 3. It's generally sort of tacky UI.

1. file urls still expand (rdf:file is still present in the overlay file), so if this is a problem, then that should probably be removed as well. 2a. Does this mean that the fact that ftp:// directories expand from the personal toolbar (and the bookmarks folder button from that toolbar) is a bug? And therefore bug 36224 is invalid as well? Assuming that having it there doesn't affect the mac, then I don't think so - its a useful feature. 2b. rdf:internetsearch is still present (on both the personal toolbar and the the bookmarks menu), and that presumably causes a network connection as well. 3. The UI isn't that bad. Its not that good, but I think that its a nice feature, and no-one has complained about it yet. Of course, you can't select subfolders of large folders because they're laid out in wierd parts of the screen (not connected to other parts of the menu), but that happens with "normal" bookmarks as well. It may have something to do with my window manager.

I was gonna rubber-stamp 'verified' but I'm not as sure now. I understand this would be hella slow but is that the only reason? Why are we consistent with the way this feature is implemented. Re:#1 I thought that the Mac menus would somehow be a liability but the MacOS has no problem digging deep into the file system as every Mac i've ever owned has had my whole hard drive loaded into the apple menu w/o a problem.

maybe we need to get a draft set of tests and run them on each build for a while. there is still time to decide...

not quite done.

This is the diff to fix the bookmarks panel: - datasources="rdf:bookmarks rdf:files rdf:httpindex rdf:localsearch rdf:internetsearch" + datasources="rdf:bookmarks rdf:files rdf:localsearch rdf:internetsearch" (I'm also using this as an excuse to cvs remove bookmarksPanel.xul, which holds the other occurrence of rdf:httpindex, and this file is unused).

r=bbaetz

Paul Chen is now taking Bookmarks bugs. For your convenience, you can filter email notifications caused by this by searching for 'ilikegoats'.

sr=blake

Current behavior is not a defect, marking invalid

mass-verifying Invalid bugs which haven't changed since 2001-12-31. use the search string "PinballWizard" if you want to filter out this msg.