WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
ASSIGNED
144127
Test compositing/scrolling/touch-scroll-to-clip.html fails in WK1
https://bugs.webkit.org/show_bug.cgi?id=144127
Summary
Test compositing/scrolling/touch-scroll-to-clip.html fails in WK1
Daniel Bates
Reported
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
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
View All
Add attachment
proposed patch, testcase, etc.
Alexey Proskuryakov
Comment 1
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) )
Simon Fraser (smfr)
Comment 2
2015-04-23 15:39:22 PDT
Looks like it's just different by scrollbar width (15px). Probably just needs an iOS-specific result.
Daniel Bates
Comment 3
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.
Daniel Bates
Comment 4
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
>.
Simon Fraser (smfr)
Comment 5
2015-04-23 15:50:30 PDT
This seems like a genuine failure (space for scrollbar remains when overflow:hidden is set).
Radar WebKit Bug Importer
Comment 6
2015-04-23 15:50:50 PDT
<
rdar://problem/20675864
>
Alexey Proskuryakov
Comment 7
2015-04-23 16:05:59 PDT
Marked as flaky in
r183226
.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug