184988 - message header display sometimes assumes extra height

Status: RESOLVED WORKSFORME

(SeaMonkey :: MailNews: Message Display, defect)

Description

[Kousik Nandy]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021203
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021203

Some times, in a 3 pane message display, the header takes much more space
than it should; but it is only temporary. When the message is clicked on
the threadTree it is observed. A click on the message makes the problem
disappear (the height is adjusted correctly).

Reproducible: Sometimes

Steps to Reproduce:
1. Click on a message in the threadTree to select.

Actual Results:  
(sometimes) observe the header display taken extra space than it should.

Expected Results:  
It should take correct height.

A screenshot is at http://www.geocities.com/kousik/shot_1.png

Comment 1

[Olivier Cahagne]

is this still an issue with 1.6 or 1.7b ?

Comment 2

[Kousik Nandy]

Yes. I'm using 1.6; and today I captured a screenshot:
http://www.geocities.com/kousik/screen_2.png

Comment 3

[Serge Gautherie (:sgautherie)]

Attachment: Screen Capture of the wrong display

Notice the extra "empty" area under the last 'To:' line; it can be much higher on some messages.

This usually happens at the first (in a session) display of some messages.

Workaround: Reducing/expanding the header pane is enough to fix the display.

Comment 4

[Serge Gautherie (:sgautherie)]

[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.12) Gecko/20050915] (release) (W98SE)
[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b4) Gecko/20050910 SeaMonkey/1.0a] (release) (W98SE)
[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20051124 SeaMonkey/1.5a] (nightly) (W98SE)

Confirming, on Windows (too).

Comment 5

[Karsten Düsterloh]

This happens if an e-mail header like To: is the last header shown and has more than three addresses that together would need more space than those three shown by default (mind the [+] that indicates more, hidden, addresses)...

Comment 6

[[e-mail]]

Attachment: Another possible manifestation of the same bug.

Comment 7

[[e-mail]]

I think I now have steps to reliably reproduce the bug. Compose a message, and address it to foo@foo, bar@bar and "Johann Gambolputty de von Ausfern ... von Hautkopft of Ulm" <baz@baz>. Save it as a template. Now delete foo@foo and save it as another template. Finally delete bar@bar and save that as a template too.

Now view the three templates in the order you saved them. As you view them, the cached address nodes will be populated with the really long email address. Now these address nodes are inside a <label> which means they observe HTML visibility rules, not XUL collapse rules, and so they still take up space.

Comment 8

[[e-mail]]

Wait, I'm using a patch that makes the email addresses wrap more aggressively, could that be the problem?

Comment 9

[Serge Gautherie (:sgautherie)]

(In reply to comment #6)
> Created an attachment (id=220650) [edit]
> Another possible manifestation of the same bug.

[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8) Gecko/20060503 SeaMonkey/1.1a] (nightly) (W98SE)

Valid testcase on SMv1.1a: initially, the splitter appears at the "middle" of the browser window.

Comment 10

[[e-mail]]

(In reply to comment #9)
>initially, the splitter appears at the "middle" of the browser window.
Ah yes, but see what happens when you drag the splitter to the top.

[Note: as per comment #8 I'm no longer sure that the attachment was relevant]

Comment 11

[Serge Gautherie (:sgautherie)]

[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.0.2) Gecko/20060404 SeaMonkey/1.0.1] (release) (W98SE)
[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20060403 SeaMonkey/1.5a] (nightly) (W98SE)

(All 3 branches behave the same.)

If I open the testcase and slowly drag the splitter upward,
it moves "pixel by pixel" until it reaches the bottom of the (3 lines) text,
then stays there and eventually collapse completely to the top of the browser window.
Then, if I click to expand it from there, it draws directly below the text, which is "fine".

But if I open the testcase and immediately click to collapse/expand the splitter, sometimes it will always expand below the text, sometimes it will always expand back to its previous position in the middle of the window ... at least the possibility to have two different behaviours seems wrong.
I can get similar (inconsistent) results if I first move the splitter in the window.

Comment 12

[[e-mail]]

So you don't see any scrollbars?

Comment 13

[Serge Gautherie (:sgautherie)]

Exactly, I never get any scrollbar with this testcase.

Comment 14

[[e-mail]]

So, did this get fixed by bug 335973?

Comment 15

[Mike Cowperthwaite]

(In reply to comment #14)
> So, did this get fixed by bug 335973?

I asked the same question in TB bug 262875, and the answer seems to be Yes.

(Also, I think this is a dupe of bug 174613.)

Comment 16

[[e-mail]]

By the way, I think what was happening here was this: The old code created three elements to show email addresses in collapsed mode. If your message had fewer CCs then the code was supposed to hide the remaining addresses. However the attribute it used conflicted with the CSS styles used to make the email addresses wrap. The upshot was that the extra email addresses were rendered invisibly i.e. they still took up the same amount of space as if the message had really had three CCs.

Comment 17

[Mike Cowperthwaite]

Neil, would you think there's still anything to bug 255201?  On the surface, that appears to be the same basic problem, but reporter there claims he still sees it occasionally in trunk builds.  No CC's seen in the screenshot (from a different reporter).


> However the attribute it used conflicted with the CSS styles used to make
> the email addresses wrap.

Oh yeah?  Could you take a look at bug 355232 and bug 340327?  Both are causing the envelope's real width to expand due to failing to wrap multiple-address lines -- in the first case because they're separated by semicolons instead of commas, in the second case because one of the addresses is MIME-encoded.

Comment 18

[[e-mail]]

Bug 255201, which I've never experienced, would appear to be unrelated to bug 335973 as the former relates to the expanded list whereas the latter relates to the collapsed list.

I guess bug 355232 could be hacked around in nsMsgHeaderParser.cpp using while (*line_end && !((*line_end == ',' || *line_end == ';') && paren_depth <= 0 && (!mailbox_start || mailbox_end))) in msg_parse_Header_addresses.

For bug 340437 I did at one point get long email addresses wrapping at spaces although there were a few issues and I never got around to attaching a patch.

Comment 19

[Mike Cowperthwaite]

(In reply to comment #18)
> For [bug 340327] I did at one point get long email addresses wrapping at
> spaces although there were a few issues and I never got around to attaching
> a patch.

Generally, long lists of addresses are wrapping at the right point; 
attachment 247201 [details] (bug 340327 comment 15 et seq) show the problem I'm specifically mentioning.  The long address string stops wrapping at the first MIME-encoded address, even if subsequent addresses are vanilla.

It's an interesting symptom to consider in light of Christian Eyrich's 
bug 254519 comment 65.

Comment 20

[[e-mail]]

(In reply to comment #19)
>attachment 247201 [details] (bug 340327 comment 15 et seq) show the problem I'm
>specifically mentioning.  The long address string stops wrapping at the first
>MIME-encoded address, even if subsequent addresses are vanilla.
Yes, I agree with Christian's comment - you can see for yourself that the backend is getting it wrong by using Copy Email Address and pasting the result - "'סיור' <someone"@somewhere.org>, Some Very Very Very Long Name 02 <[e-mail]>, Some Very Very Very Long Name 03 <[e-mail]>, Some Very Very Very Long Name 04\" <[e-mail]>\"

Oh, and thanks for fixing my bug number typo :-)

Comment 21

[rsx11m]

This seems WFM with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.4) Gecko/20091007 SeaMonkey/2.0 now, a lot of things have changed in the header pane implementation since this was filed.

On initial opening of a message, it fits the content of the rows without having any additional space underneath, address headers are restricted to a single line unless opened with the twisty.

Comment 22

[Ryan VanderMeulen [:RyanVM]]

Can anyone still reproduce this?

Comment 23

[Philip Chee]

After 11 years it's time to put this bug to sleep.