448456 - Missing treelines in newsgroup threading

Status: RESOLVED WORKSFORME

(Thunderbird :: Mail Window Front End, defect)

Description

[Joe Sabash [:JoeS1]]

Since the switch to comm-central, treelines are missing in the threaded newsgroup view and also in the folder pane. (toolkit switch ?)
This loss is most apparent in trying to follow deeply nested threads.

Attached images show threading with and without treelines, for the benefit of the mac user (who never had treelines), and those that don't view deeply threaded newsgroups.

Certainly wanted tb3, and request blocking tb3 as this is a major asset for a newsreader.

Comment 1

[Joe Sabash [:JoeS1]]

Attachment: with lines

Comment 2

[Joe Sabash [:JoeS1]]

Attachment: no lines

Comment 3

[Richard Marti (:Paenglab)]

Yes without the treelines it's very hard to follow theads with a lot of subthreads.
Also using the DOMI without the treelines is really hard.

Comment 4

[David Ascher (:davida)]

This feels shallow and worth doing.

Comment 5

[David :Bienvenu]

Maybe Phil knows what's going on.

Comment 6

[Phil Ringnalda (:philor)]

Yeah, though I wish I didn't. We survived bug 425131 because it only altered tree.css, and Qute packages its own tree.css, but with the switch to comm-central we picked up Karsten's fix for bug 430852 which hides them in xul.css for trees that don't have a treelines="true" attribute, which of course is every tree. So now we need to kill Qute's tree.css, and scatter treelines="true" around and about.

Comment 7

[Karsten Düsterloh]

> we picked up Karsten's fix for bug 430852 which hides them in
> xul.css for trees that don't have a treelines="true" attribute,

I really wish I hadn't had to do that, but there was no other way toolkit owners allowed. :-(

> which of course is every tree.

Yeah, almost. We sometimes use flat trees as non-evil listboxes. I think.

> So now we need to kill Qute's tree.css, and scatter treelines="true" around
> and about.

/mailnews has about 22 trees to look at, so /mail should be in that area, too.
(I have to triage well over 130 trees for SeaMonkey, including DOMI and Venkman, which kind of explains why not much happened on this for the last weeks. :( )

I still think that treeline drop from toolkit (and the attitude/way of doing it)  hurts the Mozilla platform...

Comment 8

[Ronald Killmer]

(In reply to comment #1)
> Created an attachment (id=331674) [details]
> with lines
> 

Note that for news the treelines are very disjointed. These look like Mail treelines where the New Message sunburst icon forms a node in the treeline.  News does not have that icon node. News could use treeline graphics with extended lines that can join for visual continuity.

Comment 9

[Joe Sabash [:JoeS1]]

Before this bug popped up, I really didn't know how they were generated.
They are produced by the OS
In Winxp you must "Uncheck" FolderOptions->View->Display simple folder view in Explorer's folder list.
So, if they look poor, it's because the OS doesn't do a particularly good job.
But at least they are there.

Comment 10

[Karsten Düsterloh]

As a sidenote, since I can't decide for TB which trees to fix (although I'm gonna fix the ones under /mailnews, which includes addressbook, in bug 438793): 
  grep -ir "[<:]tree[ /]" *
in comm-central finds about 180 trees (including mozilla-central, calendar, inspector and DOMI). The results for /mail are:

mail/base/content/ABSearchDialog.xul:        <tree id="abResultsTree" flex="1" enableColumnDrag="true" class="plain"
mail/base/content/SearchDialog.xul:        <tree id="threadTree" persist="lastfoldersent" flex="1" enableColumnDrag="true" _selectDelay="500" class="plain focusring" lastfoldersent="false"
mail/base/content/messenger.xul:      <tree id="folderTree" class="plain focusring" flex="1"
mail/base/content/messenger.xul:            <tree id="threadTree" persist="lastfoldersent width" flex="2" enableColumnDrag="true" _selectDelay="500" class="plain focusring" lastfoldersent="false"
mail/base/content/msgSelectOffline.xul:  <tree id="synchronizeTree" flex="1" hidecolumnpicker="true"
mail/base/content/subscribe.xul:                    <tree id="subscribeTree"
mail/base/content/subscribe.xul:                    <tree id="searchTree" flex="1" 
mail/components/addrbook/content/abContactsPanel.xul:    <tree id="abResultsTree" flex="1" context="cardProperties" class="plain" sortCol="GeneratedName" persist="sortCol" ondblclick="contactsListDoubleClick(event);">
mail/components/addrbook/content/addressbook.xul:      <tree id="dirTree" class="abDirectory plain" seltype="single" minwidth="150" flex="1" persist="width"
mail/components/addrbook/content/addressbook.xul:      <tree id="abResultsTree" flex="1" enableColumnDrag="true" class="plain"
mail/components/preferences/downloadactions.xul:    <tree id="fileHandlersList" flex="1"
mail/components/preferences/viewpasswords.xul:            <tree id="signonsTree" flex="1" style="height: 20em;" hidecolumnpicker="true"
mail/components/preferences/viewpasswords.xul:            <tree id="rejectsTree" flex="1" style="height: 10em;" hidecolumnpicker="true"
mail/extensions/newsblog/content/feed-subscriptions.xul:    <tree id="rssSubscriptionsList" flex="1" style="height: 10em;"

Comment 11

[Bryan Clark (DevTools PM) [:clarkbw]]

Is there a way we can honor the operating system choice?  (the simple view as mentioned in bug 425131 comment 5)

Comment 12

[Karsten Düsterloh]

(In reply to comment #11)
> Is there a way we can honor the operating system choice?

No, because there is *NO* operating system choice, and that's in fact the real problem. Mac, for example, doesn't know about treelines at all - but we can draw them even there...
Please read the whole discussion in bug 430852, so that we don't need to reiterate the whole shebang here.

> (the simple view as mentioned in bug 425131 comment 5)

That's just "shell" stuff on Windows, no OS setting. See bug 430852.

Comment 13

[Bryan Clark (DevTools PM) [:clarkbw]]

Ok, I've read over the other bugs now and I can't see this as blocking.  I can see that DOMi and Venkman need treelines as the exact parent child relationship is much more important, but in mail or even in news this isn't true.  

When a person doesn't address or quote another person's message in a reply then the reply-to context doesn't carry much significance at all other than what message they were focused on when they hit reply.  The large increase in whitespace is an information design problem that needs to be addressed and treelines don't actually address the problem.

I don't want to rehash that whole thread but I don't agree with it's conclusion.  I could see this change happening if certain treelines were turned on and there was an option in about:config to enable the visibility of those lines.  I'm open to discussion other possible similar options as well.

Comment 14

[Joe Sabash [:JoeS1]]

(In reply to comment #13)
> Ok, I've read over the other bugs now and I can't see this as blocking.  I can
> see that DOMi and Venkman need treelines as the exact parent child relationship
> is much more important, but in mail or even in news this isn't true.  
> 
> When a person doesn't address or quote another person's message in a reply then
> the reply-to context doesn't carry much significance at all other than what
> message they were focused on when they hit reply.

Certainly it's vital to see the exact parent/child relationship for DOMi and Venkman, but I would argue that for newsgroups threads, the "who responded to whom" is nearly as important, or at least, very helpful. If you read a lot of newsgroups, rarely is it necessary to read the entire thread to understand the point of the post.

For example, in https://bugzilla.mozilla.org/attachment.cgi?id=331675 I might value ovidiu's opinion highly, but  there is no easy way to see if he was replying to the original post, or a sub-thread without the lines.

I think many people rely on the lines for this visual cue. 
More and more (hopefully) long time gecko users should be trying TB as we move from alpha to beta. They will certainly notice the absence of this feature.

Even though not blocking b1 we should certainly make every effort to have treelines included there.

As far as the whitespace goes without the lines, it's not a pretty display that I want, but a functional one.

   

Comment 15

[Joshua Cranmer [:jcranmer]]

(In reply to comment #13)
> Ok, I've read over the other bugs now and I can't see this as blocking.  I can
> see that DOMi and Venkman need treelines as the exact parent child relationship
> is much more important, but in mail or even in news this isn't true.

There are times in some forums where I have threads that are so deep that the subjects "walk off" the pane. Many forums (especially something like talk.origins) generate very deep threads, to the degree that I would argue that some way to show the hierarchy even in the extreme cases is necessary.

> When a person doesn't address or quote another person's message in a reply then
> the reply-to context doesn't carry much significance at all other than what
> message they were focused on when they hit reply.

Reiterating what JoeS said, to a degree, I view about 200-ish newsgroup messages a day in several forums. I don't have the time to read all of those messages, so what I do is I scan for interesting posts, often involving a lot of `n' or <space> keypresses. If I see poster A responding to poster B responding to poster A, when neither responds to the other, I'm intrigued before I read the thread. If I see a deep posting in a thread I've largely ignored, I'm intrigued.

I think heavy newsgroup users would disagree with your opinion about the importance of tree lines.

Comment 16

[Ronald Killmer]

I was astonished wile reading Comment #7 there are 170 trees I was not aware off.  So it must be that many places do without treelines. I will sacrifice those of the folder pane to keep thread pane threading.  Those are important enough that if they are dropped, a Bounty would likely be easy to raise for there reinstatement by extension. Yes, the lines are "Classic", yet there value as a visual connection in conversation is highly useful. 

Comment 17

[Joe Sabash [:JoeS1]]

Just as in the case of "scrolling headers" a very simple fix is available in userChrome.css

 *Restore treelines
 */
treechildren::-moz-tree-line {
  visibility: visible !important;
}

Unfortunately, the casual user would have no idea of this fix.

Comment 18

[Tuukka Tolvanen (sp3000)]

fwiw I don't really miss treelines, what with bug 349212...

Comment 19

[Wayne Mery (:wsmwk)]

I don't see this.
Is it still failing for you?

Comment 20

[Ronald Killmer]

Did some testing and learned that the Workaround presented in comment #17 is not needed for the thread pane to show treelines with news group discussions. 

The Folder Pane however, still needs the userChrome workaround if treelines are wanted.

I therefor suggest we close this bug since the feature regression for news did not appear to exist any longer.

Comment 21

[Joshua Cranmer [:jcranmer]]

RESOLVED WFM per comment 20.