Open Bug 464309 Opened 13 years ago Updated 9 years ago
Message headers don't scroll with the message
+++ 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....
Assignee: nobody → dmose
Flags: blocking-thunderbird3.0b1+ → blocking-thunderbird3+
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.
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.
Whiteboard: [status unclear; needs help from layout folks; reduced non-tb test case would be very helpful]
Whiteboard: [status unclear; needs help from layout folks; reduced non-tb test case would be very helpful] → [status unclear; needs updated patch from dmose; needs help from layout folks; reduced non-tb test case would be very helpful]
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!
Whiteboard: [status unclear; needs updated patch from dmose; needs help from layout folks; reduced non-tb test case would be very helpful] → [needs reduced non-tb testcase for lossage; needs help from layout folks]
Target Milestone: Thunderbird 3.0b1 → Thunderbird 3.0b2
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-. :-(
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.
davida informs me that I did indeed misunderstand him.
does this also encompass a hint for subject which can be scrolled? clearing missed milestone
Whiteboard: [needs reduced non-tb testcase for lossage; needs help from layout folks] → [patchlove][has draft patch][needs reduced non-tb testcase for lossage; needs help from layout folks]
Target Milestone: Thunderbird 3.0b2 → ---
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.
(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.
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
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.
(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.
(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.
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 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
Attachment #348845 - Attachment is obsolete: true
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.
I suggest attaching annotated screenshots when describing UI problems, it can help get the point across, when words sometimes are hard to parse quickly.
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.
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]
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.
Whiteboard: [patchlove][has draft patch][needs reduced non-tb testcase for lossage; needs help from layout folks] → [needs help from layout folks]
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
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/
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.
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.
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.
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.
Component: Mail Window Front End → Message Reader UI
QA Contact: front-end → message-reader
You need to log in before you can comment on or make changes to this bug.