Steps: 1) Open a new/blank Composer document 2) Just click on the font or heading pull down menus Actual Results: Notice that you see some of the options, but most are covered by a screen shot of some weird image Expected Results: See pull down menus Build Date/Platform: WinNT 1999120915

We believe this is a dup...and isn't this only font?

I get this for both pull down menus.

Charley -- any ideas?

It's obviously a layout/display problem of the contents of the list portion that displays when you activate the control. These widgets have worked ok for some time and we haven't changed anything in the editor concerning these in many weeks. I've tried to find other example of comboboxes not displaying correctly, but they seem to be OK in dialogs. Those in Composer's toolbar are the only ones I've seen whose list portion displays over a dynamic content window. Rod and Troy: Please help!

can't you work around this for dogfood my using the format menu instead of the combo box in the toolbar button?

Yes, but this problem seems indicative of some basic layout/redraw problem that should be addressed sooner than later, IMHO.

PDT suggests work-around for dogfood eaters.

setting to m13

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

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

adding myself to cc: list since this also affects the composer items in the mail compose window.

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

I've gotten no response from emails on the issue, so I'm assigning the bug to layout. More hopefully-helpful information: When the list is drawn over the editor content window, it seems to copy the bits from the underlying content, draw it in the list part instead of the option items! And the selected item is drawn (looks like the correct location in the list) with the borders of the closed combobox, not the normal selection style. I can't come up with a Viewer test, since it looks like comboboxes in a web page form and those in the dialogs display correctly. So I tried the following: Change the following line in editor/ui/composer/content/editor.xul: <toolbar id="FormatToolbar" persist="collapsed"> to <toolbar id="FormatToolbar" persist="collapsed" style="height: 200px"> so the toolbar is 200px high. The portion of the combobox list within the expanded toolbar now displays correctly. But notice that the botton 2 items, which still overlap the editor content window, still show drawing problems. So it's certainly not an editor problem. This bug did not exist in my tree as of 12/8 and appeared when I updated on 12/12.

Re-assigning to Rod, because it's combo box related. It don't know whether it's a XUL issue or a combo box issue

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

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

This is a view issue. I have tried to explicitly set the z-order of the drop-dwon view and it made no difference, I feeling it is the view clipping out other views bug that we have seen before. - reassigning to beard

This happens on Mac OS as well. Expanding the platform/OS description. Rods, where did you attempt to alter z-order? And how did you do it? Is a single view manager handling both the toolbar and editor content areas?

This is not a z-ordering problem, but is instead a view parentage problem. By default, all child views are clipped to their parent views. My guess is that the parent view you are getting is the view surrounding the toolbar itself. If I click on the "paragraph alignment" button on the far right of the toolbar, it brings up an XP menu popup that does completely draw. The parent views are different. Can you arrange to have the same parent view for all 3 popups? What is different about the two combo boxes?

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

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

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

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

The Paragraph style and font face widgets are HTML <select> elements (true "comboboxes") while the alignment widget is a XUL <menupopup>. The XUL is straightforward: <window...> <toolbox> [the main toolbar is here]... <toolbar id="FormatToolbar" persist="collapsed"> <html:div> <!-- items are filled out from editorOverlay --> <html:select id="ParagraphSelect"/> <html:select id="FontFaceSelect"/> </html:div> [some titled buttons]... <menu> <titledbutton id="AlignPopupButton"/> <menupopup id="AlignmentPopup"/> </menu> <spring flex="100%"/> </toolbar> [sidebar, editor content window, status bar]... </window> I see no other way to write the XUL -- this should work as shown. I tried eliminating the <html:div> around the <html:select> elements but that made no difference. If there's a different view parent, then it's still a layout problem. Not sure if it's a beard or rods problem, sending back to beard first. This definitely needs to be fixed for Beta - raising severity level.

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

With the recent surgery I performed on the view manager, this no longer happens. It seems to be fixed on all platforms.

verified in 1/18 build.