[webkit-reviews] review canceled: [Bug 98832] Remove fast/events/attempt-scroll-with-no-scrollbars.html : [Attachment 168831] Proposed removal

[bugzilla-daemon at webkit.org]

Julien Chaffraix <jchaffraix at webkit.org> has canceled Julien Chaffraix
<jchaffraix at webkit.org>'s request for review:
Bug 98832: Remove fast/events/attempt-scroll-with-no-scrollbars.html
https://bugs.webkit.org/show_bug.cgi?id=98832

Attachment 168831: Proposed removal
https://bugs.webkit.org/attachment.cgi?id=168831&action=review

------- Additional Comments from Julien Chaffraix <jchaffraix at webkit.org>
View in context: https://bugs.webkit.org/attachment.cgi?id=168831&action=review


>> LayoutTests/ChangeLog:10
>> +	    of knowledge available nowadays) but keeping this test forever
failing doesn't help any port.
> 
> I don’t think the “limited knowledge available nowadays” part of this is
right.
> 
> All there is to the history here, I believe, is that Alice Barraclough
discovered that you can scroll a scrollbars=no window with window.scrollTo even
though you can’t scroll it with the scrollbars or scroll wheel. She created
this test case to demonstrate the problem and filed an internal Apple bug
report about it.
> 
> Looking back on it, I think it would have been better to have this with
expected results showing the failure, rather than as a skipped test. But I also
think that we can decide at this point to decide to not treat this as a bug. At
one point, Dan Bernstein pointed out that other browsers (at least Firefox 3)
allow the window.scrollTo and so it’s not clear it’s a problem that WebKit
allows it too.
> 
> So I think it’s OK for us to remove this test as part of deciding not to
treat it as a bug. Or it would be OK to keep the test and land the expected
failure instead of skipping this test on every port. Running the test with an
expected result, even one that reflects what is possibly a problem, does have
value. It documents our behavior, helps us notice if we change it
unintentionally.

The test didn't really give information about what it's testing. You could
obviously infer what was going on from the test case but that's a stretch. Also
the only resource to help explain that was the rdar link which is unavailable
to most people.

You are right that I should have done my research more thoroughly about whether
it was passing on other browsers. I just did and no browser matches the
behavior tested by this test case:
* IE & WebKit scrolls to 100.
* Firefox scrolls to 42.
* Opera (FWIW) scrolls to 23.

Based on that, we could change the expectations to assert that we do scroll and
treat the original report as a non-bug.