Summary: | Kill StyleBase. | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Andreas Kling <kling> | ||||
Component: | CSS | Assignee: | Andreas Kling <kling> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Normal | CC: | dglazkov, japhet, koivisto, macpherson, ossy, webkit.review.bot, yael | ||||
Priority: | P2 | ||||||
Version: | 528+ (Nightly build) | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Attachments: |
|
Description
Andreas Kling
2011-10-31 05:34:13 PDT
Created attachment 113044 [details]
Le Patch
Comment on attachment 113044 [details] Le Patch Attachment 113044 [details] did not pass qt-ews (qt): Output: http://queues.webkit.org/results/10236953 Comment on attachment 113044 [details] Le Patch Attachment 113044 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/10237913 Comment on attachment 113044 [details] Le Patch View in context: https://bugs.webkit.org/attachment.cgi?id=113044&action=review r=me, very nice! > Source/WebCore/css/CSSStyleSheet.cpp:254 > + for (CSSStyleSheet* sheet = this; sheet; sheet = sheet->parentStyleSheet()) { > + if (Node* ownerNode = sheet->ownerNode()) > + return ownerNode->document(); Wonder if the ownerNode is always found from the root. If so, this could be a root search + assertion that ownerNode is null in child stylesheets. Committed r98853: <http://trac.webkit.org/changeset/98853> I like it. Thanks! It broke the debug build on the Qt bots: ../../WebCore/debug/libwebcore.a(XSLStyleSheetQt.o): In function `~XSLStyleSheet': /ramdisk/qt-linux-32-debug/build/WebKitBuild/Debug/WebCore/../../../Source/WebCore/xml/XSLStyleSheetQt.cpp:45: undefined reference to `WebCore::XSLImportRule::parentStyleSheet() const' /ramdisk/qt-linux-32-debug/build/WebKitBuild/Debug/WebCore/../../../Source/WebCore/xml/XSLStyleSheetQt.cpp:45: undefined reference to `WebCore::XSLImportRule::parentStyleSheet() const' /ramdisk/qt-linux-32-debug/build/WebKitBuild/Debug/WebCore/../../../Source/WebCore/xml/XSLStyleSheetQt.cpp:45: undefined reference to `WebCore::XSLImportRule::parentStyleSheet() const' Could you fix the build please? (In reply to comment #7) > It broke the debug build on the Qt bots: > > ../../WebCore/debug/libwebcore.a(XSLStyleSheetQt.o): In function `~XSLStyleSheet': > /ramdisk/qt-linux-32-debug/build/WebKitBuild/Debug/WebCore/../../../Source/WebCore/xml/XSLStyleSheetQt.cpp:45: undefined reference to `WebCore::XSLImportRule::parentStyleSheet() const' > /ramdisk/qt-linux-32-debug/build/WebKitBuild/Debug/WebCore/../../../Source/WebCore/xml/XSLStyleSheetQt.cpp:45: undefined reference to `WebCore::XSLImportRule::parentStyleSheet() const' > /ramdisk/qt-linux-32-debug/build/WebKitBuild/Debug/WebCore/../../../Source/WebCore/xml/XSLStyleSheetQt.cpp:45: undefined reference to `WebCore::XSLImportRule::parentStyleSheet() const' > > Could you fix the build please? I'll fix it first thing tomorrow dude, in the office! :) It seems that WTF_USE_LIBXML2 is false in WebCore.pro. This function is declared in the header, but the cpp file isn't linked. Where is WTF_USE_LIBXML2 defined? I can't see it anywhere. (In reply to comment #10) > Where is WTF_USE_LIBXML2 defined? I can't see it anywhere. Checking this non-existent define introduced in http://trac.webkit.org/changeset/89516 . Yael, Andreas have you got any idea what is it? (In reply to comment #11) > (In reply to comment #10) > > Where is WTF_USE_LIBXML2 defined? I can't see it anywhere. > > Checking this non-existent define introduced in http://trac.webkit.org/changeset/89516 . Yael, Andreas have you got any idea what is it? Hm, looks like WebCore/xml/XSLImportRule.cpp should always be built if ENABLE_XSLT; independent of USE_LIBXML2 (In reply to comment #12) > (In reply to comment #11) > > (In reply to comment #10) > > > Where is WTF_USE_LIBXML2 defined? I can't see it anywhere. > > > > Checking this non-existent define introduced in http://trac.webkit.org/changeset/89516 . Yael, Andreas have you got any idea what is it? > > Hm, looks like WebCore/xml/XSLImportRule.cpp should always be built if ENABLE_XSLT; independent of USE_LIBXML2 But there isn't any WTF_USE_LIBXML2 define, so USE(LIBXML2) is always false. FYI: A workaround landed in http://trac.webkit.org/changeset/98933. (In reply to comment #13) > (In reply to comment #12) > > (In reply to comment #11) > > > (In reply to comment #10) > > > > Where is WTF_USE_LIBXML2 defined? I can't see it anywhere. > > > > > > Checking this non-existent define introduced in http://trac.webkit.org/changeset/89516 . Yael, Andreas have you got any idea what is it? > > > > Hm, looks like WebCore/xml/XSLImportRule.cpp should always be built if ENABLE_XSLT; independent of USE_LIBXML2 > > But there isn't any WTF_USE_LIBXML2 define, so USE(LIBXML2) is always false. > > FYI: A workaround landed in http://trac.webkit.org/changeset/98933. WTF_USE_LIBXML2 isn't defined because I don't have a solution for mac and Windows. Enabling it requires libxml2 and libxslt. (In reply to comment #12) > (In reply to comment #11) > > (In reply to comment #10) > > > Where is WTF_USE_LIBXML2 defined? I can't see it anywhere. > > > > Checking this non-existent define introduced in http://trac.webkit.org/changeset/89516 . Yael, Andreas have you got any idea what is it? > > Hm, looks like WebCore/xml/XSLImportRule.cpp should always be built if ENABLE_XSLT; independent of USE_LIBXML2 It would be better than the landed hacky workaround. (In reply to comment #15) > (In reply to comment #12) > > (In reply to comment #11) > > > (In reply to comment #10) > > > > Where is WTF_USE_LIBXML2 defined? I can't see it anywhere. > > > > > > Checking this non-existent define introduced in http://trac.webkit.org/changeset/89516 . Yael, Andreas have you got any idea what is it? > > > > Hm, looks like WebCore/xml/XSLImportRule.cpp should always be built if ENABLE_XSLT; independent of USE_LIBXML2 > > It would be better than the landed hacky workaround. Yep, not sure why that was never fixed; I told Renata it was the wrong solution. Anyhow, no reason to revert that change, the method should remain inline. No build issue remains. |