207781 - M17 FF10PR1 [@ nsEventStateManager::ForceViewUpdate] Crash if I scroll the page while keeping the cursor on the link

Status: VERIFIED FIXED

(Core :: Layout, defect, P1)

Description

[greg.bugnon]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030526 Mozilla Firebird/0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030526 Mozilla Firebird/0.6

Whenever I click a link (with the left one or the middle one), don't move the
cursor, and then scroll with mouse wheel there is a systematic crash (memory
can't be read...) 

Posted on YaBBSE but the answer was: 
"This is not a YaBB SE bug.  It may be a bug in the template.
I think it's in Firebird."


Reproducible: Always

Steps to Reproduce:
1.Move cursor on a link within the board
2.Click on it, and let the cursor on it
3.Scroll with your mouse wheel

Actual Results:  
Memory can't be read - Mozilla crash


Application Violation in gklayout.dll

Comment 1

[Kai Lahmann (is there, where MNG is)]

can you give us a talkback ID?

Comment 2

[greg.bugnon]

I just reproduced it with latest Mozilla 20030531.
Here it is: TB20615121Z

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Incident ID 20615121
Stack Signature 	0x00000000 d2f68eb5
Email Address 	
Product ID 	MozillaTrunk
Build ID 	2003053108
Trigger Time 	2003-05-31 12:11:04
Platform 	Win32
Operating System 	Windows NT 5.0 build 2195
Module 	
URL visited 	http://www.skullknight.net/yabbse
User Comments 	
Trigger Reason 	Access violation
Source File Name 	
Trigger Line No. 	
Stack Trace 	
0x00000000
nsEventStateManager::ForceViewUpdate
[c:/builds/seamonkey/mozilla/content/events/src/nsEventStateManager.cpp, line 4539]
nsEventStateManager::DoWheelScroll
[c:/builds/seamonkey/mozilla/content/events/src/nsEventStateManager.cpp, line 1765]
nsEventStateManager::PostHandleEvent
[c:/builds/seamonkey/mozilla/content/events/src/nsEventStateManager.cpp, line 2085]
PresShell::HandleEventInternal
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp, line 6433]
PresShell::HandleEvent
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp, line 6317]
nsViewManager::HandleEvent
[c:/builds/seamonkey/mozilla/view/src/nsViewManager.cpp, line 2314]
nsView::HandleEvent [c:/builds/seamonkey/mozilla/view/src/nsView.cpp, line 308]
nsViewManager::DispatchEvent
[c:/builds/seamonkey/mozilla/view/src/nsViewManager.cpp, line 2050]
HandleEvent [c:/builds/seamonkey/mozilla/view/src/nsView.cpp, line 82]
nsWindow::DispatchEvent
[c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 1058]
nsWindow::DispatchWindowEvent
[c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 1075]
nsWindow::ProcessMessage
[c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 4580]
nsWindow::ProcessMessage
[c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 4556]
nsWindow::WindowProc
[c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 1338]
USER32.dll + 0x2a244 (0x77e2a244)
USER32.dll + 0x45e5 (0x77e045e5)
USER32.dll + 0xa792 (0x77e0a792)
nsAppShellService::Run
[c:/builds/seamonkey/mozilla/xpfe/appshell/src/nsAppShellService.cpp, line 479]
main1 [c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1284]
main [c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1650]
WinMain [c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1672]
WinMainCRTStartup()
KERNEL32.dll + 0x2847c (0x77e9847c) 

Comment 4

[Olivier Cahagne]

to make sure someone else than reporter face this, I crashed with Firebird
20030529 on Win2k: TB20617361Z.

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

That stack didn't have useful information in it (everything said
"MozillaFirebird.exe").

Comment 6

[Andrew Schultz]

worksforme with Mozilla linux trunk 20030530 and Firebird CVS/trunk

Comment 7

[Olivier Cahagne]

crashed with Mozilla 2003060108 on Win2k: TB20650659M.

Comment 8

[greg.bugnon]

I just wanted to know if it was useful to post more of these talkback IDs
thanks.

Comment 9

[Olivier Cahagne]

greg, no as I think we have stack and recent TB IDs. Marking NEW btw as I didn't
find dupes.

Comment 10

[greg.bugnon]

