Summary: | WebKit crash in DOM::NodeImpl::setChanged(bool) | ||
---|---|---|---|
Product: | WebKit | Reporter: | Aron Rosenberg <aron-webkit> |
Component: | WebKit Misc. | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED WORKSFORME | ||
Severity: | Normal | CC: | webkit |
Priority: | P2 | ||
Version: | 418.x | ||
Hardware: | Mac (Intel) | ||
OS: | OS X 10.4 | ||
URL: | http://www.sightspeed.com |
Description
Aron Rosenberg
2007-03-02 14:29:08 PST
(In reply to comment #0) > The WebKit version is the default for 10.4.8 on Intel Mac which I believe is > 419.x - Since this is a randomly occuring customer crash we don't have anyway > of using the CVS or nightly webkits on their end. The 419.x version is the Safari build (as in "2.0.4 (419.3)"). This web page describes how to map the WebKit version with the Safari version: http://developer.apple.com/internet/safari/uamatrix.html If any of your users has found a way to reproduce this issue, a reproducible test case is going to be the fastest path to getting this issue fixed. I would love to be able to get a reproducable scenario, it took us months to finally have somebody properly give us a crash report and then they didn't know exactly what they were doing. I don't know the internals of the WebKit well, but reading the call stack, it seems that the user might have been trying to copy / paste text or something along those lines? Am I right with this guess? (In reply to comment #2) > I would love to be able to get a reproducable scenario, it took us months to > finally have somebody properly give us a crash report and then they didn't know > exactly what they were doing. If any of your users sent a crash report to Apple, the Safari engineers may be able to review similar stacks and provide a count of how many times it was reported, but probably won't have much more information than that. > I don't know the internals of the WebKit well, but reading the call stack, it > seems that the user might have been trying to copy / paste text or something > along those lines? Am I right with this guess? My analysis of the stack trace was that the user clicked on a URL with a hash on it (foo.html#bar), but I'm not sure what the last two method calls do. (I'm not as familiar with the "older" internal WebKit APIs from the Tiger era.) Aron, do the crashes still happen? We have not gotten a report of this in many months - my guess is that Safari 3 fixed the issue (In reply to comment #5) > We have not gotten a report of this in many months - my guess is that Safari 3 > fixed the issue > Aron, thank you for the info! So I resolve the bug as WORSKFORME. |