464309 - Message headers don't scroll with the message

Status: NEW

(Thunderbird :: Message Reader UI, enhancement)

Description

[Dan Mosedale (:dmosedale, :dmose)]

+++ This bug was initially created as a clone of Bug #9942 +++

The message header frame above the message frame is bigger than it needs to be
to show the headers; resizing the mail window or dragging up on the sash between
the thread pane and the msg pane resizes the header frame bigger as well as
resizing the message pane, resulting in a lot of empty space below the headers
which could be used for showing more of the message.

--

After talking with roc, we're not going to get the layout changes for the iframe bug that the original was depending on for 1.9.1.  Current theory is that we'll be able to fix this in the front-end code using CSS and JS.  XUL layout is not really reacting to getting the height set manually the way we'd hoped, though, so we'll see....

Comment 1

[Ben Bucksch (:BenB)]

Why was this bug cloned?

> Current theory is that we'll be able to fix this in the front-end code
> using CSS and JS.  XUL layout is not really reacting to getting the
> height set manually the way we'd hoped, though,

Do you mean what I tried in bug 9942? (see patches there)
Please see bug 9942 comment 93, bug 9942 comment 102 and 103, and bug 9942 comment 109.

Comment 2

[Dan Mosedale (:dmosedale, :dmose)]

I cloned because that bug was filed for SeaMonkey only.  I'm using a very similar (though not exactly identical) approach.  I'll get a patch up soon.

Comment 3

[Dan Mosedale (:dmosedale, :dmose)]

Attachment: WIP patch, v1

This still needs some cleanup, and it doesn't quite work right, either.  I have a couple of other bugs that I need to get through first, so if anyone feels like taking a swing at this before I get a chance to, please feel free!

Comment 4

[Dan Mosedale (:dmosedale, :dmose)]

