It would be useful for clients to have API to customize the background/underlay color displayed beneath the page, e.g. during rubber-banding.
Created attachment 190402 [details] Patch
Comment on attachment 190402 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=190402&action=review > Source/WebKit2/WebProcess/WebPage/WebPage.cpp:1871 > +void WebPage::setUnderlayColor(const WebCore::Color& color) This file using namespace WebCore;s. Maybe some of the others too, but definitely this one.
Comment on attachment 190402 [details] Patch Will submit a new version based on feedback.
Created attachment 190662 [details] Patch
Comment on attachment 190662 [details] Patch Attachment 190662 [details] did not pass qt-ews (qt): Output: http://webkit-commit-queue.appspot.com/results/16791196
Comment on attachment 190662 [details] Patch Attachment 190662 [details] did not pass chromium-ews (chromium-xvfb): Output: http://webkit-commit-queue.appspot.com/results/16771916
Created attachment 190668 [details] Patch
Comment on attachment 190668 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=190668&action=review > Source/WebCore/page/ChromeClient.h:190 > + virtual Color underlayColor() const = 0; I think this should not be pure virtual, and can return Color() so you don't have to touch all the other clients. > Source/WebCore/platform/mac/ScrollbarThemeMac.mm:620 > + graphicsLayer->platformLayer().backgroundColor = backgroundColor.isValid() ? nsColor(backgroundColor).CGColor : cachedLinenBackgroundColor; I think this should use cachedCGColor(backgroundColor, ColorSpaceDeviceRGB).
(In reply to comment #8) > (From update of attachment 190668 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=190668&action=review > > > Source/WebCore/page/ChromeClient.h:190 > > + virtual Color underlayColor() const = 0; > > I think this should not be pure virtual, and can return Color() so you don't have to touch all the other clients. Changed. > > > Source/WebCore/platform/mac/ScrollbarThemeMac.mm:620 > > + graphicsLayer->platformLayer().backgroundColor = backgroundColor.isValid() ? nsColor(backgroundColor).CGColor : cachedLinenBackgroundColor; > > I think this should use cachedCGColor(backgroundColor, ColorSpaceDeviceRGB). Good idea, changed. Will post a revised patch shortly.
Created attachment 190766 [details] Patch
Comment on attachment 190766 [details] Patch Clearing flags on attachment: 190766 Committed r144397: <http://trac.webkit.org/changeset/144397>
All reviewed patches have been landed. Closing bug.
Comment on attachment 190766 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=190766&action=review > Source/WebKit2/UIProcess/WebPageProxy.cpp:865 > + if (isValid()) > + m_process->send(Messages::WebPage::SetUnderlayColor(color), m_pageID); I don’t understand why the isValid() check here is a good idea. If we set the underlay color to an invalid color, then m_underlayColor gets set, but the other process is never told and is left with the old underlay color? That’s strange behavior. Seems we should send a SetUnderlayColor message to clear the underlay color if the new color is invalid.
(In reply to comment #13) > (From update of attachment 190766 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=190766&action=review > > > Source/WebKit2/UIProcess/WebPageProxy.cpp:865 > > + if (isValid()) > > + m_process->send(Messages::WebPage::SetUnderlayColor(color), m_pageID); > > I don’t understand why the isValid() check here is a good idea. If we set the underlay color to an invalid color, then m_underlayColor gets set, but the other process is never told and is left with the old underlay color? That’s strange behavior. Seems we should send a SetUnderlayColor message to clear the underlay color if the new color is invalid. isValid checks if the WebProcess is valid, not the color (right?). If we try to send a message to !isValid() WebProcess, we crash. We've really gotta sort this out, because there are a bunch of WebPageProxy methods where it's easy to cause a crash by trying to do something from the UIProcess at the wrong time (especially post-WebProcess-crash).