WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
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
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.
Top of Page
Format For Printing
XML
Clone This Bug