Compose Mail has spurious boxes

[GoogleCodeExporter]

Reported by a user but I am unable to confirm this bug myself (the Compose
Mail window appears normally to me): under the Subject line are several
large boxes that consume roughly half the window. They cannot be rolled
back, so it chews up a bit of real estate. The reporter also adds

> When I switched to Classic theme, I get a brief moment where the
> multiple boxes appear beneath the subject box, but then they grey out.
> The real estate is still there, un-usable.  And I can not expand the
> Message Pane upward to reclaim that real estate.  But, the behavior
> seems less extreme in the classic theme...  I had 3 and sometimes 4
> additional address boxes beneath the Subject box in the Modern theme,
> and when attempting to adjust, once you pull downward to reduce the size
> of the Message Pane, you then expose MORE empty address boxes above and
> you can't expand into their area once they are in place.
>
> I can manage in Classic mode of course, no biggie.  I just tried to pull
> down to resize the Message Pane, and in Classic mode, I am allowed to
> move it back up to about the mid point of the window's rectangle, but no
> further.

Adding this bug here as unconfirmed while I wait to see if others report this.

Original issue reported on code.google.com by classi...@floodgap.com on 29 Oct 2009 at 3:48

Attachments:

• mai1.pict
• mai1-1.pict

[GoogleCodeExporter]

He also adds

> > If you try to resize the message pane, then windowshade the window and
> > unwindowshade it, does this repaint everything correctly (with the message
> > pane in the proper place)?
>
> No.  Tried that...  I know exactly what you mean, but no.

Original comment by classi...@floodgap.com on 29 Oct 2009 at 3:50

[GoogleCodeExporter]

Also

Original comment by classi...@floodgap.com on 29 Oct 2009 at 3:53

Attachments:

• mai1-1.pict

[GoogleCodeExporter]

I am the original reporting user.  Just want to update my experience with this 
issue:

Originally, as noted above, it appeared that Classic Theme exhibited this issue 
less
than Modern Theme.  In fact, upon further use, the behavior is identical.  It 
does
DISPLAY the issue in a slightly different manner.  Where in Modern Theme, an 
extra
"text" box (or boxes) appears below the Subject box, consuming real estate, in
Classic Theme the equivalent space is consumed but the "extra box(es)" are 
greyed out
as just solid (ever-expanding) panel space.  It should be noted that the extra
box(es) that appear in Modern Theme do not respond to cursor insertion as would 
a
normal text or address box.

Also worthy of note: each successive "Compose" command creates one additional 
empty
box (Modern) or solid panel (Classic) beneath subject box, AD INFINITUM.  For
instance, on first launch of Compose, I get a single "additional box."  Next 
Compose
command, I get two, then three, etc., as they expand into the Message body pane 
which
cannot be "rolled back" over said box(es).  A Quit/Relaunch of 9.04 
re-initializes
this behavior and, once again, the initial "compose" command will produce a 
single
"extra box" beneath Subject, then two, three, etc.

Behavior persists whether using Rich Text of Plain

Behavior persists in both IMAP and POP mail accounts

MacOS 9.1 is using standard "platinum" Finder theme.
No added extentions to Classilla
Standard Renderer or Experimental, no change in behavior.  Default to Standard 
Renderer.
Behavior is repeatable after a fresh re-install of 9.04

Q:  Could this be a prefs related issue?

Original comment by aeverm...@gmail.com on 29 Oct 2009 at 5:58

[GoogleCodeExporter]

I finally see the bug now -- for some reason it didn't start on my system until 
I
opened and closed the compose mail window about a dozen times, then it started 
acting up.

Taking.

Original comment by classi...@floodgap.com on 30 Oct 2009 at 3:30

• Changed state: Accepted

[GoogleCodeExporter]

The bug seems unrelated to what is actually in the left <hbox> of the XUL 
compose
window. Removing the textbox doesn't change anything either.

Original comment by classi...@floodgap.com on 30 Oct 2009 at 4:23

[GoogleCodeExporter]