ok, thanks for the answer :)
So just to make sure it is not OS dependant, I could as well reproduce the bug
on a Linux system: On Mandrake 9.1, both embeded Mozilla and Galeon did crash
the same way, all browsers'windows instantaneously disapeared. The same happens
with latest builds of Mozilla, but I couldn't test the 20030530 build Andrew had
mentioned.
 

Comment 11

[Olivier Cahagne]

wfm using Firebird 20030626 on WinXP.

Comment 12

[Scott Gifford]

I can't reproduce this on Linux with FireBird 20030817.

Comment 13

[greg.bugnon]

I realize this bug is not a big one, but since I got caught once again and that
it crashed all my windows.. well I just wanted to make sure the procedure I gave
was right ;>

Steps to Reproduce:
1.Move cursor on a link within the board
2.Left-Click on it, and keep the button pressed!
3.Scroll with your mouse wheel

same issue with the middle-button/scroll
always the same access violation in GKLAYOUT.DLL
I've tested it with the most recent builds as well on Win2k and WinXP and it's
always the same thing.

Comment 14

[timeless]

   Incident ID 24611551
    Build ID   2003102004

nsEventStateManager::ForceViewUpdate
[c:/builds/seamonkey/mozilla/content/events/src/nsEventStateManager.cpp, line 4483]
nsEventStateManager::DoWheelScroll
[c:/builds/seamonkey/mozilla/content/events/src/nsEventStateManager.cpp, line 1727]
nsEventStateManager::PostHandleEvent

My bet was that aView was null:

4474 bryner          1.108 void nsEventStateManager::ForceViewUpdate(nsIView* aView)
4475                       {
4479 roc+            1.452   nsIViewManager* vm = aView->GetViewManager();
4480                         if (vm) {
4483 kmcclusk        1.116     vm->ForceUpdate();

Except that doesn't work: nsEventStateManager::DoWheelScroll
1724 bryner       1.294       if (focusView)
1725                            ForceViewUpdate(focusView);

Comment 15

[Neil Paris]

Still crashes Moz 1.7 Beta, Slackware-Current: Mozilla/5.0 (X11; U; Linux i686;
en-US; rv:1.7b) Gecko/20040316

Talkback ID is TB11329E (I don't know the relevance of it, but its there)
Captured at 04/03/04 at 01:16 PM

Comment 16

[Adam Hauner]

Attachment: stack of 2004041408 build crash

Comment 17

[Marco]

i got something like this on http://www.gocciaditenebra.com/download.php.
In this page if i click on a wallpaper preview image, i open a popup window with
the wallpaper within. If i close the popup, and i scroll up and down the frame
(the one with the preview), and the mouse cursor is over the image that i
clicked previously, the browser crash and close itself.

Comment 18

[Jay Patel [:jay]]

Adding M17rc1 to summary for tracking...this is a topcrash for Mozilla 1.7 RC1.
 Here's the latest from Talkback for M17rc1:

     Count   Offset    Real Signature
[ 13   nsEventStateManager::ForceViewUpdate f2d78591 -
nsEventStateManager::ForceViewUpdate ]
 
     Crash date range: 22-APR-04 to 25-APR-04
     Min/Max Seconds since last crash: 22 - 75571
     Min/Max Runtime: 388 - 155956
 
     Count   Platform List 
     13   [Windows NT 5.1 build 2600]   
 
     Count   Build Id List 
     13   2004042109
 
     No of Unique Users         4
 
 Stack trace(Frame) 

	 nsEventStateManager::ForceViewUpdate
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/content/events/src/nsEventStateManager.cpp
 line 4393] 
	 nsEventStateManager::DoWheelScroll
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/content/events/src/nsEventStateManager.cpp
 line 1680] 
	 nsEventStateManager::PostHandleEvent
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/content/events/src/nsEventStateManager.cpp
 line 1985] 
	 PresShell::HandleEventInternal
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsPresShell.cpp
 line 6092] 
	 PresShell::HandleEvent
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsPresShell.cpp
 line 5962] 
	 nsViewManager::HandleEvent
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/view/src/nsViewManager.cpp
 line 2285] 
	 nsViewManager::DispatchEvent
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/view/src/nsViewManager.cpp
 line 2029] 
	 HandleEvent
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/view/src/nsView.cpp 
line 79] 
	 nsWindow::DispatchEvent
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp
 line 1071] 
	 nsWindow::DispatchWindowEvent
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp
 line 1088] 
	 nsWindow::ProcessMessage
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp
 line 4649] 
	 nsWindow::ProcessMessage
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp
 line 4626] 
	 nsWindow::WindowProc
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp
 line 1350] 
	 USER32.dll + 0x3a50 (0x77d43a50)  
	 USER32.dll + 0x3b1f (0x77d43b1f)  
	 USER32.dll + 0x3d79 (0x77d43d79)  
	 USER32.dll + 0x3ddf (0x77d43ddf)  
	 nsAppShellService::Run
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/xpfe/appshell/src/nsAppShellService.cpp
 line 524] 
	 main1
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/xpfe/bootstrap/nsAppRunner.cpp
 line 1313] 
	 main
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/xpfe/bootstrap/nsAppRunner.cpp
 line 1783] 
	 WinMain
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/xpfe/bootstrap/nsAppRunner.cpp
 line 1809] 
	 WinMainCRTStartup()  
	 kernel32.dll + 0x214c7 (0x77e814c7)   
 
     (30377)	URL: http://external.pcc.jp/biso
     (30377)	Comments: Clicking enter at the site
 
