Bug 144127

Summary:

Test compositing/scrolling/touch-scroll-to-clip.html fails in WK1

Product:

WebKit

Reporter:

Daniel Bates <dbates>

Component:

Layout and Rendering

Assignee:

Simon Fraser (smfr) <simon.fraser>

Status:

ASSIGNED ---

Severity:

Normal

CC:

ap, simon.fraser, webkit-bug-importer, zalan

Priority:

Keywords:

InRadar

Version:

528+ (Nightly build)

Hardware:

Mac

OS:

OS X 10.10

Attachments:

Description	Flags
touch-scroll-to-clip.html test results archive	none

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.