Bug 144127 - Test compositing/scrolling/touch-scroll-to-clip.html fails in WK1
Summary: Test compositing/scrolling/touch-scroll-to-clip.html fails in WK1
Status: ASSIGNED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: 528+ (Nightly build)
Hardware: Mac OS X 10.10
: P2 Normal
Assignee: Simon Fraser (smfr)
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2015-04-23 15:20 PDT by Daniel Bates
Modified: 2015-04-23 16:05 PDT (History)
4 users (show)

See Also:


Attachments
touch-scroll-to-clip.html test results archive (5.44 KB, application/zip)
2015-04-23 15:20 PDT, Daniel Bates
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Bates 2015-04-23 15:20:47 PDT
Created attachment 251499 [details]
touch-scroll-to-clip.html test results archive

The test compositing/scrolling/touch-scroll-to-clip.html fails in DumpRenderTree (*). I am using a debug build of WebKit r183016 on OS X Yosemite (14D136) using a Mac Pro with 2.7 GHz 12-Core Intel Xeon E5, 32 GB 1866 MHz DDR3 ECC and AMD FirePro D300 2048 MB.

For some reason, I do not see the same failure on the Yosemite WK1 Test bots. Though the Mac EWS remarked about the failing test when it ran tests with the patch for bug #144045, <https://webkit-queues.appspot.com/results/5769191860731904>. The results were uploaded to the bug in attachment #251334 [details]. For convenience, I've attached an archive with only the results of the test touch-scroll-to-clip.html to this bug.

(*) Tools/Scripts/run-webkit-tests --debug -1 compositing/scrolling/touch-scroll-to-clip.html
Comment 1 Alexey Proskuryakov 2015-04-23 15:38:52 PDT
Initially, I suspected that this could be an ATI specific issue (because EWS bots also have ATI graphics, and regular bots have Intel). But looks like this is a flaky test, I can reproduce that on a MacBook Pro with Nvidia graphics like this:

run-webkit-tests --debug -1 compositing/scrolling/touch-scroll-to-clip.html --repeat 100 -f --no-retry --no-show

                 (GraphicsLayer
-                  (anchor 0.50 0.50)
-                  (bounds 265.00 500.00)
+                  (bounds 280.00 500.00)
                   (contentsOpaque 1)
                 )
Comment 2 Simon Fraser (smfr) 2015-04-23 15:39:22 PDT
Looks like it's just different by scrollbar width (15px). Probably just needs an iOS-specific result.
Comment 3 Daniel Bates 2015-04-23 15:41:11 PDT
(In reply to comment #2)
> Looks like it's just different by scrollbar width (15px). Probably just
> needs an iOS-specific result.

Notice that the test failed on Mac EWS.
Comment 4 Daniel Bates 2015-04-23 15:44:03 PDT
(In reply to comment #3)
> (In reply to comment #2)
> > Looks like it's just different by scrollbar width (15px). Probably just
> > needs an iOS-specific result.
> 
> Notice that the test failed on Mac EWS.

For completeness, the test is marked as failing in WK1 for iOS according to <http://trac.webkit.org/browser/trunk/LayoutTests/platform/ios-simulator-wk1/TestExpectations?rev=183154#L1020>.
Comment 5 Simon Fraser (smfr) 2015-04-23 15:50:30 PDT
This seems like a genuine failure (space for scrollbar remains when overflow:hidden is set).
Comment 6 Radar WebKit Bug Importer 2015-04-23 15:50:50 PDT
<rdar://problem/20675864>
Comment 7 Alexey Proskuryakov 2015-04-23 16:05:59 PDT
Marked as flaky in r183226.