Closed Bug 670058 Opened 8 years ago Closed 8 years ago

crash nsFrame::ExpandSelectionByMouseMove (click on <textarea> for adding comment in facebook)


(Core :: User events and focus handling, defect, critical)

Not set





(Reporter: masayuki, Assigned: masayuki)


(Depends on 1 open bug, Blocks 1 open bug)


(Keywords: crash, regression, testcase)

Crash Data


(3 files, 1 obsolete file)

The STR is:

1. mousedown on the textnode of default text in <textarea> for adding comment on facebook.
2. mousemove
Hmm, I need to move mouse to bottom in #2. I'm trying to write simple testcase but I cannot reproduce it...
The STR isn't correct, I reproduced without the textnode...
Attached patch Patch v1.0 (obsolete) — Splinter Review
This fixes the crash. However, I don't find to reproduce it simply, so, this patch doesn't have the test.
Summary: crash nsFrame::ExpandSelectionByMouseMove (click on default text in <textarea> for adding comment on facebook) → crash nsFrame::ExpandSelectionByMouseMove (click on <textarea> for adding comment in facebook)
Crash Signature: [@ nsFrame::ExpandSelectionByMouseMove] → [@ nsFrame::ExpandSelectionByMouseMove] [@ nsFrame::ExpandSelectionByMouseMove(nsFrameSelection*, nsIPresShell*, nsMouseEvent*, nsEventStatus*) ]
Attached patch Patch v2.0Splinter Review
When presShell is detached from frameSelection, the frameSelection should abort the dragging for selection.

I couldn't reproduce this bug with simple testcase, so, this patch doesn't have regression test which should be in this, though...
Attachment #544719 - Attachment is obsolete: true
Attachment #544938 - Flags: review?(Olli.Pettay)
So why does this fix the crash?
When the textarea in facebook gets focus, something was destroyed for restyling. At that time, nsTextInputSelectionImpl::SetScrollableFrame() detaches the presShell from the frameSelection which is handling the dragging. Therefore, nsFrameSelection::GetShell() returns NULL in nsFrame::HandleDrag(). That causes nsIContent::GetSelectionRoot() to fail to get the selection root of the content due to NULL presShell (in GetSelectionRootContentForCapturingContent()).

I'm not sure what styles are changed and causes the crash...
Attached file testcase
I'm seeing this crash with this testcase, while drag-selecting in the textarea.
Attachment #544938 - Flags: review?(Olli.Pettay) → review+

pushed to inbound without tests. however, I can reproduce this bug with attachment 545065 [details] (Thank you, Martijn!), so, I'll write the regression test.
Whiteboard: [inbound]
I confirmed that this test makes crash without the patch v2.0.
Attachment #545148 - Flags: review?(Olli.Pettay)
Comment on attachment 545148 [details] [diff] [review]
regression test v1.0

Someone will complain about the interval, but IMO it is ok.
Attachment #545148 - Flags: review?(Olli.Pettay) → review+
Closed: 8 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Whiteboard: [inbound](5618a1b01989 and 2bc2ed17af7a) → (5618a1b01989 and 2bc2ed17af7a)
Target Milestone: --- → mozilla8
2bc2ed17af7a is still in inbound due to separated checkin.
Whiteboard: (5618a1b01989 and 2bc2ed17af7a) → [inbound](only 2bc2ed17af7a)
And merged:
Whiteboard: [inbound](only 2bc2ed17af7a)
Fwiw, I'm still hitting this crash (after the fix for this bug), but I haven't been able to get a minimized testcase yet.
(In reply to comment #16)
> Fwiw, I'm still hitting this crash (after the fix for this bug)

On a build from which channel and with which build ID?
This is showing up on 8.0a1 for build id = 20110712030758. I don't see anything for the 13th yet. Can someone confirm the checkin happened AFTER we did that build?
It was merged at 3:44 PDT on the 12th, so it would have definitely missed the nightly for the 12th.
Are you sure? I can't reproduce the crash with the attached testcase using the 2011-07-12 build.

However, I am able to reproduce the crash with a testcase (that I finally have been able to minimize on my computer) with that same build. The crashes that Sheila mentioned in comment 19 are probably mine.
Keywords: 4xp, testcase
I filed bug 671319 for the crash that I was seeing in comment 16. I haven't looked for a  regression range for it, but might very well have the same regression range as this bug.
That's because you're on the ux branch, which probably hasn't pulled the fix in.
Temporarily, backed out for risk management of mozilla8, see bug 675865.
Target Milestone: mozilla8 → mozilla9
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.