Bug 11551 - REGRESSION (from 419.3) Google Reader List & Expanded view are broken
Summary: REGRESSION (from 419.3) Google Reader List & Expanded view are broken
Status: RESOLVED DUPLICATE of bug 12597
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 420+
Hardware: Macintosh OS X 10.4
: P1 Normal
Assignee: Nobody
URL: http://www.google.fr/reader/view/
Keywords: GoogleBug, InRadar, Regression
Depends on:
Blocks:
 
Reported: 2006-11-09 02:20 PST by Benjamin Mironer
Modified: 2007-02-27 16:20 PST (History)
6 users (show)

See Also:


Attachments
Google Reader Rendering (241.25 KB, image/png)
2006-11-14 12:19 PST, Michael Sorensen
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Benjamin Mironer 2006-11-09 02:20:55 PST
Google reader list view & expanded view (go to "All Items" to see them) do not display properly.
Regular Safari from Tiger (419.3) works fine.
Comment 1 Bill Burcham 2006-11-10 12:02:12 PST
In expanded view, the hyperlink/controls at the bottom of each item are jumbled and missing their icons.  Looks like an image replacement problem since the hyperlinks are present and functional.

Some controls at the bottom of each item are not functional at all: "edit tags", and "email".
Comment 2 Michael Sorensen 2006-11-14 12:19:39 PST
Created attachment 11521 [details]
Google Reader Rendering

This is a screen grab of the Google Reader rendering in the latest webkit (2.0.4/419.3).
Comment 3 Stephanie Lewis 2007-01-22 17:36:38 PST
In Radar 
<rdar://problem/4946991>
Comment 4 W. Andy Carrel 2007-01-27 23:30:59 PST
Spent a little time chasing this down today. It turns out this is caused by the fact that the current JavaScriptCore interaction with the document doesn't do the right thing with node.className="foo". This should result in the equivalent to <node class="foo"> but instead it results in <node classname="foo">.
Comment 5 W. Andy Carrel 2007-01-28 01:07:55 PST
(In reply to comment #4)
> Spent a little time chasing this down today. It turns out this is caused by the
> fact that the current JavaScriptCore interaction with the document doesn't do
> the right thing with node.className="foo". This should result in the equivalent
> to <node class="foo"> but instead it results in <node classname="foo">.

False start, 10 yard penalty on me. JavaScript that works for this on Firefox is:
somediv.setAttribute("class", "foo");
somediv.className = "foo";

I'll have to look a little harder.
Comment 6 Maciej Stachowiak 2007-01-30 19:11:22 PST
I think this might be a bug in Google's user agent detection. If so, we will need them to fix it.
Comment 7 mitz 2007-02-21 08:27:01 PST
(In reply to comment #6)
> I think this might be a bug in Google's user agent detection. If so, we will
> need them to fix it.
> 

See bug 12597 comment #4.
Comment 8 Beth Dakin 2007-02-27 16:20:18 PST
I just confirmed, that like http://bugs.webkit.org/show_bug.cgi?id=12597 , this bug was caused by:
http://trac.webkit.org/projects/webkit/changeset/13555

And it is, indeed, a bug in Google's user agent detection. contains should only be defined for elements, but we wrongly defined it for the document in Safari 2.0. The above change fixed our behavior so that we only support contains for elements. Unfortunately, many Google sites seem to detect Safari by looking for document.contains. And now that we don't support it any more, they don't know it's us!

I am going to mark this as a duplicate since it is the same problem.

*** This bug has been marked as a duplicate of 12597 ***