Closed Bug 339470 Opened 20 years ago Closed 19 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 patch — — Splinter 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: 19 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.

Attachment

General

Created:
Updated:
Size: