277923 - Crash on scroll during page load.

Status: RESOLVED FIXED

(Core Graveyard :: Widget: Mac, defect)

Description

[Jasper]

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.

Comment 1

[Jasper]

Attachment: Crash log of the crash

-

Comment 2

[Jasper]

*** Bug 279886 has been marked as a duplicate of this bug. ***

Comment 3

[Miklos Master]

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 imdb.com; morningstar.com and etc.

Comment 4

[Josh Aas]

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?

Comment 5

[Simon Fraser [no longer active]]

I checked in the tab resize stuff on Saturday (1/29), and it only affected
background tabs.

Comment 6

[Kurt Weinschenker]

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...

Comment 7

[Kurt Weinschenker]

Attachment: Same crash, but under Mac OS 10.3.8

Pretty much the same as Jasper's log, but posting because of subtle differences
in 10.3.8 compared to 10.3.6.

Comment 8

[Jasper]

*** Bug 280425 has been marked as a duplicate of this bug. ***

Comment 9

[Simon Fraser [no longer active]]

The scrollbar must be being blown away in the middle of the scroll. Maybe we
need to keep a ref around?

Comment 10

[John Pastor]

Yeah, this happens to me as well.

Comment 11

[Simon Fraser [no longer active]]

Attachment: Testcase

Comment 12

[Josh Aas]

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...

Comment 13

[Simon Fraser [no longer active]]

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.

Comment 14

[Simon Fraser [no longer active]]

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).

Comment 15

[Simon Fraser [no longer active]]

Attachment: Patch to break out of the tracking loop by posting a fake mouse up event

Comment 16

[Mike Pinkerton (not reading bugmail)]

Comment on attachment 179668 [details] [diff] [review]
Patch to break out of the tracking loop by posting a fake mouse up event

r=pink

Comment 17

[Simon Fraser [no longer active]]

Throwing this over to cocoa widget to get approval (since it's outside
mozilla/camino)

Comment 18

[Simon Fraser [no longer active]]

I went ahead and checked this in, since it's Camino-only.

Comment 19

[Mike Pinkerton (not reading bugmail)]

landed on branch for 084