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)
Tracking
()
VERIFIED
FIXED
People
(Reporter: greg.bugnon, Assigned: son.le0)
References
()
Details
(5 keywords)
Crash Data
Attachments
(3 files, 1 obsolete file)
2.42 KB,
text/plain
|
Details | |
329 bytes,
text/html
|
Details | |
2.60 KB,
patch
|
bzbarsky
:
review+
bryner
:
superreview+
asa
:
approval-aviary+
asa
:
approval1.7.5+
|
Details | Diff | Splinter Review |
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
Reporter | ||
Comment 2•21 years ago
|
||
I just reproduced it with latest Mozilla 20030531. Here it is: TB20615121Z
Updated•21 years ago
|
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
Comment 4•21 years ago
|
||
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").
Comment 6•21 years ago
|
||
worksforme with Mozilla linux trunk 20030530 and Firebird CVS/trunk
Comment 7•21 years ago
|
||
crashed with Mozilla 2003060108 on Win2k: TB20650659M.
Reporter | ||
Comment 8•21 years ago
|
||
I just wanted to know if it was useful to post more of these talkback IDs thanks.
Comment 9•21 years ago
|
||
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
Reporter | ||
Comment 10•21 years ago
|
||
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
Comment 11•21 years ago
|
||
wfm using Firebird 20030626 on WinXP.
Comment 12•21 years ago
|
||
I can't reproduce this on Linux with FireBird 20030817.
Reporter | ||
Comment 13•21 years ago
|
||
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•21 years ago
|
||
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
Comment 15•20 years ago
|
||
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•20 years ago
|
||
Comment 17•20 years ago
|
||
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•20 years ago
|
||
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]
Comment 19•20 years ago
|
||
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
Comment 20•20 years ago
|
||
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.
Updated•20 years ago
|
Flags: blocking1.7?
Comment 21•20 years ago
|
||
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•20 years ago
|
||
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
Comment 23•20 years ago
|
||
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•20 years ago
|
||
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.
Reporter | ||
Comment 25•20 years ago
|
||
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
Reporter | ||
Comment 26•20 years ago
|
||
> 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•20 years ago
|
||
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•20 years ago
|
||
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
Comment 29•20 years ago
|
||
not going to block on this but we'd certainly consider a reviewed patch.
Flags: blocking1.7? → blocking1.7-
Comment 30•20 years ago
|
||
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
Comment 31•20 years ago
|
||
-> dbaron
Assignee: core.layout → dbaron
Flags: blocking-aviary1.0+
Priority: -- → P1
Comment 32•20 years ago
|
||
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
Comment 33•20 years ago
|
||
See bug 254890 (which seems to be a dup of this bug) for a simple testcase exhibiting this crash.
Comment 34•20 years ago
|
||
*** Bug 254890 has been marked as a duplicate of this bug. ***
Comment 35•20 years ago
|
||
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•20 years ago
|
||
*** Bug 259785 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Flags: blocking1.7-
Updated•20 years ago
|
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
Comment 37•20 years ago
|
||
*** Bug 261914 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 38•20 years ago
|
||
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)
Comment 39•20 years ago
|
||
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
Assignee | ||
Comment 40•20 years ago
|
||
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•20 years ago
|
||
> 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.
Assignee | ||
Comment 42•20 years ago
|
||
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•20 years ago
|
||
> (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)
Assignee | ||
Comment 44•20 years ago
|
||
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 45•20 years ago
|
||
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+
Updated•20 years ago
|
Attachment #160998 -
Flags: superreview?(bryner) → superreview+
Comment 46•20 years ago
|
||
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 47•20 years ago
|
||
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+
Updated•20 years ago
|
Assignee: dbaron → lesx99
Comment 48•20 years ago
|
||
Fixed on branches (and wasn't an issue on trunk, apparently).
Status: NEW → RESOLVED
Closed: 20 years ago
Keywords: fixed-aviary1.0,
fixed1.7.x
Resolution: --- → FIXED
Assignee | ||
Comment 49•20 years ago
|
||
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•19 years ago
|
||
v.fixed per Talkback. This crash is gone in the latest Mozilla 1.7.5 and Firefox 1.0 crash data.
Status: RESOLVED → VERIFIED
Comment 51•19 years ago
|
||
*** Bug 307963 has been marked as a duplicate of this bug. ***
Updated•13 years ago
|
Crash Signature: [@ nsEventStateManager::ForceViewUpdate]
You need to log in
before you can comment on or make changes to this bug.
Description
•