The listbox seems a likely suspect because at least in Classic theme the blue
pinstripe enters the "dead" area and paints the whole way down to the message 
pane.
However, putting a fixed height on it in the CSS for the window doesn't do 
anything
(it certainly doesn't shrink it).

This makes me think this is layout, which would be really unfortunate.

Original comment by classi...@floodgap.com on 30 Oct 2009 at 4:46

[GoogleCodeExporter]

Regression appears to be present as far back as the 20090922 snapshot.
As there is currently no workaround, upgrading to high.

Original comment by classi...@floodgap.com on 30 Oct 2009 at 12:39

• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

patches applied at that point were

C13 (M222730/m)
C40 C54 C58 (custom plus M104778 M130265/m M178729/m M198660 M205817 M205989
M210451/p M210556
M231393 M237566/p M244776/m M249322 (Suite patch only) M277224/m M280215 
M297122/m
M302575 M306810)
C46 (M137315 M235171)
C49 (M205850)
C55 (M194638 M207477/m)
M43267 M97695 
M229654 M233480/m (attachment 140919) M237366
M216303
M219693/m M221784/m
M293761
M231278
M252771/m
M174688/m (completed)
M206516 M292295 M205790/p M273193/m
M245715 (with pull ups) M92217
M226954 M227819 M230249 M232754
M197581

I suspect anything touching nsBox or nsBoxFrame.

Original comment by classi...@floodgap.com on 30 Oct 2009 at 12:46

[GoogleCodeExporter]

Original comment by classi...@floodgap.com on 6 Nov 2009 at 5:48

• Added labels: Regression

[GoogleCodeExporter]

Upgrading to Critical; this will be solved for 9.1.

Original comment by classi...@floodgap.com on 30 Jan 2010 at 7:05

• Added labels: Priority-Critical
• Removed labels: Priority-High

[GoogleCodeExporter]

Suspects:

M229654
M174688
M206516
M292295

Some of these need to be fixed, too, as they do not appear to (any longer?) fix 
their
test case. I suspect they may not have applied correctly.

Also, while we're at it, we should try to round out M233480 now that we are on
overflow branch and can tolerate the more advanced content/ patches.

Original comment by classi...@floodgap.com on 3 Feb 2010 at 6:42

[GoogleCodeExporter]

Interestingly, when the XUL is viewed in DOM Inspector, it appears *correctly*!
Otherwise, it appears it's not just that the listbox has its height ruined -- it
doesn't appear that the listbox with the message headers appears *at all*.

Original comment by classi...@floodgap.com on 3 Feb 2010 at 6:44

[GoogleCodeExporter]

... thus this implies we may be able to fix this without backing stuff out. But 
let's
clean up these patches first.

Original comment by classi...@floodgap.com on 3 Feb 2010 at 6:45

[GoogleCodeExporter]

Could JavaScript be doing this? Maybe that explains the difference why it lays 
out in
DOM Inspector.

Original comment by classi...@floodgap.com on 3 Feb 2010 at 6:49

[GoogleCodeExporter]

After a lot of fiddling in DOM Inspector and the JS debugger, if we prevent
addressingWidgetOverlay.js::CompFields2Recipients from running, the listbox 
lays out
properly (and doesn't keep growing). This is not a solution because we can't add
headers, but something in that function is fouling our display.

Original comment by classi...@floodgap.com on 11 Feb 2010 at 5:47

[GoogleCodeExporter]

Commenting out

    var parent = listbox.parentNode;
    parent.replaceChild(newListBoxNode, listbox);
    awFitDummyRows(2);
    setTimeout("awFinishCopyNodes();", 0);

makes it almost work. We did upgrade replaceChild() for 9.0.4 and I think 
that's what
the bug is -- so this is not a bug in JavaScript or layout, it's actually a 
problem
with DOM. It might be simpler just to code around it.

Original comment by classi...@floodgap.com on 11 Feb 2010 at 5:59

[GoogleCodeExporter]

M197427 seems right up our alley.

Original comment by classi...@floodgap.com on 11 Feb 2010 at 6:03

[GoogleCodeExporter]

After closer evaluation, it appears that M197427 caused many regressions. I 
don't
think we want this for 9.1, so I backed it out even though it appears to land.

The functionality we lack by losing that code appears to be adding more than 
four
header lines, and backspace doesn't work. The second is critical, the first 
would be
really really nice. If we can get those dealt with, that's close enough to 9.0 
that
can be shippable, and we can come back to replaceChild() (M197427 and all its
regressions) in a future version, probably for 9.2 or 9.2.1, for the final fix.

The other possibility is changing replaceChild() to something more like it was 
in 9.0
for XUL only. We are already out of compliance by having XUL different from HTML
anyway, so that might not be so bad.

Original comment by classi...@floodgap.com on 11 Feb 2010 at 7:08

[GoogleCodeExporter]

Relevant code, btw, was in content/ -> nsGenericElement.cpp and
nsGenericXULElement.cpp. Notice that XUL already has a nearly totally different
ReplaceChild.

Original comment by classi...@floodgap.com on 11 Feb 2010 at 7:11

[GoogleCodeExporter]

Offender turned out to be our modified patches for M237566. Wisely I had not 
gutted
the code as badly as that patch does, and left most of the old code intact. 
However,
I made the assumption in nsCSSFrameConstructor::ContentReplaced that since the 
patch
seemed to make aOldChild and aNewChild the same, that I could just use aOldChild
everywhere. However, the XUL code is calling it with different values that was
replaced prior to M237566, so it fails. The patch was to change the 
ContentInserted
call to use aNewChild like it used to.

Ironically, it really *was* a layout bug, but only exposed by DOM!

VERIFIED

Original comment by classi...@floodgap.com on 12 Feb 2010 at 5:35

• Changed state: Verified

[GoogleCodeExporter]

This also repairs issue 84. The layout problems I pointed out were moved to 
issue 1
for later consumption.

Original comment by classi...@floodgap.com on 12 Feb 2010 at 5:38