Closed Bug 339470 Opened 14 years ago Closed 14 years ago

Testcase in bug 210240 crashes [@ nsIMEStateManager::IsActive] after first alert

Categories

(Core :: DOM: UI Events & Focus Handling, defect)

x86
Windows XP
defect
Not set
critical

Tracking

()

RESOLVED FIXED

People

(Reporter: martijn.martijn, Unassigned)

References

()

Details

(Keywords: crash, regression, testcase, Whiteboard: [sg:nse null deref] post 1.8-branch)

Crash Data

Attachments

(1 file)

Flags: blocking1.9a1?
Talkback ID: TB19197302K
nsIMEStateManager::IsActive   nsIMEStateManager::OnChangeFocus   nsEventStateManager::PreHandleEvent   PresShell::HandleEventInternal   PresShell::HandleEvent   nsViewManager::HandleEvent   nsViewManager::DispatchEvent   HandleEvent   nsWindow::DispatchEvent   nsWindow::DispatchFocus   nsWindow::ProcessMessage   0x7ffdfc00
0x7ffdfc00
0x7ffdfc00
0x7ffdfc00
0x7ffdfc00 (etc)

So based on talkback, maybe bug 55751 is the guilty one?
Summary: Testcase in bug 210240 crashes after first alert → Testcase in bug 210240 crashes [@ nsIMEStateManager::IsActive] after first alert
Is this accessing to null pointer?
# I cannot see bug 210240 and the testcase.
Isn't this is a regression of bug 338122?
That patch removes pointer check in nsIMEStateManager::IsActive.
(In reply to comment #3)
> Isn't this is a regression of bug 338122?
> That patch removes pointer check in nsIMEStateManager::IsActive.

Ah, sorry. It's not right. the comment 0 doesn't say so.
Attached patch test patchSplinter Review
If the cause is the mShell of nsPresContext is null, this *suppress* to crash.
But maybe roc hate this patch. However, I don't know why the case is existing.
(In reply to comment #5)
> However, I don't know why the case is existing.
>

When presshell is being deleted, prescontext's pointer to it is set to
null. That may happen especially during event handling.

Does this crash still happen? Couldn't reproduce.

I still crash with the testcase, using:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061203 Minefield/3.0a1
This is 'just' a null pointer crash. 
Comment on attachment 224341 [details] [diff] [review]
test patch

Could we take the patch?
Attachment #224341 - Flags: superreview?(roc)
Attachment #224341 - Flags: review?(roc)
Comment on attachment 224341 [details] [diff] [review]
test patch

We can take this, although since nsPresContext::PresShell is never supposed to return null, it's bad that it can. So I'd like to see a patch that fixes that ... I thought presshell lifetime was suppsed to fully enclose the lifetime of its prescontext?
Attachment #224341 - Flags: superreview?(roc)
Attachment #224341 - Flags: superreview+
Attachment #224341 - Flags: review?(roc)
Attachment #224341 - Flags: review+
Checked in.

We do have if (presContext->presShell) tests elsewhere too, 
for example they are needed in ESM, unfortunately.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Whiteboard: post 1.8-branch
Group: security
Whiteboard: post 1.8-branch → [sg:nse null deref] post 1.8-branch
Flags: blocking1.9a1?
Flags: wanted1.8.1.x-
Crash Signature: [@ nsIMEStateManager::IsActive]
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.