RESOLVED FIXED 14307
REGRESSION: Google Product Search results pages render incorrectly
https://bugs.webkit.org/show_bug.cgi?id=14307
Summary REGRESSION: Google Product Search results pages render incorrectly
Greg Smith
Reported 2007-06-22 00:13:47 PDT
1) Go to Google product search (http://www.google.com/products) 2) Search for anything 3) On the results page, set the view to list view, if it isn't already 4) See rendering issue Basically, the issue is that the area where the prices are overlaps and runs off the page to the right, making prices impossible to see without scrolling to the right. The page is rendered too wide, and the price area overlaps and runs over what would be the sponsored links area. I would like to attach a screenshot of how WebKit renders this page (incorrect) vs. Camino (gecko-based) renders the page (correct), however I cannot find where to attach anything. This issue occurs with the Safari 3.0 beta and with the Safari 3.0 beta using the most recent webkit nightly.
Attachments
Safari, full screen, no prices visible (incorrect rendering). (364.47 KB, image/png)
2007-06-22 00:21 PDT, Greg Smith
no flags
reduction (474 bytes, text/html)
2007-06-28 06:15 PDT, Antti Koivisto
no flags
Slightly less reduced test case to show impact of doctype (325 bytes, text/html)
2007-07-06 04:05 PDT, Antti Koivisto
no flags
Greg Smith
Comment 1 2007-06-22 00:21:16 PDT
Created attachment 15178 [details] Safari, full screen, no prices visible (incorrect rendering).
David Kilzer (:ddkilzer)
Comment 2 2007-06-22 10:12:17 PDT
Confirmed with Safari 3.0 (522.11) with a local debug build of WebKit r23728 on Mac OS X 10.4.10 (8R218). This is a regression from Safari 2.0.4 (419.3) as the page renders similar to Firefox 2.0.0.4 on the same Mac. Note that the text descriptions of the items do not wrap in ToT WebKit, either (compared to Safari 2.0.4 and Firefox 2.0.0.4), which may or may not be related. Needs a reduction to determine if this is a WebKit bug or a Google evangelism bug.
David Kilzer (:ddkilzer)
Comment 3 2007-06-22 10:16:13 PDT
(In reply to comment #2) > Needs a reduction to determine if this is a WebKit bug or a Google evangelism > bug. Spoofing Safari 3.0 as Firefox 2.0.0.2 does not change the rendering, so this is likely a browser bug.
David Kilzer (:ddkilzer)
Comment 4 2007-06-22 10:35:27 PDT
Greg Smith
Comment 5 2007-06-26 21:28:54 PDT
In working on a test case reduction for this I realized that removing the doctype causes the page to render CORRECTLY. The doctype is: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> I am working on a reduction with the doctype included so that I can find the specific problem in the code that renders this particular doctype. Is this the correct thing I should be doing?
Antti Koivisto
Comment 6 2007-06-28 06:15:32 PDT
Created attachment 15288 [details] reduction <div><nobr></div> closes nobr in Firefox but not in WebKit ToT.
Antti Koivisto
Comment 7 2007-06-28 08:06:25 PDT
ToT behavior here matches HTML5 draft and html5lib output but not Firefox.
David Kilzer (:ddkilzer)
Comment 8 2007-07-05 21:56:57 PDT
Looks like a Google bug per Comment #6 and Comment #7.
Antti Koivisto
Comment 9 2007-07-06 04:05:25 PDT
Created attachment 15415 [details] Slightly less reduced test case to show impact of doctype On Firefox this page works because <div><nobr></div> closes nobr. On IE7 it does not close but the page works since nobr does not affect content of tables. Without DOCTYPE WebKit defaults to quirks mode which matches IE behavior and the page works too. However the Transitional DOCTYPE on the page throws WebKit to almost-standards mode. We could fix this by adopting Firefox nobr close behavior but that does not match either IE or current HTML5 draft so it does not sound very appealing. Adopting IE behavior in almost-standards mode sounds like a bad idea too. I think this could be better fixed in Google side.
David Kilzer (:ddkilzer)
Comment 10 2007-07-11 17:51:49 PDT
This is an evangelism issue per Comment #9.
David Kilzer (:ddkilzer)
Comment 11 2007-07-12 10:52:55 PDT
This appears to be fixed now!
Note You need to log in before you can comment on or make changes to this bug.