| Summary: | Remove the immediate repaint codepath and support, it doesn't do anything | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | James Robinson <jamesr> | ||||
| Component: | New Bugs | Assignee: | James Robinson <jamesr> | ||||
| Status: | NEW --- | ||||||
| Severity: | Normal | CC: | darin, eric, fishd, hyatt, mitz | ||||
| Priority: | P2 | ||||||
| Version: | 528+ (Nightly build) | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Attachments: |
|
||||||
|
Description
James Robinson
2011-07-21 18:18:13 PDT
Created attachment 101687 [details]
Patch
This code appears to work perfectly well in WebKit1 in OS X Lion. I tested activating a link with the keyboard and activating a button with a keyboard, and in both cases the element painted in its active state, then after a short delay, repainted the inactive state. I think the patch will break this behavior. Comment on attachment 101687 [details] Patch Attachment 101687 [details] did not pass mac-ews (mac): Output: http://queues.webkit.org/results/9199971 Comment on attachment 101687 [details] Patch Attachment 101687 [details] did not pass mac-ews (mac): Output: http://queues.webkit.org/results/9193968 Comment on attachment 101687 [details]
Patch
review- based on the build failures and Dan’s comments
Wow. Do we know if there is another way to get this behavior for Mac? If James is correct, this 80k patch of code is only to support Mac WK1. :) If we have to keep it for Mac, that's fine (and we can do bug 87054 instead, but if it's possible to get this behavior some other way, that seems best. I guess bug 87054 is the expedient solution since it's unlikely that James is the right person to change Mac WK1 here. |