With Mozilla/5.0 (X11; Linux x86_64; rv:18.0) Gecko/18.0 Thunderbird/18.0a1, built 20120830130605, on Linux: 1. Open a compose window from an email account. 2. Put some HTML text (e.g., bold, italic) in the body of the message. 3. Change the sender to a news account identity. 4. Add both a To and a Newsgroups recipient to the header of the message. 5. Try to send. You will get the attached dialog. Note how the bottom is cut off.

I see that you specified Linux in platform affected. FWIW, the full dialog window appears correctly in Win7

Strangely enough I now tested it in TB18 on Win XP and I get different wording in the dialog than you show in the screenshot. Can you update your Daily and see if it has changed?

There are actually two different windows with slightly different wording. One of them is cut off and one of them is not. If you follow *exactly* the steps I posted above, on Linux, you will get the prompt window that this bug is about. I have just reconfirmed this after updating my trunk build.

What is the format of a Newsgroups recipient ?

(In reply to :aceman from comment #4) > What is the format of a Newsgroups recipient ? Name of the newsgroup.

I think I have followed the steps but I can't get the other (truncated dialog).

Aha! I have a customization in my userChrome.js which makes the steps slightly different for me. You should be able to reproduce by changing the foreground color of some text in step 2, instead of just bold or italic.

And by the way, when I undo my userChrome.js customizations and follow the original steps above, I get a different dialog like you were getting, and the Cancel and Send buttons are visible in that dialog, but they aren't _fully_ visible, i.e., even that dialog is slightly shorter than it should be.

OK, I have seen the other dialog now, in Win XP and it is OK. I'll see in Linux in a while.

(In reply to :aceman from comment #9) > OK, I have seen the other dialog now, in Win XP and it is OK. I'll see in > Linux in a while.

Yeah I can see it on linux. The dialog is this: chrome://messenger/content/messengercompose/askSendFormat.xul I suspect this is because some of the texts in the dialog are inserted after the dialog is up via .textContent and that does not cause reflow. The problem may depend on exact font used for the texts and whether the "anyway?" word fits on the preceding line. For me the word "plain" wrapped to the second line. I've tried window.sizeToContent(); but it does not help either.

Huh? The basic alert dialog does something similar except it manually inserts its text nodes, so I don't see why this dialog should have a problem. Is there a regression range?

OK, on Windows both of the paragraphs also wrap (the 'plain text' and 'anyway' words are on second line). Also the buttons are centered in the bottom of the dialog. On linux they are on bottom right.

No regression range yet. There were big changes to the file in bug 507682 but that one does not seem to touch the logic much. I do not see any other relevant changes in hg log of this file.

Neil, there is something crappy going on here. The Dom inspector reports the <dialog> height to be 600x250px. But that is not true, the window manager sees it as 600x218px. That is when the buttons are hidden behind the bottom edge of the dialog. If you cancel the dialog and open it again, it comes up fine. Both heights are now really 250px.

So we need reflow to happen after the text is filled in. There is probably no .innerText in Gecko, so maybe we can use innerHTML. If that doesn't help, there may be a problem in XUL toolkit.

Neither .innerHTML not sizeToContent() helps me. <deck> does help a bit because it preallocates the space for the longest of the strings. But the buttons are still cut of slightly. The dialog is now 250px high, but DOM inspector says it is 266px (also .clientHeight says so). So there is something wrong in the reflow. Any further proposals?

Not sure, I can't seem to reproduce this on Windows. Once you have the dialog in the "incorrect" state where DOM Inspector disagrees on its height, what happens when you evaluate target.defaultView.sizeToContent() in DOM Inspector's JS Object pane?

I also see this on SeaMonkey. Should we just add a height to the dialog box or could the explanations all be moved to the dtd and put into the xul, then just reveal the relevant one?

I don't think we can add a fixed height as the translations may be differently long. If you mean using <deck>, I tried that in comment 17 and it didn't work. Or did you mean something else? There seems to be some bug in rendering that the window does not have the size the other components think it has.