RESOLVED FIXED Bug 32078
REGRESSION: Home photo slider is too narrow at http://www.ziprealty.com/
https://bugs.webkit.org/show_bug.cgi?id=32078
Summary REGRESSION: Home photo slider is too narrow at http://www.ziprealty.com/
Adele Peterson
Reported 2009-12-02 11:15:27 PST
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
Attachments
beginnings of a reduction (170.74 KB, text/html)
2009-12-02 11:15 PST, Adele Peterson
no flags
patch (14.64 KB, patch)
2009-12-13 14:00 PST, Adele Peterson
sam: review+
More reduced testcase (260.78 KB, text/html)
2009-12-14 13:44 PST, Simon Fraser (smfr)
no flags
Adele Peterson
Comment 1 2009-12-02 11:16:08 PST
Evan Martin
Comment 2 2009-12-02 11:25:04 PST
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
Comment 3 2009-12-02 11:27:34 PST
I don't think we need to revert right now. Its fine to investigate first.
Adele Peterson
Comment 4 2009-12-11 17:02:22 PST
Any update?
Evan Martin
Comment 5 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.
Adele Peterson
Comment 6 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.
Adele Peterson
Comment 7 2009-12-13 14:00:03 PST
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
Comment 8 2009-12-13 14:05:14 PST
style-queue ran check-webkit-style on attachment 44762 [details] without any errors.
Sam Weinig
Comment 9 2009-12-13 14:52:13 PST
Comment on attachment 44762 [details] patch This is missing a changelog, but otherwise is fine. r=me
Adele Peterson
Comment 10 2009-12-13 15:00:38 PST
Committed revision 52071.
Simon Fraser (smfr)
Comment 11 2009-12-13 16:10:37 PST
I also reopened bug 20674 :(
Adele Peterson
Comment 12 2009-12-13 23:02:40 PST
Also committed revision 52081.
Adele Peterson
Comment 13 2009-12-14 01:04:04 PST
Also committed r52083
Simon Fraser (smfr)
Comment 14 2009-12-14 13:44:23 PST
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
Comment 15 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.
Simon Fraser (smfr)
Comment 16 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.
Adele Peterson
Comment 17 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.
Adele Peterson
Comment 18 2009-12-15 14:51:22 PST
Do any browsers have the right behavior for this?
Simon Fraser (smfr)
Comment 19 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.
Simon Fraser (smfr)
Comment 20 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.
Simon Fraser (smfr)
Comment 21 2010-10-17 14:01:49 PDT
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.
Note You need to log in before you can comment on or make changes to this bug.