Closed Bug 207781 Opened 21 years ago Closed 20 years ago

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

Categories

(Core :: Layout, defect, P1)

1.7 Branch
x86
All
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: greg.bugnon, Assigned: son.le0)

References

()

Details

(5 keywords)

Crash Data

Attachments

(3 files, 1 obsolete file)

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
can you give us a talkback ID?
Keywords: crash
Severity: normal → critical
I just reproduced it with latest Mozilla 20030531.
Here it is: TB20615121Z
Keywords: stackwanted
Whiteboard: TB20615121Z
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) 
Keywords: stackwanted
Summary: Crash if I scroll the page while keeping the cursor on the link → Crash if I scroll the page while keeping the cursor on the link [@ nsEventStateManager::ForceViewUpdate]
Whiteboard: TB20615121Z
to make sure someone else than reporter face this, I crashed with Firebird
20030529 on Win2k: TB20617361Z.
That stack didn't have useful information in it (everything said
"MozillaFirebird.exe").
worksforme with Mozilla linux trunk 20030530 and Firebird CVS/trunk
crashed with Mozilla 2003060108 on Win2k: TB20650659M.
I just wanted to know if it was useful to post more of these talkback IDs
thanks.
greg, no as I think we have stack and recent TB IDs. Marking NEW btw as I didn't
find dupes.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
 
OS: Windows 2000 → All
wfm using Firebird 20030626 on WinXP.
I can't reproduce this on Linux with FireBird 20030817.
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.
   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);
Keywords: topcrash
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
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.
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
Summary: Crash if I scroll the page while keeping the cursor on the link [@ nsEventStateManager::ForceViewUpdate] → Crash if I scroll the page while keeping the cursor on the link - M17rc1 [@ nsEventStateManager::ForceViewUpdate]
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.
Summary: Crash if I scroll the page while keeping the cursor on the link - M17rc1 [@ nsEventStateManager::ForceViewUpdate] → M17rc1 [@ nsEventStateManager::ForceViewUpdate] Crash if I scroll the page while keeping the cursor on the link
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.
Keywords: topcrashtopcrash+
Flags: blocking1.7?
Attached file 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.
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)
Keywords: testcase
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.
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.
 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
>  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.
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
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.
Summary: M17rc1 [@ nsEventStateManager::ForceViewUpdate] Crash if I scroll the page while keeping the cursor on the link → M17rc2 [@ nsEventStateManager::ForceViewUpdate] Crash if I scroll the page while keeping the cursor on the link
not going to block on this but we'd certainly consider a reviewed patch.
Flags: blocking1.7? → blocking1.7-
Still around with Mozilla 1.7 rc3.
Summary: M17rc2 [@ nsEventStateManager::ForceViewUpdate] Crash if I scroll the page while keeping the cursor on the link → M17rc3 [@ nsEventStateManager::ForceViewUpdate] Crash if I scroll the page while keeping the cursor on the link
-> dbaron
Assignee: core.layout → dbaron
Flags: blocking-aviary1.0+
Priority: -- → P1
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
Summary: M17rc3 [@ nsEventStateManager::ForceViewUpdate] Crash if I scroll the page while keeping the cursor on the link → M17 FF09x [@ nsEventStateManager::ForceViewUpdate] Crash if I scroll the page while keeping the cursor on the link
See bug 254890 (which seems to be a dup of this bug) for a simple testcase
exhibiting this crash.
*** Bug 254890 has been marked as a duplicate of this bug. ***
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.
*** Bug 259785 has been marked as a duplicate of this bug. ***
Flags: blocking1.7-
Summary: M17 FF09x [@ nsEventStateManager::ForceViewUpdate] Crash if I scroll the page while keeping the cursor on the link → M17 FF10PR1 [@ nsEventStateManager::ForceViewUpdate] Crash if I scroll the page while keeping the cursor on the link
*** Bug 261914 has been marked as a duplicate of this bug. ***
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.
Attachment #160882 - Flags: review?(bryner)
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.
Version: Trunk → 1.7 Branch
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. 
> 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.
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)
> (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....
Attachment #160882 - Attachment is obsolete: true
Attachment #160882 - Flags: review?(bryner)
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.
Attachment #160998 - Flags: review?(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...
Attachment #160998 - Flags: superreview?(bryner)
Attachment #160998 - Flags: review?(bzbarsky)
Attachment #160998 - Flags: review+
Attachment #160998 - Flags: superreview?(bryner) → superreview+
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....
Attachment #160998 - Flags: approval1.7.x?
Attachment #160998 - Flags: approval-aviary?
Comment on attachment 160998 [details] [diff] [review]
reget focusFrame, svp, focusView, and sv

a=asa for aviary and 1.7 checkin.
Attachment #160998 - Flags: approval1.7.x?
Attachment #160998 - Flags: approval1.7.x+
Attachment #160998 - Flags: approval-aviary?
Attachment #160998 - Flags: approval-aviary+
Assignee: dbaron → lesx99
Fixed on branches (and wasn't an issue on trunk, apparently).
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
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+
v.fixed per Talkback. This crash is gone in the latest Mozilla 1.7.5 and Firefox
1.0 crash data.
Status: RESOLVED → VERIFIED
*** Bug 307963 has been marked as a duplicate of this bug. ***
Crash Signature: [@ nsEventStateManager::ForceViewUpdate]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: