Closed Bug 277923 Opened 20 years ago Closed 19 years ago

Crash on scroll during page load.


(Core Graveyard :: Widget: Mac, defect)

Not set


(Not tracked)



(Reporter: camino, Assigned: sfraser_bugs)



(Keywords: fixed1.7.7)


(4 files)

Sometimes (very rarely, and not reproducable) Camino will crash when you try to
scroll while a webpage is loading. I have yet to find a way the reproduce it 100%.

I will attach a crash log asap.
Attached file Crash log of the crash
Target Milestone: --- → Camino0.9
*** Bug 279886 has been marked as a duplicate of this bug. ***
Frequent crash on scrolling certain pages with certain content. Repeatable crash
on scrolling certain pages (must be code related to content - no flash, nothing
extra) on; and etc.
Just a thought that crossed my mind...

Could this be a problem with the tab scroll positioning fix that smfr put in
maybe a week ago?
I checked in the tab resize stuff on Saturday (1/29), and it only affected
background tabs.
I've seen this happening as well.  I will examine a few console logs over the
next few days to see if I can lend any further insight.

Otherwise, I'll shut up.  Shutting up...
Pretty much the same as Jasper's log, but posting because of subtle differences
in 10.3.8 compared to 10.3.6.
*** Bug 280425 has been marked as a duplicate of this bug. ***
The scrollbar must be being blown away in the middle of the scroll. Maybe we
need to keep a ref around?
Yeah, this happens to me as well.
Attached file Testcase
0   <<00000000>> 	0x224e534c 0 + 0x224e534c
1   libwidget_mac.dylib   	0x02cade24 -[NativeScrollbarView scroll:] + 0x3c

These are the top two lines of the stack trace. When you initialize a
NativeScrollBarView, it sets itself to receive events with this code:

539   // make ourselves the target of the scroll and set the action message
540   [self setTarget:self];
541   [self setAction:@selector(scroll:)];

The reason we get <<00000000>> for a function address is probably that events
are calling scroll: but the object is already gone and the selector never
resolves... I don't know much more about what is going on at the moment, but I
wanted to point out the code that is probably responsible for the slightly
confusing stack trace.

It seems the reason the testcase works is that when you hold onto the scrollbar
and start sending a chain of events to it, the scrollbar is getting wiped out
from underneath you when the page refreshes. The events can no longer resolves
the target function, and we crash...
As I suspected, the problem here is that the gecko nsNativeScrollbar is blown
away while we're in the middle of a [NSScroller trackKnob:] tracking loop.
Assignee: pinkerton → sfraser_bugs
Hrm, we might have to implement trackKnob: ourselves. I can't find a way to tell
NSScroller to kill the tracking loop (unless I fake a mouseup event or something).
Attachment #179668 - Flags: superreview?(pinkerton)
Attachment #179668 - Flags: review?(joshmoz)
Comment on attachment 179668 [details] [diff] [review]
Patch to break out of the tracking loop by posting a fake mouse up event

Attachment #179668 - Flags: review?(joshmoz) → review+
Attachment #179668 - Flags: superreview?(pinkerton)
Attachment #179668 - Flags: superreview+
Attachment #179668 - Flags: review?(joshmoz)
Attachment #179668 - Flags: review+
Throwing this over to cocoa widget to get approval (since it's outside
Component: General → Widget: Mac
Flags: review?(joshmoz)
Product: Camino → Core
Target Milestone: Camino0.9 → mozilla1.8beta2
Version: unspecified → Trunk
Flags: blocking1.8b2?
I went ahead and checked this in, since it's Camino-only.
Closed: 19 years ago
Flags: blocking1.8b2?
Resolution: --- → FIXED
landed on branch for 084
Keywords: fixed1.7.7
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.