Bug 12553 – Type rendering slightly off after AJAX reload of content

• Component: Layout and Rendering
• Status: RESOLVED INVALID

[Faruk Ates]

In: Webkit nightly, revision 19341  on Mac OS X 10.4.8

*** Overview description ***
Type rendering is slightly off after an AJAX-driven reload of (partial) page content.


*** Steps to reproduce ***
1) go to URL http://storedev.apple.com/1-800-MY-APPLE/WebObjects/AppleStore.woa/wa/RSLID?mco=392EC8B&nplm=MA086LL%2FA
2) scroll down to the Reviews section and take a very close look at the first post (as example)
3) switch to a different page of the reviews, then switch back to page 1
4) compare visual difference. Take screenshots if necessary.


*** Actual results ***
Text looks slightly different than it should; looks slightly different for the first page's content compared to what it looks like before switching pages.


*** Expected result ***
Text to look the same, visually.


*** Additional information ***
- AJAX change is driven by a Dojo library, which uses Opacity to do the fade-in and fade-out
- bug initially discovered in the latest public Safari
- I have sent two images of the first post, text scaled up two notches, to Maciej Stachowiak. The first image shows the post after page load, the second shows the post after switching Reviews pages back and forth. Visual differences are easy to spot at this text size (I can send the screenshots to whoever wants them, or ask Maciej for them).

[Faruk Ates]

Created attachment 12887 [details]
First screenshot: directly after page load

This is the first review post, with the text scaled up two notches, taken directly after the page loaded, so before any switching of Reviews pages via AJAX.

[Faruk Ates]

Created attachment 12888 [details]
Second screenshot: after switching pages back and forth

This screenshot shows the exact same post after switching to a different Reviews page and then back to page 1. It's visually different by quite a noticeable margin, so much so that on the regular text size we noticed the text looking "not so good".

[David Kilzer (:ddkilzer)]

(In reply to comment #0)
> 3) switch to a different page of the reviews, then switch back to page 1

How are you "switching" views?  Are you clicking the "2" link, then clicking the Back button on Safari, or doing something else?

Offhand I'd say the text in the second attachment (Attachment 12888 [details]) looks like it lost its antialiasing when being redrawn.

Does this only reproduce on storedev.apple.com and not store.apple.com?

One thing that will make text smoothing look like in attachment 12888 [details] (it's still antialiased, it just monochromatic) is text-shadow (or painting into a transparency layer, IIRC). You need to examine the CSS style of the text (and possibly its container) and see if there's a difference.

[Faruk Ates]

(In reply to comment #3)
> How are you "switching" views?  Are you clicking the "2" link, then clicking
> the Back button on Safari, or doing something else?

Yes, apologies for not being explicitly clear. Switching views is done by clicking on one of the page numbers, for instance, "2", and clicking back to page 1 (so that you can view the difference prior to and after switching).


> Does this only reproduce on storedev.apple.com and not store.apple.com?

We don't have this setup of AJAX-switching live on the store yet, so currently it's only on storedev.apple.com 


(In reply to comment #4)
> One thing that will make text smoothing look like in attachment 12888 [details] [edit] (it's
> still antialiased, it just monochromatic) is text-shadow (or painting into a
> transparency layer, IIRC). You need to examine the CSS style of the text (and
> possibly its container) and see if there's a difference.

We aren't using text-shadow but we ARE using opacity for the fade, so t hat would use the transparency layer I'm sure. However, the Web Inspector shows no style differences between the two states. 

Question: could it be that in CSS, "opacity: 1.000" is not a valid value and could that cause the issue? (leaving it stuck at the previous iteration of the opacity/fade loop, which I believe is 0.999)

(In reply to comment #5)
> Question: could it be that in CSS, "opacity: 1.000" is not a valid value and
> could that cause the issue? (leaving it stuck at the previous iteration of the
> opacity/fade loop, which I believe is 0.999)
> 

Simple experimentation shows that 1.000 is valid, but indeed the screenshot is consistent with the "stuck at 0.999" theory. However, in that case, the fractional opacity should show up in the Web Inspector (in the Computed Style properties). Perhaps not on the element where you're looking for it but on some other element.

[Faruk Ates]

> Simple experimentation shows that 1.000 is valid, but indeed the screenshot is
> consistent with the "stuck at 0.999" theory. However, in that case, the
> fractional opacity should show up in the Web Inspector (in the Computed Style
> properties). Perhaps not on the element where you're looking for it but on some
> other element. 

It's the ReviewList containing element that is stuck at 0.999999 after all. I wrote a user style sheet to override the JavaScript to verify if that was causing the odd rendering, and it does indeed: with the userstyle-css applied, setting the opacity to 1, the type rendered properly after switching.

We'll work on fixing that opacity setting, thanks for your time & help!