Summary: | Need API to control page underlay color | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Conrad Shultz <conrad_shultz> | ||||||||||
Component: | WebKit Misc. | Assignee: | Conrad Shultz <conrad_shultz> | ||||||||||
Status: | RESOLVED FIXED | ||||||||||||
Severity: | Enhancement | CC: | andersca, anilsson, dglazkov, efidler, eric, esprehn+autocc, gyuyoung.kim, japhet, kdecker, mifenton, ojan.autocc, philn, rakuco, rwlbuis, sam, simon.fraser, thorton, tonikitoo, webkit-ews, webkit.review.bot, xan.lopez | ||||||||||
Priority: | P2 | ||||||||||||
Version: | 528+ (Nightly build) | ||||||||||||
Hardware: | Mac | ||||||||||||
OS: | Unspecified | ||||||||||||
Attachments: |
|
Description
Conrad Shultz
2013-02-26 15:44:14 PST
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). |