590287 - Crash in [@ nsPresShellEventCB::HandleEvent(nsEventChainPostVisitor&) ]

Status: RESOLVED WORKSFORME

(Core :: Layout, defect, P1)

Description

[Jim Mathies [:jimm]]

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b5pre) Gecko/20100824 Firefox/3.6.4 ( .NET CLR 3.5.30729; .NET4.0C)

STR, On win7:

1) click the little gold star in the address bar to bring up "edit this bookmark" panel
2) alt-tab away from the window

http://crash-stats.mozilla.com/report/index/36c08342-5a5c-4eab-affe-29d6a2100824

http://hg.mozilla.org/mozilla-central/annotate/9a623cc1c5e7/layout/base/nsPresShell.cpp#l1406

Appears to have something to do with IME related events. This might be a widget bug.

Comment 1

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Hmm... I cannot reproduce this bug on both trunk and 3.6.8 (Win7-Ja)...

Comment 2

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

> Appears to have something to do with IME related events. This might be a widget
> bug.

When a widget receives WM_IME_NOTIFY during an Alt key pressed, we dispatch a fake key event for preventing that menubar will become active. Because Alt+` turn on/off Japanese IME, so, the Alt key down event shouldn't steal focus from an editor.

I think that this is nsPresShell's bug because the dispatcher widget isn't the destroying panel's widget.

Comment 3

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

> the Alt key down event shouldn't steal focus from an editor.

Next Alt key up event shouldn't steal focus from an editor.

See:
http://hg.mozilla.org/mozilla-central/annotate/9a623cc1c5e7/widget/src/windows/nsIMM32Handler.cpp#l738

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

So any idea why we're crashing? Is the frame a dead object?

Comment 5

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to comment #4)
> So any idea why we're crashing? Is the frame a dead object?

I guess so. Can there be any other reasons?

Comment 6

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

OnIMESetContext() calls DefWndProc(), then, WM_IME_NOTIFY is sent. OnIMESetContext() is called by WM_IME_SETCONTEXT which is received when the window gets/loses focus. I guess that the message is for losing focus, i.e., the panel was already closed. So, the frame might be a part of the panel.

Comment 7

[Daniel Veditz [:dveditz]]

Could the conditions be duplicated with web content? If so that would make this a more important security bug (if frames are dead as speculated). If it requires user-action in chrome then it's a low-risk bug.

The stack in comment 0 shows a frame-poisoned address, so "sg:dos" on branches with frame-poisoning. If this can be made to happen in 1.9.1 then it would be a potentially exploitable dead object deref.

Comment 8

[Daniel Veditz [:dveditz]]

The above question was for Jim or Olli

Comment 9

[Jim Mathies [:jimm]]

(In reply to comment #7)
> Could the conditions be duplicated with web content? If so that would make this
> a more important security bug (if frames are dead as speculated). If it
> requires user-action in chrome then it's a low-risk bug.

Can we create popup widgets in content that contain text edits? I have a hard time answering this.
 
> The stack in comment 0 shows a frame-poisoned address, so "sg:dos" on branches
> with frame-poisoning. If this can be made to happen in 1.9.1 then it would be a
> potentially exploitable dead object deref.

The frame pointer is definitely bogus:

frame	0x0b6a0d40
mRect	{x=-253853697 y=-253853697 width=-253853697 ...}	nsRect
mContent	0xf0de7fff {mPrimaryFrame=??? }
mStyleContext	0xf0de7fff {mParent=??? mChild=??? mEmptyChild=??? ...}
mParent	0xf0de7fff {mRect={...} mContent=??? mStyleContext=??? ...}
mNextSibling	0xf0de7fff {mRect={...} mContent=??? mStyleContext=??? ...}
mPrevSibling	0xf0de7fff {mRect={...} mContent=??? mStyleContext=??? ...}
mState	17356450751166971903
mOverflow	{mType=4041113599 mDeltas={...} }

I need to dig in a bit and figure out how to debug this. Can we get blocking 2.0 set? This is crash in 4.0 that is easy to reproduce.

Comment 10

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to comment #9)
> (In reply to comment #7)
> > Could the conditions be duplicated with web content? If so that would make this
> > a more important security bug (if frames are dead as speculated). If it
> > requires user-action in chrome then it's a low-risk bug.
> 
> Can we create popup widgets in content that contain text edits?

Yes, we can do it. Content cannot create topmost panel, but can create non-topmost panel.

Comment 11

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I don't think it can without XUL. I don't think this is critical.

Comment 12

[Jim Mathies [:jimm]]

(In reply to comment #11)
> I don't think it can without XUL. I don't think this is critical.

This is an easily triggered crash in the main ui in release builds, caused by simply alt-tabbing away from the bookmarks panel. Regardless of any security issues, this should block 2.0, imho.

(Or am I the only person who can reproduce?)

Comment 13

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Oops, you're right, that was a mistake.

Comment 14

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Mats, can you reproduce this? If not, unassign yourself.

Comment 15

[Mats Palmgren (inactive)]

I can't reproduce it.  Tested m-c nightly and debug builds, Fx 3.6.10 on
both WinXP 32-bit and Win7 64-bit.

Comment 16

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I cannot reproduce either.

Jim, if you can reproduce, can you take this? I'll trade you for a bug of yours that I can reproduce :-).

Comment 17

[Jim Mathies [:jimm]]

Odd I'm  the only one that can reproduce. I'll do some more testing to see what I can find.

Comment 18

[Jim Mathies [:jimm]]

Looking at crash stats it seems I'm pretty much the only person who can reproduce this. So this doesn't need to block release. I'll still do some digging though when I get some time.

http://crash-stats.mozilla.com/query/query?product=Firefox&version=Firefox%3A4.0b6&platform=windows&range_value=1&range_unit=weeks&date=10%2F26%2F2010+19%3A36%3A05&query_search=signature&query_type=contains&query=nsPresShellEventCB%3A%3AHandleEvent&build_id=&process_type=any&hang_type=any&do_query=1

Comment 19

[Jim Mathies [:jimm]]

not able to reproduce in 4.0.