Bug 32078 - REGRESSION: Home photo slider is too narrow at http://www.ziprealty.com/
: REGRESSION: Home photo slider is too narrow at http://www.ziprealty.com/
: WebKit
: 528+ (Nightly build)
: PC Mac OS X 10.5
: P2 Normal
Assigned To:
: http://www.ziprealty.com/
: InRadar
  Show dependency treegraph
Reported: 2009-12-02 11:15 PST by
Modified: 2010-10-17 14:01 PST (History)

beginnings of a reduction (170.74 KB, text/html)
2009-12-02 11:15 PST, Adele Peterson
no flags Details
patch (14.64 KB, patch)
2009-12-13 14:00 PST, Adele Peterson
sam: review+
Review Patch | Details | Formatted Diff | Diff
More reduced testcase (260.78 KB, text/html)
2009-12-14 13:44 PST, Simon Fraser (smfr)
no flags Details


You need to log in before you can comment on or make changes to this bug.

Description From 2009-12-02 11:15:27 PST
Created an attachment (id=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
------- Comment #1 From 2009-12-02 11:16:08 PST -------
------- Comment #2 From 2009-12-02 11:25:04 PST -------

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.
------- Comment #3 From 2009-12-02 11:27:34 PST -------
I don't think we need to revert right now.  Its fine to investigate first.
------- Comment #4 From 2009-12-11 17:02:22 PST -------
Any update?
------- Comment #5 From 2009-12-12 09:56:49 PST -------
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.
------- Comment #6 From 2009-12-12 13:54:44 PST -------
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.
------- Comment #7 From 2009-12-13 14:00:03 PST -------
Created an attachment (id=44762) [details]

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.
------- Comment #8 From 2009-12-13 14:05:14 PST -------
style-queue ran check-webkit-style on attachment 44762 [details] without any errors.
------- Comment #9 From 2009-12-13 14:52:13 PST -------
(From update of attachment 44762 [details])
This is missing a changelog, but otherwise is fine. r=me
------- Comment #10 From 2009-12-13 15:00:38 PST -------
Committed revision 52071.
------- Comment #11 From 2009-12-13 16:10:37 PST -------
I also reopened bug 20674 :(
------- Comment #12 From 2009-12-13 23:02:40 PST -------
Also committed revision 52081.
------- Comment #13 From 2009-12-14 01:04:04 PST -------
Also committed r52083
------- Comment #14 From 2009-12-14 13:44:23 PST -------
Created an attachment (id=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.
------- Comment #15 From 2009-12-14 13:48:31 PST -------
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.
------- Comment #16 From 2009-12-14 13:54:57 PST -------
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.
------- Comment #17 From 2009-12-14 22:20:25 PST -------
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.
------- Comment #18 From 2009-12-15 14:51:22 PST -------
Do any browsers have the right behavior for this?
------- Comment #19 From 2009-12-15 15:00:27 PST -------
Opera (Mac) seems to read the width as zero, and then clamp it to 32767px. The page ends up rendering correctly.
------- Comment #20 From 2009-12-15 15:47:35 PST -------
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.
------- Comment #21 From 2010-10-17 14:01:49 PST -------
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.