VERIFIED FIXED 6473
REGRESSION: Serious painting problems on new iLife and iWorks pages
https://bugs.webkit.org/show_bug.cgi?id=6473
Summary REGRESSION: Serious painting problems on new iLife and iWorks pages
mitz
Reported 2006-01-10 13:37:52 PST
Upon loading http://www.apple.com/ilife/iphoto/ or http://www.apple.com/iwork/pages/ they are displayed incorrectly, with the main content offset up and clipped by the top tabs. Doing Select All causes the content to draw on top of the tabs. The "Learn More" and "Visit an Apple Store" buttons are also broken. It seems that with the right combination of scrolling and highlighting the entire page can be made to repaint correctly, so this is purely a repaint (rather than layout) issue. This might be a dupe of bug 3509 or bug 6388 or both, or some other regression from the repaint optimization from bug 5633.
Attachments
Screenshot (92.99 KB, image/jpeg)
2006-01-11 14:07 PST, mitz
no flags
Testcase (686 bytes, text/html)
2006-01-13 09:26 PST, mitz
no flags
Update layer positions when a layer is pulled from the middle (3.50 KB, patch)
2006-01-13 13:00 PST, mitz
hyatt: review-
Update layer positions when a layer is pulled from the middle (4.72 KB, patch)
2006-01-13 15:29 PST, mitz
hyatt: review+
mitz
Comment 1 2006-01-11 14:07:20 PST
Created attachment 5609 [details] Screenshot
Alice Liu
Comment 2 2006-01-11 14:20:33 PST
mitz
Comment 3 2006-01-13 08:01:37 PST
I changed my mind about this being purely a painting issue: those "Learn More" links at the bottom don't move until you hover above them.
mitz
Comment 4 2006-01-13 09:26:10 PST
Created attachment 5643 [details] Testcase This testcase demonstrates the bug that makes the iLife pages break: changing the opacity from <1 to 1 creates layout and rendering problems (supposedly because of layer positioning). However, the latter bug is present also in release Safari. The iLife pages work around it by setting the opacity property to (100/101) at most. The problem is that they don't use the same workaround for the mozOpacity property, which in TOT maps to opacity (and in release Safari apparently doesn't).
mitz
Comment 5 2006-01-13 13:00:22 PST
Created attachment 5646 [details] Update layer positions when a layer is pulled from the middle
Dave Hyatt
Comment 6 2006-01-13 14:55:34 PST
Comment on attachment 5646 [details] Update layer positions when a layer is pulled from the middle This bug has convinced me that we should go further and also drop support for the -moz properties. I think this will just get us in trouble in the future. Can you go one step further and remove the code that is mapping -moz to -khtml?
mitz
Comment 7 2006-01-13 15:29:21 PST
Created attachment 5648 [details] Update layer positions when a layer is pulled from the middle Revised patch, also undoes the -moz-opacity -> opacity and -moz-border-radius -> border-radius mappings.
Dave Hyatt
Comment 8 2006-01-13 15:30:57 PST
Comment on attachment 5648 [details] Update layer positions when a layer is pulled from the middle r=me
mitz
Comment 9 2006-01-18 00:58:08 PST
Looks like Apple changed the iPhoto page since the bug was filed, but I verified the fix using the Pages page http://www.apple.com/iwork/pages/ and the testcase.
Joost de Valk (AlthA)
Comment 10 2006-01-22 04:58:07 PST
Removing keyword(s) since bug is fixed.
Note You need to log in before you can comment on or make changes to this bug.