Summary: | Black Highlight when selecting certain elements | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Aaron Conran <aaron> | ||||||
Component: | WebKit Qt | Assignee: | QtWebKit Unassigned <webkit-qt-unassigned> | ||||||
Status: | RESOLVED DUPLICATE | ||||||||
Severity: | Normal | CC: | ariya.hidayat, hausmann, kenneth, kent.hansen | ||||||
Priority: | P2 | Keywords: | Qt | ||||||
Version: | 528+ (Nightly build) | ||||||||
Hardware: | All | ||||||||
OS: | All | ||||||||
Attachments: |
|
Description
Aaron Conran
2010-02-09 12:55:08 PST
It's also worth noting that this example works fine in Chrome and Safari. Created attachment 48617 [details]
Naive Patch
This naive patch solves the problem for me.
However, It seems to be indicative of a deeper problem where we have a brush with an invalid color that does not have a style == Qt::NoBrush.
Ah I remember that we had such a similar issue before. Do you remember the details Simon? I guess this is because of my commit: http://trac.webkit.org/changeset/37421 The optimization does not take into account that the color could be bogus. The patch from Nick looks good to solve this problem. > I guess this is because of my commit: http://trac.webkit.org/changeset/37421
False alarm. Excluding the optimization still shows the same behaviour.
Nick: if you include some ChangeLog, then we can land your patch.
Please follow the QtWebKit bug reporting guidelines when reporting bugs. See http://trac.webkit.org/wiki/QtWebKitBugs Specifically: - The 'QtWebKit' component should only be used for bugs/features in the public QtWebKit API layer, not to signify that the bug is specific to the Qt port of WebKit http://trac.webkit.org/wiki/QtWebKitBugs#Component - Add the keyword 'Qt' to signal that it's a Qt-related bug http://trac.webkit.org/wiki/QtWebKitBugs#Keywords Fixed by the commit http://trac.webkit.org/changeset/58949 |