Bug 7235

Summary:

Pure CSS Tooltips method renders wrong and creates artifacts

Product:

WebKit

Reporter:

Jeremy Knope <jerome>

Component:

CSS

Assignee:

Nobody <webkit-unassigned>

Status:

RESOLVED FIXED

Severity:

Normal

CC:

michaelm, mitz

Priority:

Keywords:

HasReduction

Version:

420+

Hardware:

Mac

OS:

OS X 10.4

URL:

http://www.cybersaps.org/2004/01/Pure-css-tooltips.html

Attachments:

Description	Flags
uploaded version of css render bug example	none
Reduced testcase	none
First cut at a fix	hyatt: review+
Patch including manual test and changelog entry	hyatt: review+

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	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
Show Obsolete (1) View All Add attachment proposed patch, testcase, etc.

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.