Closed
Bug 297224
Opened 20 years ago
Closed 20 years ago
Lockup in nsFrame::PeekOffset() with textarea element.
Categories
(Core :: Layout, defect)
Core
Layout
Tracking
()
RESOLVED
FIXED
People
(Reporter: jst, Assigned: mrbkap)
Details
(Keywords: regression)
Attachments
(3 files)
461 bytes,
text/html
|
Details | |
1.36 KB,
patch
|
roc
:
review+
roc
:
superreview+
benjamin
:
approval1.8b3+
|
Details | Diff | Splinter Review |
3.95 KB,
patch
|
roc
:
review-
|
Details | Diff | Splinter Review |
Hitting the down arrow key when on the last line in the textarea in the testcase
I'm about to attach makes Deer Park (alpha 1) lock up. The lock up is in
nsFrame::PeekOffset(), we're spinning forever in the while loop in the
eSelectLine case.
Reporter | ||
Comment 1•20 years ago
|
||
This is a regression since 1.0. Still works on the 1.0.1 branch, so something
changed on the trunk...
Comment 2•20 years ago
|
||
Where's the promised testcase?
Comment 3•20 years ago
|
||
jst, could you attach your testcase please?
Comment 4•20 years ago
|
||
blocking- until a testcase appears ;-) please renominate then.
Flags: blocking1.8b3?
Flags: blocking1.8b3-
Flags: blocking-aviary1.1?
Flags: blocking-aviary1.1-
Reporter | ||
Comment 5•20 years ago
|
||
Duh, totally missed the fact that I forgot to attach the testcase here :(
Reporter | ||
Updated•20 years ago
|
Flags: blocking1.8b4?
Assignee | ||
Comment 6•20 years ago
|
||
Note: The caret has to not be over the "Submit" button when you push down or
you will not see the hang.
What's happening here is that when we set nearStoppingFrame, we set it to the
first frame in the current line unconditionally (even if this frame is not a
leaf). While we're iterating over the frames in the line, we use a leaf
iterator to do so, checking against nearStoppingFrame to see if we've hit the
first frame in the line. In this case, nearStoppingFrame is the button frame,
but it isn't a leaf, so the frame travseral passes it up and goes to its
previous frame, namely, the HR frame. The HR frame is a block, so we look for a
place to put the caret in _it_, but all that does is bring us to the next line,
where we loop.
This patch makes the frame traversal "extensive", so we always hit
nearStoppingFrame. Another possibility would be to always dig into the last
leaf of every frame we encounter. Roc, do you have any preference?
Assignee | ||
Updated•20 years ago
|
Assignee | ||
Comment 7•20 years ago
|
||
This is the alternate solution.
Assignee | ||
Updated•20 years ago
|
Attachment #187822 -
Flags: review?(roc)
Attachment #187821 -
Flags: superreview+
Attachment #187821 -
Flags: review?(roc)
Attachment #187821 -
Flags: review+
Attachment #187822 -
Flags: review?(roc) → review-
Assignee | ||
Comment 8•20 years ago
|
||
Comment on attachment 187821 [details] [diff] [review]
potential solution
This is a small patch to fix an easy-to-trigger (in the right circumstances)
hang.
Attachment #187821 -
Flags: approval1.8b3?
Comment 9•20 years ago
|
||
Comment on attachment 187821 [details] [diff] [review]
potential solution
Please land today.
Attachment #187821 -
Flags: approval1.8b3? → approval1.8b3+
Assignee | ||
Comment 10•20 years ago
|
||
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Comment 11•20 years ago
|
||
this seems to have caused a freeze selecting across a select dropdown arrow, bug
299533
Updated•20 years ago
|
Flags: blocking1.8b4?
You need to log in
before you can comment on or make changes to this bug.
Description
•