RESOLVED FIXED 67702
[Qt] Remove Qt specific code from css/SelectorChecker.cpp
https://bugs.webkit.org/show_bug.cgi?id=67702
Summary [Qt] Remove Qt specific code from css/SelectorChecker.cpp
Csaba Osztrogonác
Reported 2011-09-07 03:00:51 PDT
This code introduced in http://trac.webkit.org/changeset/43052/trunk/WebCore/css/CSSStyleSelector.cpp and a refactoring of this code (http://trac.webkit.org/changeset/94656) showed that there are Qt specific code here (build fail), but in general code it isn't acceptable.
Attachments
proposed patch (14.44 KB, patch)
2011-09-08 08:45 PDT, Andras Becsi
no flags
proposed patch (14.49 KB, patch)
2011-09-08 08:48 PDT, Andras Becsi
no flags
proposed fix v2 (14.52 KB, patch)
2011-09-09 03:43 PDT, Andras Becsi
no flags
updated patch (14.57 KB, patch)
2011-09-12 06:28 PDT, Andras Becsi
no flags
Csaba Osztrogonác
Comment 1 2011-09-07 03:03:05 PDT
I cc-ed the author, reviewer and the commiter of the original patch, additionally Antti and András as CSS experts.
Andras Becsi
Comment 2 2011-09-07 10:25:06 PDT
(In reply to comment #0) > This code introduced in http://trac.webkit.org/changeset/43052/trunk/WebCore/css/CSSStyleSelector.cpp > and a refactoring of this code (http://trac.webkit.org/changeset/94656) showed that there are > Qt specific code here (build fail), but in general code it isn't acceptable. I have a work-in-progress patch which moves this logic to the platform specific WebPlatformStrategies, so we could deal with the QWebHistoryInterface visited link check in the platformStrategies()->visitedLinkStrategy()->isLinkVisited call to avoid the layering violation. This unfortunately would break the visited link detection on a Qt build where PLATFORM_STRATEGIES is disabled. A possible solution for this would be to only support global history if PLATFORM_STRATEGIES is enabled. Tomorrow I'll upload the patch for feedback.
Balazs Kelemen
Comment 3 2011-09-07 10:29:43 PDT
I think PLATFORM_STRATEGIES is a per platform enabled/disabled feature. Once a platform choose it it does not makes sense to return to the world before it so you should not really care about it.
Andras Becsi
Comment 4 2011-09-08 08:45:25 PDT
Created attachment 106743 [details] proposed patch
WebKit Review Bot
Comment 5 2011-09-08 08:46:56 PDT
Attachment 106743 [details] did not pass style-queue: Failed to run "['Tools/Scripts/check-webkit-style', '--diff-files', u'Source/WebCore/ChangeLog', u'Source/WebCor..." exit_code: 1 Source/WebKit/qt/ChangeLog:1: ChangeLog entry has no bug number [changelog/bugnumber] [5] Total errors found: 1 in 18 files If any of these errors are false positives, please file a bug against check-webkit-style.
Andras Becsi
Comment 6 2011-09-08 08:48:00 PDT
Created attachment 106745 [details] proposed patch Added missing bug link.
WebKit Review Bot
Comment 7 2011-09-08 09:02:32 PDT
Comment on attachment 106745 [details] proposed patch Attachment 106745 [details] did not pass cr-mac-ews (chromium): Output: http://queues.webkit.org/results/9618717
Andras Becsi
Comment 8 2011-09-08 09:12:17 PDT
Comment on attachment 106745 [details] proposed patch Chromium has forked the LinkHash support functions in chromium/PlatformSupport.h so we need another way of creating the hash for Qt.
Andras Becsi
Comment 9 2011-09-09 03:43:45 PDT
Created attachment 106855 [details] proposed fix v2
Andras Becsi
Comment 10 2011-09-12 06:28:45 PDT
Created attachment 107047 [details] updated patch
Csaba Osztrogonác
Comment 11 2011-09-21 01:51:36 PDT
Comment on attachment 107047 [details] updated patch r=me, but cq-, because CQ still hates my name. :(
Andras Becsi
Comment 12 2011-09-21 01:58:16 PDT
Comment on attachment 107047 [details] updated patch Clearing flags on attachment: 107047 Committed r95604: <http://trac.webkit.org/changeset/95604>
Andras Becsi
Comment 13 2011-09-21 01:58:25 PDT
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.