RESOLVED FIXED 7235
Pure CSS Tooltips method renders wrong and creates artifacts
https://bugs.webkit.org/show_bug.cgi?id=7235
Summary Pure CSS Tooltips method renders wrong and creates artifacts
Jeremy Knope
Reported 2006-02-13 11:30:48 PST
Using the 'Pure CSS Tooltips' method described in the url given in report (http://www.cybersaps.org/2004/01/Pure-css-tooltips.html) ends up with funky draw problems in Safari (and WebKit nightly.) This will render fine in Firefox. Hope to see this fixed, being an excellent no-javascript-fancy-tooltip method. I pulled a more noticeable example from an app at my work that renders really bad: http://www.macsaresexy.com/files/pure_css_tooltips.html
Attachments
uploaded version of css render bug example (3.10 KB, text/html)
2006-02-13 11:32 PST, Jeremy Knope
no flags
Reduced testcase (599 bytes, text/html)
2006-02-13 15:08 PST, mitz
no flags
First cut at a fix (3.91 KB, patch)
2006-02-14 14:00 PST, mitz
hyatt: review+
Patch including manual test and changelog entry (6.27 KB, patch)
2006-02-15 09:40 PST, mitz
hyatt: review+
Jeremy Knope
Comment 1 2006-02-13 11:32:15 PST
Created attachment 6461 [details] uploaded version of css render bug example wanted to upload a version of the linked file so don't have to rely on my link
Alexey Proskuryakov
Comment 2 2006-02-13 11:54:02 PST
This looks quite similar to bug 7204.
Jeremy Knope
Comment 3 2006-02-13 12:05:05 PST
(In reply to comment #2) > This looks quite similar to bug 7204. > sounds like it could be, 7204 references javascript and DOM usage of producing content where this one is pure CSS, html is already there but the use of CSS in doing some tricks like :hover, display: none etc. with elements inside an <a> tag seem to get rendered funny. but could be similar in how it's rendered/handled internally. just wanted to clarify that this one isn't javascript & DOM related I don't think.
mitz
Comment 4 2006-02-13 15:08:03 PST
Created attachment 6469 [details] Reduced testcase
mitz
Comment 5 2006-02-13 15:10:04 PST
This is a repaint issue
mitz
Comment 6 2006-02-14 11:09:01 PST
This is the case of a positioned layer that has an enclosing relpositioned inline which is handled in updateLayerPosition, but not in getAbsoluteRepaintRect* and absolutePosition, hence the incorrect repaint.
mitz
Comment 7 2006-02-14 14:00:21 PST
Created attachment 6491 [details] First cut at a fix This fixes the bug by implementing the logic from RenderLayer::updateLayerPosition in RenderBox::absolutePosition and RenderBox::computeAbsoluteRepaintRect. It's probably a bad idea to repeat that code twice, so I'll welcome suggestions on that (including naming).
Dave Hyatt
Comment 8 2006-02-14 14:37:51 PST
Comment on attachment 6491 [details] First cut at a fix Unfortunate code duplication, but eventually I wanted to rework absolutePosition to use layers anyway.
mitz
Comment 9 2006-02-15 09:40:15 PST
Created attachment 6506 [details] Patch including manual test and changelog entry Left in the duplicate code for now.
Dave Hyatt
Comment 10 2006-02-17 12:59:17 PST
Comment on attachment 6506 [details] Patch including manual test and changelog entry r=me
mitz
Comment 11 2006-12-16 12:21:26 PST
*** Bug 3875 has been marked as a duplicate of this bug. ***
Note You need to log in before you can comment on or make changes to this bug.