| Summary: | [chromium] WebKit::setColorNames is a client API | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | James Robinson <jamesr> | ||||||
| Component: | New Bugs | Assignee: | James Robinson <jamesr> | ||||||
| Status: | RESOLVED FIXED | ||||||||
| Severity: | Normal | CC: | abarth, enne, fishd | ||||||
| Priority: | P2 | ||||||||
| Version: | 528+ (Nightly build) | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| Bug Depends on: | 79544 | ||||||||
| Bug Blocks: | |||||||||
| Attachments: |
|
||||||||
|
Description
James Robinson
2012-02-24 15:43:54 PST
Created attachment 128819 [details]
Patch
I moved WebColor into Platform/ since it's needed for some compositor APIs, but upon reflection WebKit::setNamedColors is really logically a client API. This moves setNamedColors and the WebColorName enums back into the client space. I can update the chromium headers as a follow-up and then remove the platform/WebColorName.h forwarding header. I think WebColor as a typedef for unsigned should remain in both APIs. Actually, I should probably move the setNamedColors() impl from WebColor.cpp to WebColorName.cpp if I do this. Will update patch... Created attachment 128820 [details]
Patch
Committed r108860: <http://trac.webkit.org/changeset/108860> Rolled out in r108865. From http://build.chromium.org/p/chromium.webkit/builders/Linux%20Tests/builds/18924/steps/compile/logs/stdio: --SNIP-- CXX(target) out/Release/obj.target/content_common/content/common/swapped_out_messages.o In file included from ./third_party/WebKit/Source/WebKit/chromium/public/platform/WebColorName.h:29, from ./content/common/css_colors.h:13, from ./content/common/view_messages.h:11, from content/browser/resolve_proxy_msg_helper.cc:10: ./third_party/WebKit/Source/WebKit/chromium/public/platform/../WebColorName.h:34:29:error: public/WebColor.h: No such file or directory ./third_party/WebKit/Source/WebKit/chromium/public/platform/../WebColorName.h:35:30:error: public/WebCommon.h: No such file or directory --SNIP-- Code on the chromium side that #inclues WebColorName.h depends on the WebKit client API but not the Platform API, so it doesn't have the Platform API's include paths. I think the fix is to use full relative include paths like "../../../Platform/chromium/public/WebColor.h" in WebKit/chromium/public/WebColorName.h or to jigger the dependencies around so that every target that depends on the WebKit client API also has the Platform API's include paths. Committed r108877: <http://trac.webkit.org/changeset/108877> |