User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:220.127.116.11) Gecko/2009042316 Firefox/3.0.10 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:18.104.22.168) Gecko/2009042316 Firefox/3.0.10 When I scroll the page (entire page, not the embedded pdf) with mouse wheel, the scroll lasts a while. If during that period I click the pdf, Firefox crashes. It has already sent you some reports by itself as I was trying to find out how to reproduce the bug :) . Reproducible: Always Steps to Reproduce: 1. Enter the page with embedded pdf (use Adobe plug-in) 2. Click the page outside the pdf to make sure it has a focus. 3. Scroll the page with mouse wheel 4. While the page is still in motion click the pdf. Actual Results: Firefox Crashes, sends the report and safely restarts restoring all tabs I have had open, and not only them - I have just had it upgrade to 3.0.10 so apart from restoring my tabs, the "Firefox has been updated" also comes in again. Expected Results: Well... nothing visible should have happen - just the focus should have been transferred to the pdf reader plug-in. All additional info has been sent to you by default crash reporting system, I think. It was using my other e-mail address, in domain "poczta.onet.pl" instead of "o2.pl".
Please provide a crash ID: https://developer.mozilla.org/en/How_to_get_a_stacktrace_for_a_bug_report
Here you go: af67d4e9-4c60-404c-a2c4-e893d2090428 2009.04.28 16:38 42e613ca-1ada-41e7-b2d5-54a162090428 2009.04.28 16:37 d5d791ec-8879-4667-a208-4c7362090428 2009.04.28 16:36 43aaabb6-4724-48b6-aef4-61eef2090428 2009.04.28 16:35 d35bd35d-db98-4795-8de6-230332090428 2009.04.28 16:33 502dd2a9-499a-4f29-ac3d-9dd8b2090428 2009.04.28 16:14 d5e4cd98-165c-4e60-aa9c-415842090428 2009.04.28 16:13 c0f3d77b-b922-4961-88ad-92a472090428 2009.04.28 16:12 b5898189-45be-4289-9083-a622b2090428 2009.04.28 16:12 802e1578-0a78-43b4-8931-387122090428 2009.04.28 16:11 all should have sth to do with that bug, but the earlier ones will be more sure. The later ones happened after I submitted the bug, I had the site http://wikidyd.iem.pw.edu.pl/index.cgi/LabKPO/cw5?action=AttachFile&do=view&target=ins5.pdf opened and I opened it again using the link in my submision above so I think it's another bug, but can't provide more info right now. Either way I won't tell you now which are which.
most of your crashes are this: Signature nsScrollPortView::IncrementalScroll() UUID af67d4e9-4c60-404c-a2c4-e893d2090428 Crash Address 0x54 0 xul.dll nsScrollPortView::IncrementalScroll mozilla/view/src/nsScrollPortView.cpp:729 1 xul.dll nsScrollPortView::SmoothScrollAnimationCallback mozilla/view/src/nsScrollPortView.cpp:711 2 xul.dll nsTimerImpl::Fire mozilla/xpcom/threads/nsTimerImpl.cpp:400 3 xul.dll nsTimerEvent::Run mozilla/xpcom/threads/nsTimerImpl.cpp:490 4 xul.dll nsThread::ProcessNextEvent mozilla/xpcom/threads/nsThread.cpp:510 5 xul.dll nsBaseAppShell::Run mozilla/widget/src/xpwidgets/nsBaseAppShell.cpp:170 6 nspr4.dll PR_GetEnv 7 firefox.exe wmain mozilla/toolkit/xre/nsWindowsWMain.cpp:87 8 firefox.exe firefox.exe@0x217f 9 kernel32.dll kernel32.dll@0x17066
also crashing on Minefield: bp-c2095893-8b8a-4a10-9a88-f4a9b2090501 Shiretoko: bp-c257df27-5cce-4b9a-92be-ed50f2090501 nsScrollPortView::IncrementalScroll view/src/nsScrollPortView.cpp:726 nsScrollPortView::AsyncScrollCallback view/src/nsScrollPortView.cpp:709 nsTimerImpl::Fire xpcom/threads/nsTimerImpl.cpp:420 nsTimerEvent::Run xpcom/threads/nsTimerImpl.cpp:512 nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:510
Bug 454872 might have fixed some of the above crashes. I managed to crash a local 1.9.2 debug build though, on Windows XP, with smooth scrolling enabled. Inspecting the data in the debugger the nsWeakView appears alive and healthy and the mView inside too and has a mDeletionObserver that points back at the address of 'thisView' and everything looks good, except that 'mAsyncScroll' is null. http://hg.mozilla.org/releases/mozilla-1.9.2/annotate/tip/view/src/nsScrollPortView.cpp#l841 The only scenario I can think of that would cause that is a nested call to ScrollTo that takes the synchronous path, which deletes and nulls out 'mAsyncScroll'. Could it be that the click shifts focus in a way that causes a scroll-into-view instant scroll request?
FWIW, I'm using Adobe Acrobat 22.214.171.124 PDF plugin. It crashes nearly every time on exit, after just starting, loading the URL (probably just any PDF URL will do), then File->Exit. It's an unrelated crash with only plugin stuff on the stack, inside BiB.DLL.
Created attachment 416005 [details] IncrementalScroll() -> ScrollTo() stack My suspicion in comment 5 was right. nsScrollPortView::ScrollTo Line 243 is the line before "delete mAsyncScroll" in my tree.
I think this bug is what causes the crashes with 0x54 as the address http://crash-stats.mozilla.com/report/list?query_search=signature&query_type=contains&query=IncrementalScroll&date=&range_value=2&range_unit=weeks&do_query=1&signature=nsScrollPortView%3A%3AIncrementalScroll() (although, in my 1.9.2 debug build the offset of mAsyncScroll is 0x58)
Created attachment 416014 [details] [diff] [review] Patch rev. 1 Simple null-check.
Ah, the offset of AsyncScroll::mFrameIndex is 0x54, that's what I should have looked for.
Comment on attachment 416014 [details] [diff] [review] Patch rev. 1 Definitely the right fix for now, but Windows passing WM_MOUSEACTIVATE to us during a call to ::UpdateWindow() is evil evil evil.
Comment on attachment 416014 [details] [diff] [review] Patch rev. 1 Simple null-pointer check that's worth taking for 1.9.2.
Affects linux too, crashes with flash plugin: https://bugzilla.redhat.com/show_bug.cgi?id=546153 bp-27e89591-7aae-4ef4-8d8e-5dadf2091206
Comment on attachment 416014 [details] [diff] [review] Patch rev. 1 a=LegNeato for 126.96.36.199. Please ONLY land this on mozilla-1.9.2 default, as we are still working on 188.8.131.52 on the relbranch
I landed the above patch on 1.9.2 for you: http://hg.mozilla.org/releases/mozilla-1.9.2/rev/2b4ebfc8bfcf It looks like the code is 1.9.2-only -- should this get marked both FIXED and status1.9.2:.5-fixed now?
Thanks. Yes, I'm pretty sure trunk does not have this bug. I should have asked for 1.9.1 or 1.9.0 approval also though. Doing so now...
Comment on attachment 416014 [details] [diff] [review] Patch rev. 1 Approved for 184.108.40.206, a=dveditz for release-drivers
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/4e407af7682f On CVS trunk: Checking in view/src/nsScrollPortView.cpp; /cvsroot/mozilla/view/src/nsScrollPortView.cpp,v <-- nsScrollPortView.cpp new revision: 3.92; previous revision: 3.91
Juan, can you look at this for 1.9.1 and 1.9.2 with your scrollmouse?
Verified fix on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:220.127.116.11) Gecko/20100701 Firefox/3.6.7 (.NET CLR 3.5.30729). no crash.