While this would continue to be a fine thing to get, discussion with clarkbw a few weeks back suggests that we could live without it for tb3; setting blocking-.  :-(

Comment 5

[Dan Mosedale (:dmosedale, :dmose)]

From IRC yesterday:

<davida> the attachment pane code can actually (as I did in my patch) be tweaked to work as intended, where it takes a variable amount of space up to some % of the window, and then scrolls.
<davida> i started poking around a patch to do that, but haven't gotten much of anywhere yet

I believe he was referring to bug 436555, and the implication I took away from the discussion was that he thought that strategy might work here too.  It's possible that I misunderstood him; need to investigate further.

Comment 6

[Dan Mosedale (:dmosedale, :dmose)]

davida informs me that I did indeed misunderstand him.

Comment 8

[Wayne Mery (:wsmwk)]

does this also encompass a hint for subject which can be scrolled?

clearing missed milestone

Comment 10

[Ben Bucksch (:BenB)]

Can we convince roc to get the autosize iframe layout changes (bug 80713) in sometime now (they were originally promised for 1.9.1, see initial comment)? I don't think we'll get a satisfactory solution without them. I tried real hard, with various workarounds, in bug 9942, and nothing worked properly without other considerable regressions.

Comment 11

[Saul Tannenbaum]

(In reply to comment #9)
> *** Bug 501366 has been marked as a duplicate of this bug. ***

I don't believe that the bug I reported is a duplicate of this bug.

This bug is focused on vertical scrolling of the entire header area.

The bug I"m reporting is about horizontal scrolling of single header lines.
What I'm seeing is that those header lines appear truncated. But, if you
click and drag near the end of the line, it scrolls.

This isn't about autosizing of iframes, but of the end result should the frame
be too small horizontally. Thunderbird does the right thing, but there's no visual indication of what it's doing.

Anything I can do to clarify this, please let me know.

Comment 12

[Wayne Mery (:wsmwk)]

is bug 325144 a dupe?


(In reply to comment #11)
> (In reply to comment #9)
> > *** Bug 501366 has been marked as a duplicate of this bug. ***
> 
> I don't believe that the bug I reported is a duplicate of this bug.
> 
> This bug is focused on vertical scrolling of the entire header area.
> 
> The bug I"m reporting is about horizontal scrolling of single header lines.
> What I'm seeing is that those header lines appear truncated. But, if you
> click and drag near the end of the line, it scrolls.

I read your bug a couple times, and my take away was you were talking about scrolling the entire header.  I agree there should be a hint that the subject can be scrolled, and I wasn't able to find a duplicate. Feel free to reopen your bug and improve the summary.  and cc :clarkbw

Comment 13

[Ronald Killmer]

Bug 325144 is not a dup of the horizontal scroll case.  

There was an old bug which I could not track down to my satisfaction. My recollection is the comments had a workaround of using the arrow keys to scroll a header such as the x-trace or Posting-host. There are some bugs about wrapping headers, but not sure they fit this case.

Comment 14

[rsx11m]

(In reply to comment #13)
> Bug 325144 is not a dup of the horizontal scroll case.  

Where do you think they are different? Seems to be exactly addressing the same issue described here, maybe less specific.

Also, I'd recommend to revisit the discussion in bug 449691, which introduced the action buttons in the Thunderbird header pane. If scrolling the headers
with the message becomes a default and non-configurable behavior, access to the action buttons is lost when scrolling down the message. Complementary toolbar buttons would no longer be present by default once bug 474523 lands.

Comment 15

[Dan Mosedale (:dmosedale, :dmose)]

(In reply to comment #10)
> Can we convince roc to get the autosize iframe layout changes (bug 80713) in
> sometime now (they were originally promised for 1.9.1, see initial comment)? I
> don't think we'll get a satisfactory solution without them. I tried real hard,
> with various workarounds, in bug 9942, and nothing worked properly without
> other considerable regressions.

I talked to beltzner about this recently, from what I understood, there's no way that those changes would be accepted anywhere other trunk, and even there not until after 1.9.2 branches.

Comment 17

[Mats Lindhé]

I'm not sure that bug 486107 is really a duplicate of this one, but if so I can add some further info about the problem.
If you have a huge mail header it will spill over downwards (into the status line area) and get truncated sideways - long lines continuing "out the window". With no scroll bars in either direction.

Comment 18

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Comment on attachment 348845 [details] [diff] [review]
WIP patch, v1

Patch has bitrotted:

$ patch -p1 --dry-run < ~/Desktop/scrolling-headers 
patching file mail/base/content/contentAreaClick.js
Hunk #1 succeeded at 75 (offset 1 line).
Hunk #2 succeeded at 149 (offset 1 line).
patching file mail/base/content/mailWindowOverlay.js
Hunk #1 FAILED at 2399.
Hunk #2 FAILED at 2665.
2 out of 2 hunks FAILED -- saving rejects to file mail/base/content/mailWindowOverlay.js.rej
patching file mail/base/content/messenger.xul
Hunk #1 FAILED at 419.
1 out of 1 hunk FAILED -- saving rejects to file mail/base/content/messenger.xul.rej
patching file mail/base/content/msgMail3PaneWindow.js
Hunk #1 FAILED at 801.
1 out of 1 hunk FAILED -- saving rejects to file mail/base/content/msgMail3PaneWindow.js.rej
patching file mail/themes/pinstripe/mail/mailWindow1.css
Hunk #1 FAILED at 374.
1 out of 1 hunk FAILED -- saving rejects to file mail/themes/pinstripe/mail/mailWindow1.css.rej

Comment 20

[David E. Ross]

From the initial description of this bug, this is NOT a duplicate of bug 325144.  

Here, the problem is that the frame for the headers is sized incorrectly.  This bug report also appears to refer to the upper-right pane in the three-pane "wide" view.  

Bug 325144 involves the complete header of a single message.  This is a problem whether the message is viewed in the bottom pane in the three-pane "wide" view or in a separate window.  If the complete header is viewed -- selecting the +- widget to the far left of the Subject with [View > Headers > All] -- the header might require more lines than can be displayed within the window.  There is no vertical scroll bar to view the entire set of header lines or to reach the message below the header.  On the other hand, selecting the +- widget again reduces the header to a single line with exactly the right amount of vertical space.  

I must also question closing a bug report that is more than three years old in favor of a newer report that is less than a year old.  This obscures the true age of the underlying problem.

Comment 21

[David Ascher (:davida)]

I suggest attaching annotated screenshots when describing UI problems, it can help get the point across, when words sometimes are hard to parse quickly.

Comment 22

[rsx11m]

Looking at attachment 171616 [details] of bug 9942, from which this bug was derived,
I still think that's exactly what the bug here is discussing for Thunderbird.
Thus, I'm puzzled what the difference between bug 9942, bug 325144, and this bug actually is. Some clarification might be helpful, it appeared to me that the iframe issue was only one component of the overall aim here.

Comment 23

[Peter Lairo]

Attachment: Screenshot showing buttons in header

What happens to this bug now that bug 474523 was imposed? (see screen-shot)

https://bugzilla.mozilla.org/show_bug.cgi?id=474523
remove reply, reply all, forward, delete, junk, and forward/back buttons from default mail toolbar [and put them in the header pane]

Comment 25

[Brandon Stout]

This bug should be more than an enhancement.  If the subject line of an email is really long (which happens if you buy some 50 things at once on ebay from one seller and they send you an invoice - for one example), the entire email becomes unreadable because the whole message window is covered with headers.  There's the workaround to view all headers, but even with that, this is more than just an enhancement.

Comment 26

[A. Klitzing]

by the way... claws-mail and balsa do it that way. Also, you can configure the header lines to be displayed in claws-mail (see Bug #456830).

Balsa: http://balsa.gnome.org/screens/2.2/balsa-main-window.png
Claws-Mail: http://www.claws-mail.org/img/screenshots/main.png

Comment 27

[A. Klitzing]

Evolution scrolls, too: http://projects.gnome.org/evolution/images/screenshots/2.4/read-mail.png

The extension Mnenhy can display header lines "inline" as requested here. But it looks a little bit cluttered. This could be the beginning...
http://mnenhy.mozdev.org/

Comment 28

[rsx11m]

All of the examples given in the previous comments have the action buttons for a message in the main toolbar. Thus, comment #23 still applies - combining a moving header pane with the buttons in it won't work.

Comment 29

[A. Klitzing]

Well, why not leave the action buttons in the tiling pane? Claws-Mail has some buttons for mail searching in it, too. So thunderbird could use it for the action buttons but move the headers to mail view.
Maybe it could be an option or editable by an addon.

Personally I don't like the action buttons in that bar.

Comment 30

[Ben Bucksch (:BenB)]

Guys, there is no need to discuss or argue for this. We'd like to do it, but we
we're waiting for a blocking bug in Gecko, see dependencies.
Please also avoid the urge to make layman suggestions how to implement it anyway. We just need bug 80713. You may vote for that bug (and this one), though.

Comment 31

[rsx11m]

I'm not arguing for it, rather against it.  ;-)

The header-pane layout of Thunderbird 3.x doesn't quite resemble Netscape 4.x any more, hence some more thought would have to be put into a possible design than just waiting for the iframe stuff to become available.