Move functions from Frame to SelectionController as planned
Created attachment 67130 [details] Patch
Attachment 67130 [details] did not build on chromium: Build output: http://queues.webkit.org/results/3974365
Comment on attachment 67130 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=67130&action=prettypatch Please try not to break the chromium build when landing. Thanks! > WebKit/chromium/src/WebFrameImpl.cpp:1716 > + return IntRect(frame()->selection()->selectionBounds(false)); Not just selection()->bounds(false) ? > WebKit/mac/WebView/WebHTMLView.mm:6052 > + coreFrame->selection()->selectionTextRects(list, SelectionController::RespectTransforms); selection()->selectionTextRects => selection()->textRects ?
Sure, we could rename these functions now that they are on the SelectionController, but I think it’s probably best to do that in a separate pass. I’ll think about doing it now, though.
ok. I just noticed you renamed granularity, which seemed like a good idea.
(In reply to comment #5) > I just noticed you renamed granularity, which seemed like a good idea. That case was different; believe it or not I didn’t rename things. Frame::selectionGranularity() was a function with the body "return selection()->granularity()", and I chose to delete that rather than moving it to SelectionController. One problem with renaming is that SelectionController is accessed with a call named selection() yet represents more than just the selection; the broader concept of selection control. So in some cases we might need to keep selection in the names of selection controller functions. But despite that it does seem likely we can remove the word selection from virtually all SelectionController function names. Just not sure if I should do it now as part of this patch.
Committed r67238: <http://trac.webkit.org/changeset/67238>
*** Bug 23431 has been marked as a duplicate of this bug. ***