The Edit/Preferences/Navigator/Bookmarks/Show Extended Data is basically non-functional because checking and unchecking the selection box has _no_ effect. The extended data(e.g., a ftp site as a 'folder') is _always_ shown if the bookmark is in the 'PersonalToolbar', the 'Sidebar', or in the 'Bookmarks Manager'. It is _not_ shown in the Bookmarks drop down list. Nice feature, btw. Would be even better if I could turn it off.;) This is in today's Linux build 2001031611 but existed in the 0313 and 0314 builds also; dunno about previous to that but don't think moz-0.8 had this pb. Have A Nice Day! Ric

ben/claudius, is this a dup...?

Still in today's Linux build:2001031821. About the dup: Is there a special trick to getting the bugzilla search engine to work? 99.9% of the time, for me, it returns "Zarro bugs found" even if the search parameters are the same words as another bug that has already been posted. Quite irritating... I have tried it in various ways amd none seem to work. Ric

not a dupe that I'm aware of. I can confirm this bug with 2001032304 builds. the pref is having no effect whatsoever. By my reading of the pref panel language it should only effect the toplevel menu and the manage bookmarks window. I should note that the extended view is not in effect for the toplevel menu but it is everywhere else (regardless of the pref setting). sairuh, at this moment I'd say that this is a prefs issue. There's nothing wrong with the feature - it's been there for many months. The only issue is whether the pref is being written, respected, etc. Ric, often you get the zarro bugs message when you know you shouldn't because you either selected or unselected a field on the query page inadvertantly. I would double-check that your query is broad enough in the state and resolution fields. Start with a broad query that gets too many matches and then work on modifying it.

actually, selecting/deselecting this checkbox does work for me [2001.03.29.08 comm bits]. what i think the problem might be is that the description is reversed (or, rather the checkbox behavior is reversed ;). actual results: -------------- selected: extended data is *not* shown as folders. deselected: extended data *is* shown as folders. expected: the opposite. ben, not sure if you have an existing bug on this already, but am gonna add the Usual Keywords to see if you can get this fixed soon. :)

just a note. With the 2001032904 build on Win98 with a new profile i get extended views in the bookmarks window but NOT in the menu(the toplevel menu, not the link on the personal toolbar) by default even though the pref window claims this is turned off. Checking it 'on' has no discernable effect on the previous behavior, nor does checking it back 'off'. Ben, the language of the pref makes no mention of the personal toolbar, what's supposed to happen? Shouldn't it be included with the rest? Currently I can't turn off extended views on the ptoolbar.

Why are so many people saying that this is a nice feature (ftp dirs in sidebar), while at the same time menioning that it would be nice to be able to turn it off? It's because the feature is totally useless in its current form! All you can do is navigate ALL the way down to the bottom of an ftp tree inside the narrow sidebar - woohoo. This feature should be turned OFF by default until someone fugures out how to display *any* subtree in the main window.

Well, for one thing, at the bottom of that narrow FTP tree is mozilla-i686-pc-linux-gnu-installer.tar.gz or other new file that is needed or wanted almost daily. All I have to do, when moz is running, is nav to that single item from my personal toolbar and dld it. In short, it's faster. Turning it off in the bookmarks/manager is important, imo, only because some people do not want it/will never use it and would prefer to actually go to the site and display the page info in the browser. For myself, I cannot understand why the info would be ever be displayed in the bookmarks manager. I must agree that if it was only in the sidebar, it would not interest me as much but having that function in the personal toolbar for frequently used FTP sites really _is_ woo!hoo! , at least in Linux. It is also a feature that is unique to Mozilla...

Also see bug 70269. I think that the best place to handle this pref is probably in nsDirectoryViewer.cpp - I have some local cleanup patches in my tree (bug 70529) which should make it easy to just plug this check into nsDirectoryViewer::isWellKnownContainerUri. Thats the datasource which is enumerated, anyway. That way all the places which care about it can just add in the rdf:httpindex datasource, and not have to worry about the pref, but still let the dirviewer work. (I keep track of whether we have been loaded via an httpindex converter, or whether someone is just querying for RDF attributes) That suggestion doesn't handle rdf:files though, and would turn it off in the sidebar as well. I didn't get a response to my query in bug 70269 - is my suggestion of releasing the mouse while over the actual directory name (in the bookmarks) a reasonable one, assuming that it can be done? IIRC this is what the mac does (from the apple menu). It wouldn't work for the directories on the personal toolbar though. Where is this code currently enabled? Theres some stuff in bookmarksOverlay.js, but its commented out. The biggest problem with it is that mozilla appears to lock up when you mouseover a large directory listing in the bookmark menu/personal toolbar - try mousing over /dev/ from a file:/// bookmark listing (you can do the same for large ftp directories. This really has to be fixed before this feature is any use.

interesting. now that the Bookmarks preference panel is gone, there's no front-end to access this pref. in any case [for reference], the back-end pref is "browser.bookmarks.show_extended_data" --however, it looks like this might be broken [recently?].

btw, i was trying to test that with existing [non-newish] profiles.

Items that were in the Bookmarks panel will be back soon in a new merged panel, `Bookmarks and History'

nav pretriage: I added nsbeta1+ to this a while ago, but forgot to schedule it. I propose mozilla0.9.2 as the tm.

nav triage team: Marking mozilla0.9.2. No matter what, we need to fix this (even if it means turning off the feature).

nav triage team: Not highly used feature, marking p3 and mozilla0.9.3, and it's still currently broken. Will probably disable it when we get around to it.

Pushing out to 1.0.

Resummarizing.

[RFE] is deprecated in favor of severity: enhancement. They have the same meaning.

(Filter "spam" on 'prefs-nobody-20080612'.)

UI does not exist on trunk or any version of SeaMonkey.

It would be more appropriate to mark as FIXED as it was 'fixed' with newer versions. It was _never_ invalid. Wow, OVER NINE YEARS LATER definitely qualifies in 'better late than never' category. So old it did not even show in the reported list(had completely forgotten about it ...).