When you enter more than 3 recipients, the subject edit field jumps over the recipients field. This occurs with builds from this morning (I have tested it on Mac and Windows). mscott told me that he saw that with a build from last night 10 pm. 1) Open a new message 2) enter a first recipient address, press <enter> 3) enter a second recipient address, press <enter> 4) enter a third recipient address, press <enter> 5) Now, move your mouse over the menu bar 6) ==> the subject is over the recipients

I don't believe I touched the tree code last night.

if it's not the tree code, it's maybe something to do with scrolling!

Nominate for beta1

Putting no PDT+ radar for beta1.

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

Bug 26133 has similar results. When I see this symptom, the subject line goes to the top of the box, the rest is just grey background, and a scroll bar appears. If you click in the subject box, the edit box then draws on top of the scroll bar.

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

Fixed.

OK using: 2000-02-04-08m14 commercial build linux rh6.0 2000-02-04-10m14 commercial build NT 4.0

To verify on NT and linux, I had to use reply-all to get an address block showing more than 2 headers. I can't do that on Mac because of bug #26618 and #26344.

Reopening... The subject line now jumps over address block in this simple case: 1. Open new compose window. 2. Type one address on To: line. 3. Click on the subject line. Result: subject line is now over the addressee area. Happens on all platforms using feb10 or feb11 commercial builds.

removed my feb08/09 comments from status whiteboard

This also affects AIM. CCing amusil, scalkins,prass

This appears to be Ender's fault. It only happens if the Subject text field has not yet undergone the transformation from Bruce Banner to The Incredible Hulk. In other words, the act of becoming heavyweight ("Don't make me editable. You won't like me if I'm editable.") seems to be causing problems. Reassigning to buster.

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

Ok, now i've managed to fix that problem, but the text widget just seems to jump and draw itself in the wrong place before always returning to the right place, a la what it does in the New Card dialog in address book.

Another case for this is in AIM after you log in and choose "Find A Buddy". Clicking in the input field jumps the field up about 100px.

can't look into this until 26618 is fixed :(

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

From akkana: If I back out this evaughan checkin from yesterday to the following revision numbers (from just before his checkin), I no longer see the problem. cvs update -r1.364 layout/html/style/src/nsCSSFrameConstructor.cpp cvs update -r1.43 layout/xul/base/src/Makefile.in cvs update -r1.40 layout/xul/base/src/makefile.win cvs update -r1.83 layout/xul/base/src/nsBoxFrame.cpp cvs update -r1.35 layout/xul/base/src/nsBoxFrame.h cvs update -r1.24 layout/xul/base/src/nsDeckFrame.cpp cvs update -r1.15 layout/xul/base/src/nsDeckFrame.h cvs update -r1.2 layout/xul/base/src/nsTitledBoxFrame.cpp cvs update -r1.140 xpfe/browser/resources/content/navigator.xul cvs update -r1.37 xpfe/global/resources/skin/global.css

given the extent of files that need to be backed out to get this to work, I strongly prefer to wait for eric to get back from vacation and take care of this. Need guidance from PDT team to know if this is acceptable, or if his changes should be backed out, or if I should try to fix it in his absence. I've spent a lot of time on this, but I'm no expert on box layout, so any fix I came up with would likely need eric's review anyway.

I think this should wait till Eric gets back, if at all possible. Hyatt is also avoiding making any changes to the new box code,and he was familiar with the old box code.

consensus seems to be to wait for evaughan. reassign back to me if that decision changes.

Has this been fixed? I'm not seeing this in today's build (2000-02-22-08) on WinNT.

Don't see this on Linux either. dropping priority to P2 until I hear how much of a blocker this is (priority is only relative to Eric's other blocker)

This does not happen on windows either. Closing out.

it would be comforting to know *what* changed to make this work, since many people reported it last week. if it's something as dumb as an uninitialized variable or a memory clobber, then it's not really fixed it's just hidden for now. sorry, I get paranoid near public releases!

Some info from QA: In the past several days one thing which has been fixed is the dependency bug #26618; maybe some clues there as to why this bug isn't being seen anymore. A new bug has been logged ( bug #28696 ) which strikes me as a duplicate of this one -- symptoms are described just like hyatt's 2-13 comments in this bug report and are like the ones in bug #28217, which was marked a duplicate of this one. This new bug 28696 is reported in current builds.

I'm going to go ahead and mark this one verified since I don't see it using feb24 commercial builds on mac, linux and NT.

OK, I found a case which will reproduce the address line jumping into title bar effect using a reply all window. I'm going to put my scenario in bug #28696 since its description follows suit more closely.