Closed Bug 281173 Opened 19 years ago Closed 19 years ago

chance of crash [@ nsScrollPortView::IncrementalScroll][@ nsScrollPortView::Paint] when scrolling on this page, only with smooth scrolling enabled

Categories

(Core :: Web Painting, defect, P1)

x86
Windows 2000
defect

Tracking

()

RESOLVED FIXED
mozilla1.8beta1

People

(Reporter: stevee, Assigned: bzbarsky)

References

()

Details

(Keywords: crash, regression)

Crash Data

Attachments

(2 files)

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
Keywords: crash
Version: unspecified → Trunk
Severity: normal → critical
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
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
Keywords: 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.
Attached patch Possible patch?Splinter Review
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.
Attachment #173820 - Flags: superreview?(roc)
Attachment #173820 - Flags: review?(roc)
Attachment #173820 - Flags: superreview?(roc)
Attachment #173820 - Flags: superreview+
Attachment #173820 - Flags: review?(roc)
Attachment #173820 - Flags: review+
Blocks: 244366
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+
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
Closed: 19 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.
Attached patch Additional patchSplinter Review
So... the "nested scroll" assert triggers on the testcase in bug 281355.  So I
guess it's safer to do this instead...
Attachment #174607 - Flags: superreview?(roc)
Attachment #174607 - Flags: review?(roc)
Attachment #174607 - Flags: superreview?(roc)
Attachment #174607 - Flags: superreview+
Attachment #174607 - Flags: review?(roc)
Attachment #174607 - Flags: review+
Checked in the additional patch for 1.8b2
Crash Signature: [@ nsScrollPortView::IncrementalScroll] [@ nsScrollPortView::Paint]
Component: Layout: View Rendering → Layout: Web Painting
You need to log in before you can comment on or make changes to this bug.