Bug 14307

Summary:

REGRESSION: Google Product Search results pages render incorrectly

Product:

WebKit

Reporter:

Greg Smith <smitty078>

Component:

Evangelism

Assignee:

Nobody <webkit-unassigned>

Status:

RESOLVED FIXED

Severity:

Normal

CC:

abob, koivisto, troyb

Priority:

Keywords:

GoogleBug, HasReduction, InRadar, Regression

Version:

523.x (Safari 3)

Hardware:

Mac (PowerPC)

OS:

OS X 10.4

URL:

http://www.google.com/products

Attachments:

Description	Flags
Safari, full screen, no prices visible (incorrect rendering).	none
reduction	none
Slightly less reduced test case to show impact of doctype	none

Description Greg Smith 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.

Comment 1 Greg Smith 2007-06-22 00:21:16 PDT

Created attachment 15178 [details]
Safari, full screen, no prices visible (incorrect rendering).

Comment 2 David Kilzer (:ddkilzer) 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.

Comment 3 David Kilzer (:ddkilzer) 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.

Comment 4 David Kilzer (:ddkilzer) 2007-06-22 10:35:27 PDT

<rdar://problem/5287892>

Comment 5 Greg Smith 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?

Comment 6 Antti Koivisto 2007-06-28 06:15:32 PDT

Created attachment 15288 [details]
reduction

<div><nobr></div> closes nobr in Firefox but not in WebKit ToT.

Comment 7 Antti Koivisto 2007-06-28 08:06:25 PDT

ToT behavior here matches HTML5 draft and html5lib output but not Firefox.

Comment 8 David Kilzer (:ddkilzer) 2007-07-05 21:56:57 PDT

Looks like a Google bug per Comment #6 and Comment #7.

Comment 9 Antti Koivisto 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.

Comment 10 David Kilzer (:ddkilzer) 2007-07-11 17:51:49 PDT

This is an evangelism issue per Comment #9.

Comment 11 David Kilzer (:ddkilzer) 2007-07-12 10:52:55 PDT

This appears to be fixed now!