RESOLVED FIXED 42236
[Chromium] Replace ChromiumBridge::widgetSetCursor with ChromeClient::setCursor
https://bugs.webkit.org/show_bug.cgi?id=42236
Summary [Chromium] Replace ChromiumBridge::widgetSetCursor with ChromeClient::setCursor
Darin Fisher (:fishd, Google)
Reported 2010-07-13 23:51:56 PDT
Replace ChromiumBridge::widgetSetCursor with ChromeClient::setCursor
Attachments
Patch (5.97 KB, patch)
2011-01-14 16:42 PST, Adam Klein
no flags
Patch (5.63 KB, patch)
2011-01-15 13:37 PST, Adam Klein
no flags
Adam Klein
Comment 1 2011-01-14 14:32:19 PST
Request for some clarification: the only call to ChromiumBridge::widgetSetCursor() is in Widget::setCursor() (WidgetChromium.cpp). But Widget itself doesn't have easy access to a ChromeClient. Is the intention just to move ChromiumBridge's logic up into WidgetChromium (it involves using pseudo-RTTI and static_cast<FrameView*>(this)), or did you have something else in mind?
Adam Klein
Comment 2 2011-01-14 14:39:40 PST
Oh, I see that Widget actually has a nice root() method which does this for me. Using that seems to be the way to go.
Darin Fisher (:fishd, Google)
Comment 3 2011-01-14 15:33:15 PST
Yes, you can see in ChromiumBridge.cpp how we get to the ChromeClientImpl class given only a Widget. It used to be the case that ChromeClient did not have the setCursor method; however, it was added for WebKit2 (in r63339). We can use ChromeClient from our WidgetChromium implementation to reach the new setCursor method. We could not previously cast to ChromeClientImpl from WidgetChromium because WebCore cannot depend directly on code in WebKit.
Adam Klein
Comment 4 2011-01-14 16:42:45 PST
Darin Fisher (:fishd, Google)
Comment 5 2011-01-14 16:57:26 PST
Comment on attachment 79024 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=79024&action=review > Source/WebCore/platform/chromium/WidgetChromium.cpp:63 > + FrameView* view; Sorry, I just realized there is a much simpler way to achieve this! HostWindow also gained a setCursor method, and you can get the HostWindow from a Widget's parent ScrollView. That will dramatically simplify this code.
Darin Fisher (:fishd, Google)
Comment 6 2011-01-14 16:58:15 PST
The HostWindow approach makes more sense too because there is a "rule" that WebCore/platform/ should not depend back onto code outside of WebCore/platform/ (with the exception of wtf/).
Adam Klein
Comment 7 2011-01-15 13:37:19 PST
Adam Klein
Comment 8 2011-01-15 13:38:42 PST
Indeed, much simpler. And it matches with the other platforms do.
WebKit Commit Bot
Comment 9 2011-01-18 13:02:50 PST
Comment on attachment 79075 [details] Patch Clearing flags on attachment: 79075 Committed r76048: <http://trac.webkit.org/changeset/76048>
WebKit Commit Bot
Comment 10 2011-01-18 13:02:56 PST
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.