Nelson Bolyard (seldom reads bugmail) Reporter
	Description • 17 years ago

Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9a9pre) Gecko/2007100703 SeaMonkey/2.0a1pre  (trunk nightly)

100% reproducible.  

Type anything on the bottom line in the email composer text box and keep 
typing until you type past the right edge of the box, and then the text 
you type will be entered below the bottom of the text box (the box won't 
scroll up).  The email composer just seems to take no notice that you've
typed below the bottom of the text area.

Note that unlike bug 393723, this bug does not affect the text editor in 
SM browser windows.  The problem is not seen when typing into a text box
in a browser page, like the box into which I am now typing this comment.
It appears only in the email composer.

	Nelson Bolyard (seldom reads bugmail) Reporter
	Comment 1 • 17 years ago

Reassigning to Boris per his request in bug 393723 comment 15.

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 2 • 17 years ago

Nelson, does the bottom part of the scrollbar (e.g. the bottom scrollarrow) end up extending below the status bar when this happens?  That is, does it look like the entire editing area is too tall for the window all of a sudden?

That's what I'm getting here, at least sometimes.  Will dig more tomorrow.

	Nelson Bolyard (seldom reads bugmail) Reporter
	Comment 3 • 17 years ago

Boris, 
I'm not sure of the answer to your question in bug 393723 comment 16,
so I thought I'd attach this image and let you decide for yourself.
(I think maybe the answer is: yes, something's wrong with that scroll bar)

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 4 • 17 years ago

Yeah, that's what I see.  This regressed between 2007-09-20-01 and 2007-09-21-01.

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 5 • 17 years ago

Looks like a regression from bug 396587.  Digging into it.

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 6 • 17 years ago

So the key is this sequence of events:

nsSubDocumentFrame::ReflowFinished
PresShell::HandlePostedReflowCallbacks
PresShell::DidDoReflow
PresShell::ProcessReflowCommands
PresShell::DoFlushPendingNotifications
PresShell::FlushPendingNotifications
nsDocument::FlushPendingNotifications
nsDocShell::GetPositionAndSize
nsSubDocumentFrame::ReflowFinished

In particular, in ReflowFinished we set mPostedReflowCallback to false, then get our size, then get the docshell position and size, which triggers a layout flush that incidentally changes our size(!).  So we go through and set this new later size on the docshell... then unwind and set the old, earlier size.

roc, smaug, is it expected that reflow callback processing will reenter this way?

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 8 • 17 years ago

Comment on attachment 284573 [details] [diff] [review]
This fixes it, even in the face of reentry.

I think this is a very safe fix, and it fixes some nasty issues in mailnews and possibly with general scrollable iframe sizing.  Worth taking for the beta, in my opinion.

	Mike Beltzner [:beltzner, not reading bugmail]
	Comment 9 • 17 years ago

Comment on attachment 284573 [details] [diff] [review]
This fixes it, even in the face of reentry.

a=drivers for after M9 freeze

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 10 • 17 years ago

This is identical to the previous patch, but with a weakframe check to handle |this| dying.

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 11 • 17 years ago

Comment on attachment 287056 [details] [diff] [review]
Need to handle destruction

Do I want to know how GetPositionAndSize can kill the frame? Can it run script somehow?

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 12 • 17 years ago

GetPositionAndSize flushes layout, which means it can run queued up style changes and XBL constructors....

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 13 • 17 years ago

Checked in.