[Webkit-unassigned] [Bug 12647] 8F32: Help Viewer crashed on clicking link - KHTMLView::viewportMouseReleaseEvent

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Mar 13 13:17:39 PDT 2007


------- Comment #1 from bdakin at apple.com  2007-03-13 13:17 PDT -------
As described above, the crash happens when you search for something, and then
go back from a search page to the previous page. The search page is not a
WebView; I believe it is an NSTableView. All of the other pages are WebViews
which is why this assertion/display problem only happens when going back from
the search view. 

So when the search page comes up, we do not actually navigate away from the
previous page. It gets swizzled away with viewWillMoveToWindow:nil. When the
"back" key is pressed, HelpViewer calls into WebKit with
goToBackForwardItem:item. Which is kind of funny to begin with since this is
not a normal back-forth navigation.

Initially I was suspicious of this call through back-forward, and I tested what
would happen if we did nothing in goToBackForwardItem:item and unconditionally
returned "NO." (Our API indicates that we return NO if the item is not in the
back-forward list, but in reality, we have always unconditionally returned
"YES.") Help Viewer actually did the right thing in that case, which confirmed
my suspicion that it seems the problem is that we are not correctly putting the
view back into the window.

I pulled the branch to look at how things happen differently there, and so far,
any differences are very non-obvious. A lot of the code has been pushed into
WebCore, but the same basic things are happening. In both cases we end up
calling setDocumentView with a cachedView from the page cache, but it works on
the branch and not on TOT. I am currently looking into what has changed with
the cachedView and with the process of setting the document view.

Configure bugmail: http://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

More information about the webkit-unassigned mailing list