User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.10pre) Gecko/20100416 Ubuntu/9.10 (karmic) Firefox/3.5.9 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.10pre) Gecko/20100416 Shredder/3.0.5pre I know there's been extensive discussion of how column preferences are set. This is different. If I I search for a term and then select a result or select "view as list" I get a threaded message list, with or without a preview pane. It is really frustrating that I can't see, in this view, what location a folder is in and I can't set a default column set that will include Location. Reproducible: Always Steps to Reproduce: 1. Search all messages for some phrase 2. Select "View as List" Actual Results: No location shown Expected Results: Location column should be visible.

Absolutely. Global search results are pointless without showing the location. This will have a similar potential for user annoyance as related Bug 505035 (Cannot change the column list of all folders at once), as soon as more people start using faceted search and discover the goodness of plain vanilla "open as list" mode, compared to the glaring non-versatility of faceted search results (we have some bugs for that, and getsatisfaction feedback, too). Same/similar requests have already been made in other bugs/comments, e.g. Bug 374551 - Location column visibility is not persisted in saved searches Bug 77940 - [SM] Search UI: Location column doesn't preserve shown/hidden state Bug 528044 - "Show as list" faceted search results does not remember columns (should persist column visiblity, e.g. for "location") Lots of initial comments of bug 528044 also want location column to be displayed by default. And bug 528044, comment 5 says many people on getsatisfaction want this as well. This bug would be an easy workaround fix for the most frequent use case of bug 528044.

Oh, I forgot the poor state of affairs due to Bug 522768 - Search Results: Missing full path in "Location" column (Faceted Search: Open as List, Saved Searches, Search Messages; Main 3-pane Window) Which means that showing current "Location" column will only show the folder name, but no account or path information. Arguably, this may not always be enough to know where the message is. On the other hand, it's better than nothing, and not everybody has multiple accounts. Those who do, will certainly need both, current "location" column (=folder) AND "account" column (as we don't offer the full path yet, due to bug 522768). Possible solutions for this bug: a) show current "location" column (=folder without path) by default ("some location information is better than nothing, but showing account column, too, would be too much") a+) If we could have a tooltip showing the full path when hovering over current location (=folder) column, that might also solve much of the problem. b) show current "location" column AND "account" column by default (to mimic full path to containing folder as good as we can, with bug 522768) c) do not add any default columns until some better solution for bug 522768 is implemented so that we can actually show a full path to the message Opinions?

I've merged all or most of http://gsfn.us/t/1b193 http://gsfn.us/t/1b19i http://gsfn.us/t/132nb http://gsfn.us/t/1b19i http://gsfn.us/t/126j6 into http://gsfn.us/t/1b193

1. Default columns for Search results should be distinct from default columns in other contexts. 2. Search results columns should initially default to include location information (including Account). 3. It should be possible to change the default columns for Search results.

Wayne, did you tag all of the above-mentioned GS reports with "Bug 570787"? After that, can you please normalize the URL to point to the tag and declare a canonical GS report? Thank you!

