Bug 7235 - Pure CSS Tooltips method renders wrong and creates artifacts
Summary: Pure CSS Tooltips method renders wrong and creates artifacts
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: CSS (show other bugs)
Version: 420+
Hardware: Macintosh OS X 10.4
: P2 Normal
Assignee: Nobody
URL: http://www.cybersaps.org/2004/01/Pure...
Keywords: HasReduction
: 3875 (view as bug list)
Depends on:
Blocks:
 
Reported: 2006-02-13 11:30 PST by Jeremy Knope
Modified: 2006-12-16 12:21 PST (History)
2 users (show)

See Also:


Attachments
uploaded version of css render bug example (3.10 KB, text/html)
2006-02-13 11:32 PST, Jeremy Knope
no flags Details
Reduced testcase (599 bytes, text/html)
2006-02-13 15:08 PST, mitz
no flags Details
First cut at a fix (3.91 KB, patch)
2006-02-14 14:00 PST, mitz
hyatt: review+
Details | Formatted Diff | Diff
Patch including manual test and changelog entry (6.27 KB, patch)
2006-02-15 09:40 PST, mitz
hyatt: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jeremy Knope 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
Comment 1 Jeremy Knope 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
Comment 2 Alexey Proskuryakov 2006-02-13 11:54:02 PST
This looks quite similar to bug 7204.
Comment 3 Jeremy Knope 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.
Comment 4 mitz 2006-02-13 15:08:03 PST
Created attachment 6469 [details]
Reduced testcase
Comment 5 mitz 2006-02-13 15:10:04 PST
This is a repaint issue
Comment 6 mitz 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.
Comment 7 mitz 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).
Comment 8 Dave Hyatt 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.
Comment 9 mitz 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.
Comment 10 Dave Hyatt 2006-02-17 12:59:17 PST
Comment on attachment 6506 [details]
Patch including manual test and changelog entry

r=me
Comment 11 mitz 2006-12-16 12:21:26 PST
*** Bug 3875 has been marked as a duplicate of this bug. ***