User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b) Gecko/20050204 Firefox/1.0+ Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b) Gecko/20050204 Firefox/1.0+ chance of crash when scrolling on this page, only with smooth scrolling enabled. Reproducible: Sometimes Steps to Reproduce: 1. With the latest Beast build, create a new profile. 2. Set Tools > Options > Advanced to use Smooth Scrolling. 3. Go to http://www.arellanes.com/wordpress/index.php?m=200307 4. Position the mouse pointer so it will be over the main article (the white background) not the magnolia background that's to the left and right of the main article. 5. Whilst the page is loading & rendering, use the mouse-wheel to keep scrolling up & down really quickly. It doesn't matter if you don't scroll very far into the page, as long as whilst it's rendering the page is moving up and down a lot. If this doesn't work, try clearing the cache of your new profile and following steps 3-5 again. I get a 50% chance of a crash when following the above steps. I use a MS Intellimouse 4 which has a mouse-wheel that is properly analogue. ie: it's not 'notched' like othermice. I don't know if this exacerbates the problem. I also have a relatively slow connection (64kbps up, 300kbps down) - don't know if this makes the crash more likely either. Actual Results: Firefox can crash Expected Results: Firefox shouldn't crash Win2k SP4 With Intellipointer 5.2 drivers for MS Intellimouse 4.0a The moouse wheel isn't notched - it is totally smooth. Reproducing the crash happend 50% of the time with a mouse like this. The bug appears to be harder to reproduce if you don't have a smooth mouse wheel. Could this be a bug with the mouse drivers rather than firefox's fault? Talkback IDs: TB3493149K, 3507089 Forum thread: http://forums.mozillazine.org/viewtopic.php?t=212735
Version: unspecified → Trunk
I confirm, not always possible to reproduce here. I guess it is triggered when scrolling the article's div. The article's scrollbars are not always visible, sometimes multiple reloads are needed to 'enable' the article's scrollbars.
Talkback ID 3507089: nsScrollPortView::Paint [c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Clobber/mozilla/view/src/nsScrollPortView.cpp, line 537] nsAppStartup::Init [c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Clobber/mozilla/toolkit/components/startup/src/nsAppStartup.cpp, line 102] main [c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Clobber/mozilla/browser/app/nsBrowserApp.cpp, line 60] kernel32.dll + 0x16d4f (0x7c816d4f) Talkback ID TB3493149K: nsScrollPortView::IncrementalScroll [c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Clobber/mozilla/view/src/nsScrollPortView.cpp, line 705] nsAppStartup::Run [c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Clobber/mozilla/toolkit/components/startup/src/nsAppStartup.cpp, line 146] main [c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Clobber/mozilla/browser/app/nsBrowserApp.cpp, line 60] KERNEL32.DLL + 0x2893d (0x7c59893d)
Summary: chance of crash when scrolling on this page, only with smooth scrolling enabled → chance of crash [@ nsScrollPortView::IncrementalScroll][@ nsScrollPortView::Paint] when scrolling on this page, only with smooth scrolling enabled
Assignee: firefox → roc
Component: General → Layout: View Rendering
Product: Firefox → Core
QA Contact: general → ian
I've managed to crash now also. Talkback ID: TB3534207E I crashed with a 20050120 trunk nightly build. I have succeeded to crash two times now on the second try. With a 20050119 trunk build I was not able to crash yet after 5 tries. If someone else (reporter?) can confirm this observation, that would be nice. So perhaps this could be a regression from bug 244366?
I'd be glad to test with a 20050119 build but ftp.mozilla.org/pub/mozilla.org/firefox/nightly/ only seems to go back as far as 20050122
Steve, you can download older builds here: http://archive.mozilla.org/pub/firefox/nightly/ http://archive.mozilla.org/pub/firefox/nightly/2005-01-19-16-trunk/
2005-01-19-16-trunk does not crash when following steps to reproduce. 2005-01-20-11-trunk does crash when following steps to reproduce. Added keyword regression
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b) Gecko/20050206 the page is longer than 16000 px, last div I see correctly is mentioning Cory Doctorow, then garbage repeats.
Can people reproduce this with keyboard scrolling too? Or just mousewheel? I've been trying to reproduce, with minimal success...
To clarify, I have no mousewheel, hence the question about keyboard scrolling.
Yes, I am able to get firefox to crash as described above just using the arrow keys, although it seems to rarely happen first time. You might also have to left click once on the white background before holding down the down-arrow whilst the page is loading/rendering.
Created attachment 173820 [details] [diff] [review] Possible patch? OK, I still can't reproduce this... can someone seeing the bug try this patch and let me know whether it helps?
I'm afraid I'm not able to test the patch, thus far :(. I can't get my own builds - debug or non-debug - to crash, before I've applied the patch.
A kind soul in #firefox has said they will build me a version of firefox with this patch applied. Once they have I will test to see if it has fixed the crash problem. Hopefully this will only take a day or two.
Comment on attachment 173820 [details] [diff] [review] Possible patch? OK. In the interests of getting this in 1.8b1, asking for review, even though it's not confirmed that this fixes the crash. I do think this is a reasonable thing to do in general.
14 years ago
Comment on attachment 173820 [details] [diff] [review] Possible patch? Requesting approval for 1.8b1... This _should_ fix the crash in this bug, I think... The patch is pretty low-risk.
Attachment #173820 - Flags: approval1.8b?
Comment on attachment 173820 [details] [diff] [review] Possible patch? a=caillon for 1.8b
Attachment #173820 - Flags: approval1.8b? → approval1.8b+
14 years ago
Assignee: roc → bzbarsky
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P1
Target Milestone: --- → mozilla1.8beta1
Patch checked in. I'm going to mark this fixed (for 1.8b1), but could people please test tomorrow's nightlies and reopen if this still crashes?
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
I've been testing with a beast build that has this patch applied and can't get it to crash anymore.
Created attachment 174607 [details] [diff] [review] Additional patch So... the "nested scroll" assert triggers on the testcase in bug 281355. So I guess it's safer to do this instead...
Checked in the additional patch for 1.8b2
Crash Signature: [@ nsScrollPortView::IncrementalScroll] [@ nsScrollPortView::Paint]
You need to log in before you can comment on or make changes to this bug.