Using the 1/25 build of Linux seamonkey 1) load the URL. 2) notice the following: Form buttons are not in the right place Form buttons have text thats not supposed to be in there. This site does have frames. See Windows for correct layout/rendering. I'm cc:'ing karnaze on this one also.

adding Pollmann to report, deleting Karnaze.

Also another rendering issue on the Mac. I'm gonna mark this bug cross platform. On the Mac, look at the pulldown menu at the top of the page for "Websites" right below the search field. on the mac there's nothing to pulldown. Works fine on Mac 4.51 build. Can one of you developers add a Mac engineer to the CC: list. I don't know anyone on Mac team.

Inserting Milestone info.

Setting all current Open/Normal to M4.

per leger, assigning QA contacts to all open bugs without QA contacts according to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser

I just tried this page on both win32 and linux 3/26 builds and i get the same result. There seem to be two layout problems: 1) The top left/right spacers are too high. 2) If the window is made smaller horizontally, the text_field, combo_box and animated gif will end on top of each other. This seems to be a XP layout problem. Can a QA person please verify this and ressign ? thanks.

I'm investigating this one...

yes I see the same problems that Ramiro is seeing..re-assigning to rickg because its a XP layout problem.

Removing [PP] since this occurs on all platforms.

Kipp-- Much as I hate to add to your tasklist, this is a legit but.

Some of the horizontal bands are too tall (bug #4769). The form elements are acting really weird today - if I just roll the mouse over them they disappear! Probably a bug in the gfx rendered form elements which are still on for some reason.

Bug 4769 has been marked a dup of bug 5821.

I only see 1 remaining problem on this page: the "Find" button is not positioned correctly. I have attached a testcase for that above. A few observations I made while making the testcase: You can get correct layout by: removing width=100% on the outermost table OR removing   between the the two form elements OR removing width=100% on the last table cell I was using nightly build 1999-08-12-10-M9 on Windows NT.

The table formats itself differently because of how we treat &nbsp's during line-layout vs. how navigator treats them...The test case shows this.

I see two things wrong with this page, with a current tree: 1) Too much space is reserved for the select element. If you click on the arrow button, you will see that the extra space is taken up by the one line drop down...I believe that's a bug because it means that either the element is returning a height that is too large or a max-element-size.height that is too large. 2) The find button is not given enough width - if you enable borders (I attached a slightly simpler updated test) you will see the button overlapping the borders (at least that's what I see on my linux box). My guess is that the max-element-size.width for the button is not including the borders and padding properly... Reassigning to rods to dispatch to himself or to kevin to deal with as these aren't block frame issues.

Ok, I'm an idiot (news?) -- I just reread one of my own comments and relearned what the real issue is...I'm assigning it back to me - sorry for the disruption. Please return to your previously scheduled duties :-)

More data: navigator 4 seems to make nbsp's sticky *on the left*. We don't make them sticky at all, except to other pieces of text. Hmmmm.

Fixed. I've made nbsp's sticky on the left edge like nav4 does.

verified in 12/7 build.