You need to
before you can comment on or make changes to this bug.
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
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.
I don't think we need to revert right now. Its fine to investigate first.
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.
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.
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.
style-queue ran check-webkit-style on attachment 44762 [details] without any errors.
(From update of attachment 44762 [details])
This is missing a changelog, but otherwise is fine. r=me
Committed revision 52071.
I also reopened bug 20674 :(
Also committed revision 52081.
Also committed r52083
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.
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.
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.
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.
Do any browsers have the right behavior for this?
Opera (Mac) seems to read the width as zero, and then clamp it to 32767px. The page ends up rendering correctly.
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.
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.