Bug 32078 – REGRESSION: Home photo slider is too narrow at http://www.ziprealty.com/

• Component: CSS
• Status: RESOLVED FIXED

[Adele Peterson]

Created attachment 44165 [details]
beginnings of a reduction

Steps to reproduce

1. Go to  http://www.ziprealty.com/
2. Under the "Search Featured Homes" section, there should be a home photo slider ( with left/right navigation arrows on both sides of the slider) 
3. The slider is functional but is very narrow.

This was caused by http://trac.webkit.org/changeset/49585, which was part of fixing https://bugs.webkit.org/show_bug.cgi?id=18994

Attaching the beginnings of a reduction, with an alert for debugging.  The problem is related to the fact that marginRight for the <ul> element is -9999970px

[Adele Peterson]

<rdar://problem/7382815>

[Evan Martin]

Tears.

I would guess that the problem is related to that I changed the range of valid values, limiting the range.  However, the test includes verifying that the number "98765432198" makes it through ok.  I recall that some of those tests may not pass on some platforms, but I don't see any platform-specific failures on these tests.  I may be looking in the wrong place though?  (The tests to look at are fast/css/opacity-float and fast/css/large-number-round-trip.)

I am sorry for the trouble!

I am not opposed to a revert of my change, as it is fixing a relatively obscure corner of the code, but I'd like to understand what went wrong.

[Adele Peterson]

I don't think we need to revert right now.  Its fine to investigate first.

[Adele Peterson]

Any update?

[Evan Martin]

Oh, sorry!  I thought you were looking at it.  I am going to be travelling for the next few weeks but I hopefully can find some time for it.

[Adele Peterson]

I should have been clearer.  I assumed you were going to fix it since you wrote the original change.  Let's roll out r49585 for now, and you can submit a new patch once you've figured out what the issue is.

[Adele Peterson]

Created attachment 44762 [details]
patch

I'll reopen the other bug when this is committed.  One thing I noticed is that the new tests that were added to opacity-float.html didn't pass in Firefox.  I wonder if the JS library used at this site was just expecting wrong behavior.  Might be something investigate when re-fixing the bug.

[WebKit Review Bot]

style-queue ran check-webkit-style on attachment 44762 [details] without any errors.

[Sam Weinig]

Comment on attachment 44762 [details]
patch

This is missing a changelog, but otherwise is fine. r=me

[Adele Peterson]

Committed revision 52071.

[Simon Fraser (smfr)]

I also reopened bug 20674 :(

[Adele Peterson]

Also committed revision 52081.

[Adele Peterson]

Also committed r52083

[Simon Fraser (smfr)]

Created attachment 44820 [details]
More reduced testcase

This testcase runs in Firefox as well, which has the same bug (numbers in scientific notation fail to parse). So I think the site is relying on broken behavior.

[Adele Peterson]

Why doesn't Firefox hit the bug on the live site?  Spoofing as Firefox doesn't work, so I wonder what kind of detection the site is doing.

[Simon Fraser (smfr)]

Firefox has the same behavior as WebKit did before bug 18994 was fixed. So the site is relying on broken behavior in WebKit and Firefox. I don't think we want to hold back fixing the underlying behavior for this one site.

[Adele Peterson]

hmm ok.  We should consider a site-specific hack (not sure what the threshold for that should be), and we should have an evangelism bug for this too.

[Adele Peterson]

Do any browsers have the right behavior for this?

[Simon Fraser (smfr)]

Opera (Mac) seems to read the width as zero, and then clamp it to 32767px. The page ends up rendering correctly.

[Simon Fraser (smfr)]

The testcase doesn't run in IE8, but the CSS inspector shows the width of the element to be 1342177.27px. The page renders correctly.

[Simon Fraser (smfr)]

The progression that caused this bug was re-committed in http://trac.webkit.org/changeset/69928, but the site has changed so there's no need for a workaround.