First of all, to whoever implemented this feature, it rocks! I think it's really cool. If you have an ftp url in your bookmarks menu and you select that url, we actually bring up more submenus to match the directory structure for the ftp url. But I have one big usability problem...I can't actually click on my bookmark url (or one of the children that get generated) unless that url is a leaf node without any sub menus. We need to add the notion of a "this" entry to each submenu layer so you can specify that you want to actually load the url even if it isn't a leaf menu item. For instance, if I have a ftp url bookmarked for sweetlou/products/client/seamonkey, the menu should look like: sweet lou url --> this --> windows --> this --> April 18 --> mac --> linux Without a "this" type slection, there is no way to click on an ftp url for my bookmarked url or one of the top level children like windows, mac, linux. You get the submenu popup instead. In mail, we have the same problem for folders and we use a this type entry to allow you to select the current folder instead of one of the children.

over to don, his group is responsible for xul/app interaction.

Reassigning as per Don

Move to M20 target milestone.

Oops. Should be M21.

Having this feature brings out at least one bug. See bug 39579. I still think it should be a feature that you could turn on/off on the bookmarks property.

*** Bug 42118 has been marked as a duplicate of this bug. ***

Reassigning to someone who has some involvement with Mozilla.

Netscape Nav triage team: this is not a Netscape beta stopper. adding helpwanted to the keywords

I noticed this, but fixing it is ugly, because the RDF datasource which generates this is the same one that generates the directory viewer stuff. You can't call it "this" because then it gets confusing when there is a file called this, and sorting means that it wouldn't always be at the top anyway. I suppose whatever code actually builds the menu could somehow check if the datasource was rdf:httpindex, and then add the this element to the top somehow. I haven't a clue how to do this though. Note that this doesn't work from the bookmarks menu for some reason, only from manage bookmarks, although I do see this problem from the personal toolbar. A couple of bookmarks/directory interaction problems are fixed in my gopher patches.

How about if the ftp directory acted the same way a mail folder does: - when clicking the dir "name", it displays the dir content in the main window. - when clicking the dir "triangle", it shows the subdirs in the sidebar (but not the main view). - when doubleclicking the dir "mane" it does both (open the subdirs in sidebar AND in main view). This would be consistent with the apps' other behaviour :)

Though this feature might score highly on the coolness scale, I think the best thing to do UI-wise is to get rid of it. Firstly, for the Bookmarks window to show contents which are not the same as those available in the Bookmarks menu is highly non-intuitive. Secondly, the multi-second lag involved in retrieving the child directory listing (which, if there's a network problem, might *never* arrive) -- in order to open the sublist -- could cause extreme discomfort to those who expect twisty contents to expand without fail within a much shorter timeframe. Obviously these problems don't apply to mscott, who (a) has a very fast Internet connection and (b) is highly experienced at using unintuitive UIs; but I rather think he's in the minority. Today's UI lesson: If some text needs to be repeated over and over in a UI, the wrong control is probably being used somewhere. Example 1: The constant repetition of `Server' and `Copies and Folders' in the Account Manager is a symptom of using tree items where something like tabs should be used instead. Example 2: The constant repetition of `this' (or similar) in the Bookmarks window for FTP directories would be a symptom of using the Bookmarks window to display subdirectories when the browser window should be used instead.

mpt: The bookmarks menu was removed (partly) for that reason 10 days after it was added (8 days after this bug was filed). Also see bug 70269. Adding "this" everywhere is ugly, but what about if clicking (the menu)/doubleclicking (the manager) the directory folder itsself opened up that directory in the browser window (maybe only from the bookmarks manager)? I think I see a nice way to do this - instead of OpenBookmarkURL returning false if its a container, return false if there's not a url attached. That fact is exposed (as an RDF attribute) as a side effect of my gopher stuff (49334). I need to get up at 5am tomorrow though, so I'm not going to look at it til I get back next weekend. Would that solve the UI issues? The network connection arguments don't hold for file:// uris.

Marking nsbeta1- bugs as future to get off the radar

Actually, the best solution is to remove this feature from the bookmarks. When people bookmark a location, they will likely want to go to *that* location again. Therefore, an ftp bookmark should just go to *that dir* when clicked (i.e. behave just like any other BM). As an alternative, someone could create a mySidebar panel for ftp sites that allows navigatio of dirs. Then we could think of a convention that makes sense within that panel but doesn't have to conform with bookmark conventions. Not being able to use bookmarked ftp sites has lasted long ewnough - I sure hope this gets fixed soon ;)

suggest to add keyword: *nsCatFood* since this is a very user visible bug (i can't add it)

I love the 'extended data views' feature. We've all accepted that it's pretty sweet|cool|etc. So let's not go and throw the baby out with the bath water. We just need to tweak it a little. BenG has already taken one step and made this a pref enabled feature (yes yet another pref), it's not quite working right but that is already written up. The original purpose of this bug was just to give us the ability to load an arbitrary sub/directory into the browser. If you want to talk about removing this feature altogether, go do that in another bug or a newsgroup and cite this bug if you wish. This bug is about correcting a somewhat broken aspect of this feature, namely that with this feature on you can no longer load the url you actually bookmarked. Ben, you might wanna look at reeling in the 'future' target milestone, cuz this is gonna tick a lot of people off in the meantime. I'm adding the nscatfood label b/c this drive me nuts and makes me want to turn it off.

tweaking the summary to catch dupes. The bug where turning this feature on/off isn't working properly is bug 72311

*** Bug 75256 has been marked as a duplicate of this bug. ***

Easy fix. Just requires removal of rdf:httpindex from the datasources attributes of the bookmarks UI elements.

nav triage: since the percentage of general users bookmarking ftp urls is very low, nota catFood stopper. However this is dogfood+ as it impacts developers and qa of mozilla negatively on a daily basis.

I remember the issue causing the pref not to work correctly was a template builder issue. I've turned off the feature (sorry Claudius) but want to enable it again as soon as I get time to check to see if waterson's recent tinkering with template builder etc has fixed the issue. If not, the issue may also not manifest itself with outliner, so an outliner conversion may allow the pref to be enabled once more.

I'm sure I fixed this recently. Correct me if I'm wrong. Should open a new bug on the fact that the extended view for ftp is no longer available, and address the template builder issues.

This still does not work from the sidebar on build 2001-05-27 - I'll file a new bug on this :(

OK, i filed bug 82987 to fix the sidebar FTP issue.

I saw this fixed in the sense that you could right click the link and choose open to load it into the content window. I know that's not ideal (maybe the left vs. right click action could be reversed?) but none of that matters anyway as this discussion is currently moot b/c the feature has been disabled - so I'm marking VERIFIED Fixed.