(In reply to Thomas D. from comment #7) > Wayne, did you tag all of the above-mentioned GS reports with "Bug 570787"? > After that, can you please normalize the URL to point to the tag and declare > a canonical GS report? Thank you! https://getsatisfaction.com/mozilla_messaging/topics/search_results_should_allow_visibilty_of_folder_location_of_match should be considered to be canonical

Which Search does this use? And where is this "Show as list" option?

(In reply to :aceman from comment #9) > Which Search does this use? And where is this "Show as list" option? Hi aceman! My translation engine translated this as "Aceman TB papercuts terminator would be willing to deal with this bug, if only he know what this is about..." Most welcome! tia... Simple: Gloda global search ("Search... <Ctrl+K>"), then on top of first results tab, below the heading "Search foo", there's a button "Open as list" which takes you to another tab with search results listed treeview-style in threaded conversation. So this bug requests to show "Location" column by default, in addition to "Subject | From | Date" default columns which we have now.

Good translation:) I'll see what I can do. Thanks for the explanation, I have found the "button" now. Really invisible ;)

(In reply to :aceman from comment #11) > I have found the "button" now. Really invisible that is bug 545949. perhaps a good papercut candidate odd - at some point "Open as list" must have changed to "Open email as list", because all the bug reports cite the button as "Open as list"

(In reply to Wayne Mery (:wsmwk) from comment #12) > odd - at some point "Open as list" must have changed to "Open email as > list", because all the bug reports cite the button as "Open as list" Yes I noticed that too. There is no "open as list" string in TB17. I hope the "Open email as list" is the same (I can't currently start my TB17).

(In reply to :aceman from comment #13) > (In reply to Wayne Mery (:wsmwk) from comment #12) > > odd - at some point "Open as list" must have changed to "Open email as > > list", because all the bug reports cite the button as "Open as list" > Yes I noticed that too. There is no "open as list" string in TB17. I hope > the "Open email as list" is the same (I can't currently start my TB17). omg, the caption of that button is getting worse with each change (and we've had plenty). In TB's UI, to *open* email means to view messages in their own tab. Does this button really *open* email? On my mental map, this is more like *view* search results as list (perhaps coming from Windows Explorer's "Views" where you toggle between icons, list mode etc.). Of course, it's a view that *opens* in a new tab, and we even *open* first message for preview, but that's details which don't belong into the button caption, and to mingle those notions imho just adds to the confusion. Can we find a better caption for this button? Perhaps: 1) "View search results as list", or 2) "View results as list" ?

Yeah, that would make sense.

The string was changed in bug 743235 but I do not understand why. But it does not make sense in our case.

So this adds the Account and Location columns. For the record, I had to rebuild my gloda database otherwise I got an error in Error console. But maybe it is unrelated, I may have had an old version because I had it disabled for a long time.

Comment on attachment 646895 [details] [diff] [review] patch Stealing review. note to Blake: I think the original set of default values was chosen here because adding account and location cramped up the columns on more narrow screens and we thought we'd get around to the persistence...

(In reply to :aceman from comment #16) > The string was changed in bug 743235 but I do not understand why. But it > does not make sense in our case. The string was changed because global search results can now contain instant message results as well as e-mail results. However, only e-mail results can be displayed in the thread pane as a list. (Instant messages are displayed in their own UI and cannot show up in the thread pane.)

Would the change proposals from comment 14 be accepted?

(In reply to Andrew Sutherland (:asuth) from comment #19) > (In reply to :aceman from comment #16) > > The string was changed in bug 743235 but I do not understand why. But it > > does not make sense in our case. > > The string was changed because global search results can now contain instant > message results as well as e-mail results. However, only e-mail results can > be displayed in the thread pane as a list. (Instant messages are displayed > in their own UI and cannot show up in the thread pane.) Oh, I see. That explains the rationality of the change. I still find "Open email as list" not very fortunate as a caption, e.g. because "email" can also be singular, and because "open" is the wrong command notion. TB and other apps like windows Explorer all have their options for threaded views, list-style etc. in "View" menu, and "Views" is a common term, well, for different "Views" of a result set. New proposal: 3) - make the button caption short and simple: [View as list] - add details to tooltip: "View email results as list" If you want more details in the button caption (to be more correct), well then, I suppose we need to have: 4) [View email as list] (where email is used as a collective noun) +tooltip: "View email results as list" 5) Would [View emails as list] be grammatical? Whichever way, this certainly needs a *localization note* explaining the caption, because translating into other languages won't be easy unless they can just borrow the short English terms.

Comment on attachment 646895 [details] [diff] [review] patch Yeah, showing both the account and location does seem a little cluttered, particularly when coming from the "Open in Conversation" mode, where the messages are _really_ likely to be in the same account. I think I could live with auto-hiding the account column when all the messages have the same account, if you feel up for coding that. (Or only showing it when we get a message in a different account, if that's easier to code.) Thanks, Blake.

(In reply to Blake Winton (:bwinton - Thunderbird UX) from comment #22) > I think I could live with auto-hiding the account column when all the > messages have the same account, if you feel up for coding that. (Or only > showing it when we get a message in a different account, if that's easier to > code.) If you decide to go with this, it's possible to use the gloda faceting implementation to do the work for you. I don't think you can reuse the existing facets for the UI because of the possibility of instant messaging clouding the 'account' issue, but gloda/modules/facet.js could be told to compute the actual set. This could also be done internally as part of gloda/modules/dbview.js. Separate thought: I agree that "open email as list" is somewhat awkward, but that's Blake's department :)

No, I have no idea how to do this. Feel free to continue on the patch.

On the dropdown in the message header, we've got "Open in Conversation", "Open in New Window", and "Open in New Tab". How do people feel about "Open email results in list"? It's sort of a shame that the list tab doesn't replace the gloda tab, or "Switch to List View" would work. Hmm, what about "Open List View"? Later, Blake.

what about showing both views next to each other in the same tab? i think half of the people want to see the list view all the time anyway

That also feels too cluttered to me. If someone wants to come up with a way to switch back to the gloda view from the list view, then I'ld be happy to advocate for just showing the last view that the user selected. That way, the people who want one view or the other can always just use that, and the people who want to switch can also do that.

sounds fine

I meant this sounds fine: "showing the last view that the user selected" -------- This is related: bug 813877 - drag and drop emails from search results into another folder

I am not working on this.

This bug is really annoying when you have a lot of different accounts and folders. Please someone solve this issue!

Fixed by bug 528044.

Great, thanks.

Awesome, fantastic, wunderbar! Thanks to everyone who contributed to getting this shipped. I've updated the gsfn topic.

In which version this is fixed? in Thunderbird 32 it is not: Still reproduceable: 1. search globally and click "open mail at list" 2. You can change the shown columns; there I selected "location" and size" 3. close that list with CTRL+W 4. search again globally and open as list 5. the columns "location" and "size" are still there 6. close thunderbird 7. start again, search globally and open as list 8. The columns are gone! This should be fixed too, otherwise you still always have to change the column setting each time you restart thunderbird! Please reopen this ticket, or state in which FF version it is fixed

Same result as Ruben. I have never seen this working.

Per whiteboard location was added by bug 528044. Per Target Milestone field in version 29. I've just tested nightly build and location is always there. Other columns persist for me, on multiple searches, until Thunderbird is shut down. Columns added do not appear after thunderbird restart and from bug 528044 comments it seems this was not a goal. I've filed bug 1028632.

I am talking about the columns in the list view of a global search. In all other views the columns are remembered correctly. Just not there.

Strange, now it works correctly in TB 31 on Linux. I cannot reproduce, why it didn't work earlyer today. Maybe that was a buggy TB 32 installation on Windows

Maybe I mixed it up with the installation of 24.0.6 Can't you merge this fix into the next minor release of the 24 branch? that would help so much in the daily work

(In reply to Ruben from comment #41) > Can't you merge this fix into the next minor release of the 24 branch? > that would help so much in the daily work There's no point. By the time the next version of the 24 branch would be out, 31 will be released anyway. You can always just run the beta for now.

(In reply to Jim Porter (:squib) from comment #42) > There's no point. By the time the next version of the 24 branch would be > out, 31 will be released anyway. I think many users will not be able to upgrade to 31 soon. They could be dependant for example on: - plug-ins which will not work in the new version - distribution repositories which could stay with the 24 branch - extensive testing before deploying 31 If I understand it correctly, the main releases (like 24 or 31) now have a similar properties as ESR (Extended Support Releases).

(In reply to Václav Brožík from comment #43) > If I understand it correctly, the main releases (like 24 or 31) now have a > similar properties as ESR (Extended Support Releases). They do, but support for 24 ends when 31 is released, just like with Firefox ESR. Unless something changes (e.g. an emergency security fix), there are no more scheduled releases of TB 24.

(In reply to Thomas D. from comment #21) > (In reply to Andrew Sutherland (:asuth) from comment #19) > > (In reply to :aceman from comment #16) > New proposal: > 3) - make the button caption short and simple: [View as list] > - add details to tooltip: "View email results as list" > > If you want more details in the button caption (to be more correct), well > then, I suppose we need to have: > 4) [View email as list] (where email is used as a collective noun) > +tooltip: "View email results as list" > > 5) Would [View emails as list] be grammatical? > > Whichever way, this certainly needs a *localization note* explaining the > caption, because translating into other languages won't be easy unless they > can just borrow the short English terms. First, I agree with your comments, view is much less misleading. I was wary at first of trying the button when labeled "open". In fact, Chrome has almost the same language regarding bookmarks, and it does indeed open every single bookmark if one opens a folder of bookmarks. Inconvenient if you thought you were about to see a folder view of a list of bookmarks. Very convenient if opening a zillion bookmarks is the goal. Email i would not consider the plural. One would not say "two email" Rather it has two meanings, like phone. I can contact you by email or phone - the method, or i could have two phones - the thing. (not "two phone") Plural of the thing which is an email message would be emails. And while experts whiz paste the language once they know what it does, using clear language in the human interface makes it much easier for new people to adopt it as their email program. Thanks to all who cared enough to comment.

(In reply to Jim Porter (:squib) from comment #44) > (In reply to Václav Brožík from comment #43) > > If I understand it correctly, the main releases (like 24 or 31) now have a > > similar properties as ESR (Extended Support Releases). > > They do, but support for 24 ends when 31 is released, just like with Firefox > ESR. Unless something changes (e.g. an emergency security fix), there are no > more scheduled releases of TB 24. Actually, I think there are one or two minor releases of 24 after 31 releases - at least it used to, not sure if it's decided for this release yet. That doesn't change anything for this bug though, 24 would only get absolutely critical security fixes.

I would say "view search result as list"

Since this bug report mentions the Open email as list, it is relevant to ask to make this link easy to select by a keyboard key or key combination. While mouse users don't need this, blind and visually impaired people who must use the keyboard do need this. It is also helpful for users who want to construct a keyboard macro to force searching output to be in "list mode", where it is usually easier to make use of.

This bug mentions version 29. The current version is 52, so I am confused as to whether my comment got implemented three years ago or not. I also do not understand Wayne Mery's comment of 10 hours ago--is the original bug now fixed or what? I'm not familiar with TB/Bugzilla conventions.

This is not fixed. Wayne only mentioned a related bug that is fixed: you can now open the result as list and there you can activate the folder display where each email is stored in. @David: your request for a keyboard shortcut doesn't fit here, this would be another issue and i guess such a request already exists. For Info: there is an add-on, that sets the list view as default for more than X emails in the result.

(Sorry I stuck my oar in three years ago; I'm actually pretty happy with TB as it is. I use keyboard macros when I need workarounds for bugs, particularly the weird format of results of "Quick Filter" searches. Thanks to everyone who fixes bugs: they are much appreciated!)