====================================================================================================
     Count   Offset    Real Signature
[ 1   nsEventStateManager::ForceViewUpdate 631793a8 -
nsEventStateManager::ForceViewUpdate ]
 
     Crash date range: 25-APR-04 to 25-APR-04
     Min/Max Seconds since last crash: 14442 - 14442
     Min/Max Runtime: 15830 - 15830
 
     Count   Platform List 
     1   [Windows 98 4.90 build 73010104]   
 
     Count   Build Id List 
     1   2004042109
 
     No of Unique Users         1
 
 Stack trace(Frame) 

	 nsEventStateManager::ForceViewUpdate
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/content/events/src/nsEventStateManager.cpp
 line 4395] 
	 nsEventStateManager::DoWheelScroll
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/content/events/src/nsEventStateManager.cpp
 line 1680] 
	 nsEventStateManager::PostHandleEvent
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/content/events/src/nsEventStateManager.cpp
 line 1985] 
	 PresShell::HandleEventInternal
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsPresShell.cpp
 line 6092] 
	 PresShell::HandleEvent
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsPresShell.cpp
 line 5962] 
	 nsViewManager::HandleEvent
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/view/src/nsViewManager.cpp
 line 2285] 
	 nsViewManager::DispatchEvent
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/view/src/nsViewManager.cpp
 line 2029] 
	 HandleEvent
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/view/src/nsView.cpp 
line 79] 
	 nsWindow::DispatchEvent
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp
 line 1071] 
	 nsWindow::DispatchWindowEvent
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp
 line 1088] 
	 nsWindow::ProcessMessage
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp
 line 4649] 
	 nsWindow::ProcessMessage
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp
 line 4626] 
	 nsWindow::WindowProc
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp
 line 1350] 
	 KERNEL32.DLL + 0x3613 (0xbff63613)  
	 KERNEL32.DLL + 0x248f7 (0xbff848f7)  
	 0x00658b62  
	 0x00058f64   
 
     (29759)	URL: http://www.all4you.dk/FreewareWorld/links.php?action=newlinks
     (29759)	Comments: scrolling a page on the first tab while a page in a new
tab was being loaded

Comment 19

[Jay Patel [:jay]]

Looking at timeless's comment #14, would a simple null check be enough to fix
this crash?  If we can find a way to reproduce this, maybe someone can try out a
simple patch.

Comment 20

[Jay Patel [:jay]]

Looking at timeless's comment #14, would a simple null check be enough to fix
this crash?

I've been able to easily reproduce this with the reports url and steps.  Just go
to http://www.skullknight.net/yabbse and left-click and hold the mouse button
over a link and then try scrolling with the mouse wheel...boom!

There are quite a few of these crashes with Mozilla 1.7beta and rc1 so a fix for
this would be nice for 1.7 final.

Comment 21

[Andrew Schultz]

Attachment: testcase

This testcase crashes linux trunk 2004051107, although I can't get it to happen
consistently, maybe 1 out of 3 times.

Click the link and hold the click while scrolling with the mousewheel. 
Sometimes it seems to help if you move the mouse a little bit (a pixel or two),
but I can't really tell for sure.

Comment 22

[Andrew Schultz]

gdb says vm is 0x1 (as is aView->mViewManager)

valgrind sees this:
Invalid read of size 4
 nsIView::GetViewManager() const (nsIView.h:160)
 nsEventStateManager::DoScrollText() (nsEventStateManager.cpp:1775)
 nsEventStateManager::PostHandleEvent() (nsEventStateManager.cpp:2060)
 PresShell::HandleEventInternal() (nsPresShell.cpp:6124)
 PresShell::HandleEvent() (nsPresShell.cpp:5965)
 nsViewManager::HandleEvent() (nsViewManager.cpp:2197)
 nsViewManager::DispatchEvent() (nsViewManager.cpp:1939)
 HandleEvent() (nsView.cpp:76)
Address 0x780913A4 is 4 bytes inside a block of size 84 free'd
 operator delete() (vg_replace_malloc.c:134)
 nsView::operator delete() (nsView.h:75)
 nsView::~nsView() (nsView.cpp:157)
 nsIView::Destroy() (nsView.cpp:241)
 nsFrame::Destroy() (nsFrame.cpp:643)
 nsSplittableFrame::Destroy() (nsSplittableFrame.cpp:71)
 nsContainerFrame::Destroy() (nsContainerFrame.cpp:170)
 nsPositionedInlineFrame::Destroy() (nsInlineFrame.cpp:1103)

Comment 23

[Jay Patel [:jay]]

Andrew's testcase doesn't crash for me on Windows.  I've been trying to narrow
down a simpler testcase with the yabbse source, but no luck.  I wonder if it's
due to the many <b /> tags?

We should probably find some one to assign this to.

Comment 24

[Jay Patel [:jay]]

Andrew's testcase doesn't crash for me on Windows.  I've been trying to narrow
down a simpler testcase with the yabbse source, but no luck.  I wonder if it's
due to the many <b /> tags?

We should probably find some one to assign this to.

Comment 25

[greg.bugnon]

 Another YaBBSE board is also giving the same error.
 It seems like only the boards wich have their links going down when mouse is
over them do crash
 
 You can test with this board:
 http://www.thehawks.org/hawks/forum/
 
 You don't need to register the forum to make it crash ;)
 just test with the "Forgot password?" or "YaBBSE" last links, but first you'll
need to resize your window so that it becomes smaller than actual login webpage
size.
 Inside the board its stil crashing of course. 
 
 The weird thing is that the first three links of this particular page don't
make it crash for me ("Login", "Register" and "-here-" and the logo) if
smoothscrolling is activated.
 If it's not, all of them make it crash.  

 I tested this on Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040207
Firefox/0.8

Comment 26

[greg.bugnon]

>  The weird thing is that the first three links of this particular page don't
> make it crash for me ("Login", "Register" and "-here-" and the logo) if
> smoothscrolling is activated.
>  If it's not, all of them make it crash.  

Forget my statement there, in fact it's still crashing w smoothscrolling on, but
a lot less frequently. especially if you take your time doing it: the link going
down, with the "dot box" around it and then scrolling down.

Comment 27

[Walter K.]

This crash happens in Firefox as well. It happens to me at
http://gemal.dk/mozilla/blogupdates.html - Blogupdates site.
Steps to reproduce:
- Hover over Updated column. A div will pop up.
- Left-click on the link in the div and hold.
- Try to scroll with mouse wheel.
- boom

Comment 28

[Jay Patel [:jay]]

Updating summary with M17rc2.  This is still crashing for me with Mozilla 1.7
rc2 (even though it has not shown up in the top 20 crash list yet).

Since we have a reproducible testcase, it would still be nice to get a fix for 1.7.

Comment 29

[Asa Dotzler [:asa]]

not going to block on this but we'd certainly consider a reviewed patch.

Comment 30

[Jay Patel [:jay]]

Still around with Mozilla 1.7 rc3.

Comment 31

[Blake Ross]

-> dbaron

Comment 32

[Jay Patel [:jay]]

Just updating summary with M17 and FF09x to cover the latest releases that are
crashing.  There is plenty of Talkback data and one poor guy seems to be
crashing everytime he's at http://www.livejournal.com/.

For more crashes, see:
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=1&searchby=stacksig&match=contains&searchfor=nsEventStateManager%3A%3AForceViewUpdate&vendor=All&product=All&platform=All&buildid=&sdate=&stime=00%3A00%3A00&edate=&etime=23%3A59%3A59

Comment 33

[Nathan Strom]

See bug 254890 (which seems to be a dup of this bug) for a simple testcase
exhibiting this crash.

Comment 34

