Closed Bug 399410 Opened 17 years ago Closed 17 years ago

[FIX]composer text box doesn't scroll down when typing past end of last line

Categories

(Core :: Layout: Images, Video, and HTML Frames, defect)

defect
Not set
major

Tracking

()

RESOLVED FIXED

People

(Reporter: nelson, Assigned: bzbarsky)

References

Details

(Keywords: regression)

Attachments

(2 files, 1 obsolete file)

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.
Reassigning to Boris per his request in bug 393723 comment 15.
Assignee: nobody → bzbarsky
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.
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)
Yeah, that's what I see. This regressed between 2007-09-20-01 and 2007-09-21-01.
Looks like a regression from bug 396587. Digging into it.
Assignee: bzbarsky → nobody
Blocks: 396587
Component: MailNews: Composition → Layout: HTML Frames
QA Contact: composition → layout.html-frames
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?
Assignee: nobody → bzbarsky
Keywords: regression
OS: Windows XP → All
Hardware: PC → All
Summary: composer text box doesn't scroll down when typing past end of last line → [FIX]composer text box doesn't scroll down when typing past end of last line
Attachment #284573 - Flags: superreview?(roc)
Attachment #284573 - Flags: review?(roc)
Attachment #284573 - Flags: approval1.9?
Blocks: 397871
Attachment #284573 - Flags: superreview?(roc)
Attachment #284573 - Flags: superreview+
Attachment #284573 - Flags: review?(roc)
Attachment #284573 - Flags: review+
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.
Attachment #284573 - Flags: approvalM9?
Comment on attachment 284573 [details] [diff] [review] This fixes it, even in the face of reentry. a=drivers for after M9 freeze
Attachment #284573 - Flags: approvalM9?
Attachment #284573 - Flags: approvalM9-
Attachment #284573 - Flags: approval1.9?
Attachment #284573 - Flags: approval1.9+
This is identical to the previous patch, but with a weakframe check to handle |this| dying.
Attachment #284573 - Attachment is obsolete: true
Attachment #287056 - Flags: superreview?(roc)
Attachment #287056 - Flags: review?(roc)
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?
Attachment #287056 - Flags: superreview?(roc)
Attachment #287056 - Flags: superreview+
Attachment #287056 - Flags: review?(roc)
Attachment #287056 - Flags: review+
GetPositionAndSize flushes layout, which means it can run queued up style changes and XBL constructors....
Checked in.
Status: NEW → RESOLVED
Closed: 17 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Product: Core → Core Graveyard
Component: Layout: HTML Frames → Layout: Images
Product: Core Graveyard → Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: