340327 - Long From/To push window content (incl. scrollbars) out of view (with "expanded" address list)

Status: RESOLVED WORKSFORME

(Thunderbird :: Mail Window Front End, defect)

Description

[Eyal Rozenberg]

Bug 247833 manifests in Thunderbird also, up to 1.5.0.4 and probably in trunk also.

Opening this bug as per the suggestion of Bug 247833, comment 28. Marking dependence, although the bugs are more 'related' than 'dependent' and 'blocking'.

Comment 1

[Tuukka Tolvanen (sp3000)]

*** Bug 322604 has been marked as a duplicate of this bug. ***

Comment 2

[Mike Cowperthwaite]

I do believe that Scott's fix for bug 335973 has squashed this bug.
Eyal, can you confirm?

Comment 3

[Eyal Rozenberg]

No, I can't confirom, thanks to this:

https://bugzilla.mozilla.org/show_bug.cgi?id=345695

Comment 4

[Eyal Rozenberg]

No, I can't confirom, thanks to this:

https://bugzilla.mozilla.org/show_bug.cgi?id=345695

Comment 5

[Tuukka Tolvanen (sp3000)]

bug 335973 has fixed this to the extent that the initial single line display doesn't mess up chrome. if the header value is long, and is expanded using the twisty, the expanded view is as bad as ever, both horizontally and vertically.

I have some work in progress to fix that part using scrolling for the expanded header value; unfortunately I don't seem to get an underflow event if the underflow was caused by css height increase, so I get a ~4 line tall header in expanded state even if the value takes, say, two lines :\

Comment 6

[Eyal Rozenberg]

