[Webkit-unassigned] [Bug 56055] Hook up new AppKit autocorrection UI with WK2.
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Tue Mar 22 14:33:48 PDT 2011
https://bugs.webkit.org/show_bug.cgi?id=56055
--- Comment #9 from Jia Pu <jpu at apple.com> 2011-03-22 14:33:49 PST ---
(In reply to comment #7)
> (In reply to comment #6)
> > (From update of attachment 86252 [details] [details])
> > View in context: https://bugs.webkit.org/attachment.cgi?id=86252&action=review
>
> > > Source/WebKit2/UIProcess/WebPageProxy.cpp:2699
> > > +#if PLATFORM(MAC) && !defined(BUILDING_ON_SNOW_LEOPARD)
> > > + dismissCorrectionPanel(ReasonForDismissingCorrectionPanelIgnored);
> > > +#endif
> >
> > This change seems wrong; we are quite early in the loading process at the point where we set a pending API request URL, and that’s not the right time to take down the correction panel. And most loads don’t have a pending API request URL, such as clicks on links.
>
>
> Do you have a recommended spot to dismiss visible correction panel before loading a new page? In WK1, I don't actually need to do anything. In WK1, reloading a page will always dealloc NSView, hence dismiss the panel. However, in WK2, it doesn't seem always to be the case. Specifically when reloading another page when existing page is OpenSource/Source/WebCore/manual-tests/autocorrection/autocorrection-in-iframe.html.
I took a closer look at this issue. The reason that we don't need to explicitly dismiss correction panel when loading a new page in WK1 is that there's code in AppKit to take care this. Whenever [WebFrameView _setDocumentView:] is called, which calls [NSScrollView setDocumentView:], AppKit find the WebView to which WebFrameView belongs, and removes the correction panel if it exists. This is rather fragile. So I think we should handle this within WK2. I moved the call to dismissCorrectionPanel() from setPendingAPIRequestURL() to didFinishDocumentLoadForFrame().
--
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
More information about the webkit-unassigned
mailing list