[Frank Wein [:mcsmurf]]

*** Bug 254890 has been marked as a duplicate of this bug. ***

Comment 35

[Anonym]

I got the same Problem. 
(as u can see on duplicate:  http://bugzilla.mozilla.org/show_bug.cgi?id=254890)
The CSS:
A:hover { POSITION: relative; TOP: 1.5px; LEFT: 1.5px; }
is the Problem.

I got 2 Webpages, that are near the same. On the one with the hover above it
crashes, on the other with this hover: 
A:hover {color: #000000;text-decoration:none;}
it doesnt crash.

Comment 36

[Frank Wein [:mcsmurf]]

*** Bug 259785 has been marked as a duplicate of this bug. ***

Comment 37

[Olivier Cahagne]

*** Bug 261914 has been marked as a duplicate of this bug. ***

Comment 38

[Son Le]

Attachment: reget focusView since it may have changed

The focusView may have changed from the time it was fetched to the time it is
actually used. The main culprit here is the GenerateMouseEnterExit() call.

This patch re-obtains the focusView just prior to the ForceViewUpdate() so we
can get a valid nsIView. Tested against the testcase attached to bug 254890.

Comment 39

[Boris Zbarsky [:bzbarsky]]

Aren't you calling CallQI on something that may have been deleted?  So it could
randomly crash anyway?

Note that on trunk this code was removed by the patch that finally landed for
bug 20022.  So this is very much branch-only, if that patch fixes it.

Comment 40

[Son Le]

I'm not sure I follow. sv should still be valid when CallQI is made and
forceView is checked prior to calling ForceViewUpdate(). 

I don't see where it could crash unless CallQI does not return a null if the
nsIView doesn't exist. In that case a simple forceView = nsnull should be added. 

Comment 41

[Boris Zbarsky [:bzbarsky]]

> sv should still be valid when CallQI is made

Why?  Isn't there an event that gets processed in between?  That event could
have caused "sv" to go away...

Note that "sv" is not reference counted or anything, so just because you have a
pointer to it doesn't mean the object exists.

Comment 42

[Son Le]

Ahh... in that case, this entire method should be re-written. And which it has.

All I can say is this patch works on the testcase and does provide a little bit
of protection. Would calling the GenerateMouseEnterExit() earlier be better?
(ie. before the current focus frame is obtained)

Comment 43

[Boris Zbarsky [:bzbarsky]]

> (ie. before the current focus frame is obtained)

Can't do that, since we want to restrict to the case when sv is non-null, and we
get sv off the focus frame.

It may be better to, in the case when we call GenerateMouseEnterExit, reget all
of focusFrame, svp, focusView, and sv....

Comment 44

[Son Le]

Attachment: reget focusFrame, svp, focusView, and sv

New proposed patch. A hack to reget focusFrame, svp, focusView, and sv for
aviary branch only as the landing for bug 20022 has significantly changed the
trunk.

I'm not too sure if this patch meets quality standards as it is basically a cut
and paste of the previous code to get focusFrame, svp, focusView, and sv, but
since the trunk code has changed, any meaningful work here would be lost I
presume.

Tested successfully against testcase of bug 207781.

Comment 45

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 160998 [details] [diff] [review]
reget focusFrame, svp, focusView, and sv

r=bzbarsy, I guess.  Using aTargetFrame after the event dispatch is still bad,
but I guess that's not so easy to fix...

Comment 46

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 160998 [details] [diff] [review]
reget focusFrame, svp, focusView, and sv

This is a branch-only patch to fix this crasher (which should be fixed on trunk
already).  It ought to be reasonably safe, I think....

Comment 47

[Asa Dotzler [:asa]]

Comment on attachment 160998 [details] [diff] [review]
reget focusFrame, svp, focusView, and sv

a=asa for aviary and 1.7 checkin.

Comment 48

[Boris Zbarsky [:bzbarsky]]

Fixed on branches (and wasn't an issue on trunk, apparently).

Comment 49

[Son Le]

Just confirming that the trunk does not crash with bug 254890's testcase.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a5) Gecko/20041008
Firefox/0.9.1+

Comment 50

[Jay Patel [:jay]]

v.fixed per Talkback. This crash is gone in the latest Mozilla 1.7.5 and Firefox
1.0 crash data.

Comment 51

[Adam Guthrie]

*** Bug 307963 has been marked as a duplicate of this bug. ***