(In reply to comment #5)
> so I get a ~4 line tall header in
> expanded state even if the value takes, say, two lines :\

Perhaps that's good enough to check into trunk, then another bug could be opened for the underflow issue (assuming you should be getting that underflow event).

Comment 7

[Mike Cowperthwaite]

(In reply to comment #4)
> No, I can't confirom, thanks to this:
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=345695

Um.  That bug is about Seamonkey crashing.  This bug (which you reported) is a Thunderbird bug; bug 247833 is the same problem under TM.


(In reply to comment #5)
> bug 335973 has fixed this to the extent that the initial single line display
> doesn't mess up chrome. if the header value is long, and is expanded using the
> twisty, the expanded view is as bad as ever, both horizontally and vertically.

It sounds like you're talking about the behavior of the text within the envelope panel. This bug is about the behavior of the message body itself, and whether its logical width is controlled by the width of the address text in the envelope.

I have several messages with various configurations of long names and multiple addressees, and using TB 3a1-0804, I can narrow the window quite a bit without the message-body content being truncated by the window edge. There is a 
minimum-width for the body (or the status bar?), but that's not related to the relative length of the address fields.


> I have some work in progress to fix that part using scrolling for the
> expanded header value; 

As in bug 240313?

Comment 8

[Tuukka Tolvanen (sp3000)]

The effect on the message body is just one symptom. Open the twisty on a field that has an address item wider than the message pane to see the remaining horizontal issue. No, I'm scrolling an individual header, not the whole #msgHeaderView as in bug 240313.

Comment 9

[Mike Cowperthwaite]

(In reply to comment #8)
> The effect on the message body is just one symptom.

The effect on the message body is this bug:
  Long From/To push window content (incl. scrollbars) out of view
                    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The attachment bucket also gets pushed out, in Seamonkey, but that's not a TB issue.


(In reply to comment #7)
> bug 247833 is the same problem under TM.

That should have read "under SM" (meaning Seamonkey).

Comment 10

[Tuukka Tolvanen (sp3000)]

Attachment: patch0.3: expanded always 5em, overflow-x hidden

This patch leaves overflow-x always hidden, making room for the horz scroller seems too much to pay for extreme cases (there's always source view). The idea was to go from "height: auto; overflow-y: hidden;" to "height: 5em; overflow-y: auto;" on expand, and then to "overflow-y: visible;" on underflow event, and hope the second resize doesn't look too jarring. The problem is, changing the overflow rule seems to reset overflow status to no overflow, so there's no underflow event in case of overflow going away, but there is an overflow event if overflow remains.

So this patch (with remaining theme changes, it only does mail/themes/qute) improves things such that huge expanded address lists don't break ui, but with the drawback that short expanded address lists have excess vert space.

Comment 11

[Tuukka Tolvanen (sp3000)]

Attachment: before/after screenshots, patch0.3

Comment 12

[Scott MacGregor]

not blocking, but will take a patch if tuukka  keeps hacking on this.

Comment 13

[Mike Cowperthwaite]

*** Bug 356064 has been marked as a duplicate of this bug. ***

Comment 14

[Eyal Rozenberg]

Comment on attachment 232439 [details] [diff] [review]
patch0.3: expanded always 5em, overflow-x hidden

(In reply to comment #12)

So what exactly needs to be done?

Comment 15

[Eyal Rozenberg]

Attachment: folder with a testcase message

TB trunk build from 2006-12-01 exhibits the bug with the attached testcase. I haven't been able to find a triggering message with 'from' entries which do not specify a chraset. If anyone has such a testcase please post it.

Comment 16

[Mike Cowperthwaite]

With TB 2b1, the only questionable symptom with that message is that the 
long address list is truncated in the envelope panel -- which is not what 
bug 247833 is about.  As reported there:

> If there're long recipient (TO, CC, BCC) addresses, they [...] push the
> attachments box out of the visible window area, [and] do the same to the
> other parts of the right half of the window, i.e. msg body, thread pane and
> throbber.

The "attachments box" part is not relevant to TB.  With the new testcase, in TB 2b1: I see the throbber in the menu bar; the columns in the thread pane continue to display at their expected widths and positions; if I narrow the window, the message text wraps at the window border rather than running past the edge of it.  None of these things is true in TB 1.5.

Take a look at your bug 247833 comment 25, which is what led you to open this bug.  If you edit your testcase to put a bunch of text into the message, can you reproduce *that* problem with TB 2b1?  I don't think you can.

Comment 17

[Eyal Rozenberg]

Attachment: screenshot with attachment 247201

This is what I see with the testcase message. From what Mike is saying... is it possible we are actually talking about two separate problems?

Comment 18

[Mike Cowperthwaite]

Thanks for clearing that up.  I see the problem now; I hadn't tried expanding the list.  The original symptom recurs when the list is expanded, even if there isn't a MIME-encoded header.  In fact, the expand/collapse button appears even with a single address, if the window is narrow enough to truncate that address; expanding the single address causes the symptoms.

However, that header is causing a problem of its own: the list of addresses isn't wrapping the way it would if they were all straight ASCII.  I'm seeing a similar issue in a message with a list of addresses separated by semicolons -- I've just reopened bug 355232 about this problem.

Testing more with attachment 247201 [details] as a model, I see that if the MIME-encoded address is in the middle of the list, only the addresses following it are placed on the same line.  And that problem is seen whether the addresses are all in the same To: header (separated by commas) or in multiple To: headers.

Comment 20

[Ben Bucksch (:BenB)]

Guys, this bug is identical to 247833, just for Thunderbird, but the code should be identical. Any reason not to use the patch v3 in bug 247833, or something like it?

Comment 21

[Mike Cowperthwaite]

(In reply to comment #20)
> Any reason not to use the patch v3 in bug 247833, or something like it?

Yes, there is a very good reason: Because Thunderbird is no longer broken, thanks to the fixes at bug 335973.

There is an exception: the pathological case of the sample email here (attachment 247201 [details]) and the one at bug 355232 (attachment 241055 [details]).
These are broken because of a completely different problem: the long multiaddress To/CC lines are failing to wrap to additonal lines, in certain circumstances.

But my patch at bug 240313 mitigates that issue by preventing this bug's symptom, and 355232's, while also fixing bug 223132.

Comment 22

[Mike Cowperthwaite]

The behavior of this problem is slightly different when seen in Shredder's new envelope panel.  The long address list with a MIME-encoded item is wrapped, with a twisty, with the break point at spaces.  So, the problem of the scrollbars going missing is no longer an issue.

However, the list is not parsed out into individual addresses (this behavior still in common with bug 355232).  In a regular long list of addresses, the wrap point is always between addresses (except if the first address is too long to fit, in which case it wraps between spaces.  Also, the star+dropdown icons that appear next to parsed addresses are missing.  I've opened bug 458616 for this deficiency.

I would mark this WFM but I don't know what's going on in Seamonkey-land as far as the envelope panel goes.

Comment 23

[Wayne Mery (:wsmwk)]

(In reply to comment #0)
> Bug 247833 manifests in Thunderbird also, up to 1.5.0.4 and probably in trunk
> also.
> 
> Opening this bug as per the suggestion of Bug 247833, comment 28. Marking
> dependence, although the bugs are more 'related' than 'dependent' and
> 'blocking'.

(In reply to comment #22)
> The behavior of this problem is slightly different when seen in Shredder's new
> envelope panel.  The long address list with a MIME-encoded item is wrapped,
> with a twisty, with the break point at spaces.  So, the problem of the
> scrollbars going missing is no longer an issue.
> ...
> I would mark this WFM but I don't know what's going on in Seamonkey-land as far
> as the envelope panel goes.

=> WFM, as bug 247833 covers the SM side of this and Mike's got the current behavior in bug 458616

Comment 24

[Wayne Mery (:wsmwk)]

Comment on attachment 232439 [details] [diff] [review]
patch0.3: expanded always 5em, overflow-x hidden

clearing review? mscott