Bug 11027 - REGRESSION: Safari applies the wrong font to BODY element at http://www.apple.com/downloads/dashboard/
Summary: REGRESSION: Safari applies the wrong font to BODY element at http://www.apple...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: 420+
Hardware: Mac OS X 10.4
: P1 Major
Assignee: Nobody
URL:
Keywords: InRadar, Regression
: 10919 (view as bug list)
Depends on:
Blocks:
 
Reported: 2006-09-25 12:16 PDT by Chris Petersen
Modified: 2007-02-01 23:43 PST (History)
4 users (show)

See Also:

Attachments
sample test case (437 bytes, text/html)
2006-09-25 12:17 PDT, Chris Petersen 		no flags Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Petersen 2006-09-25 12:16:42 PDT 
* SUMMARY
With TOT webkit r-16553, I noticed the default font used at http://www.apple.com/downloads/dashboard/  is different when compared to stock Safari or even Mac Firefox 1.5.0.7. The CSS rule on this page is specifying {font: 13px 'Helvetica Neue';} which I assumed r-16553 was using. However, r-16553 appears to be using a different font style called "Helvetica Neue UltraLight" instead. 


* STEPS TO REPRODUCE
1. With TOT webkit r-16553 under 10.4.7 , open reduced test case "apple_downloads.html"
2. Notice how the font is rendered (styling). Now , open this test case in  stock Safari or Mac Firefox 1.5.0.6 on this same machine for a comparison.
3. Now launch Apple's  FontBook app. Click on All Fonts. Find "Helvetica Neue" in the list.
4. Click on "Helvetica Neue UltraLight" and verify this is the same font being used by TOT webkit r-16553.

* RESULTS
TOT webkit r-16553 should render the page with the specified font but doesn't.

* REGRESSION
Yes. This does appear to work in stock Safari under 10.4.7.
Comment 1 Chris Petersen 2006-09-25 12:17:43 PDT 
Created attachment 10762 [details]
sample test case
Comment 2 Chris Petersen 2006-09-25 12:18:39 PDT 
This is covered in <rdar://problem/4728514>.
Comment 3 Chris Petersen 2006-09-25 15:43:02 PDT 
This issue first regressed with r16252.
Comment 4 mitz 2007-01-16 10:08:33 PST 
*** Bug 10919 has been marked as a duplicate of this bug. ***
Comment 5 mitz 2007-01-16 10:09:58 PST 
Fixed in r17450, reintroduced in r18680.
Comment 6 Mark Rowe (bdash) 2007-01-22 17:05:04 PST 
I can't seem to reproduce this with current ToT.  The rendering of the test case appears identical with WebKit 418.9.1 and ToT.
Comment 7 mitz 2007-01-23 09:00:13 PST 
(In reply to comment #6)
> I can't seem to reproduce this with current ToT.  The rendering of the test
> case appears identical with WebKit 418.9.1 and ToT.
> 

Doesn't look the same on my machine.
Comment 8 Chris Petersen 2007-02-01 08:51:43 PST 
We really need to address this issue since can affect other third party webkit applications when running with TOT webkit frameworks.
Comment 9 mitz 2007-02-01 23:43:25 PST 
Fixed again by Tim H in r19349.