<rdar://problem/33046992>
Created attachment 314437 [details] Patch
<rdar://problem/33101038>
Comment on attachment 314437 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=314437&action=review > Source/WebCore/ChangeLog:13 > + be read back as NSURLs for "public.url". This currently causes bugs shipping software: e.g. copying and pasting Bugs shipping software
Comment on attachment 314437 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=314437&action=review Thanks Tim! >> Source/WebCore/ChangeLog:13 >> + be read back as NSURLs for "public.url". This currently causes bugs shipping software: e.g. copying and pasting > > Bugs shipping software Good catch -- fixed.
Comment on attachment 314437 [details] Patch Attachment 314437 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://webkit-queues.webkit.org/results/4040879 New failing tests: workers/bomb.html
Created attachment 314441 [details] Archive of layout-test-results from ews106 for mac-elcapitan-wk2 The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews. Bot: ews106 Port: mac-elcapitan-wk2 Platform: Mac OS X 10.11.6
(In reply to Build Bot from comment #6) > Created attachment 314441 [details] > Archive of layout-test-results from ews106 for mac-elcapitan-wk2 > > The attached test failures were seen while running run-webkit-tests on the > mac-wk2-ews. > Bot: ews106 Port: mac-elcapitan-wk2 Platform: Mac OS X 10.11.6 Test failure looks unrelated -- this patch only affects iOS-specific code, and this is the Mac bot; also, the failing test doesn't appear to exercise pasting codepaths.
Also, I’ve seen that test failing on other EWS runs.
Created attachment 314453 [details] Patch for landing
The commit-queue encountered the following flaky tests while processing attachment 314453 [details]: imported/w3c/web-platform-tests/IndexedDB/idbindex-multientry-big.htm bug 174090 (author: youennf@gmail.com) The commit-queue is continuing to process your patch.
Comment on attachment 314453 [details] Patch for landing Clearing flags on attachment: 314453 Committed r219070: <http://trac.webkit.org/changeset/219070>
Comment on attachment 314437 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=314437&action=review > Tools/TestWebKitAPI/Tests/ios/UIPasteboardTests.mm:38 > +SOFT_LINK_FRAMEWORK(UIKit) Why is this needed here and not everywhere else TestWebKitAPI uses UIKit?
(In reply to mitz from comment #12) > Comment on attachment 314437 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=314437&action=review > > > Tools/TestWebKitAPI/Tests/ios/UIPasteboardTests.mm:38 > > +SOFT_LINK_FRAMEWORK(UIKit) > > Why is this needed here and not everywhere else TestWebKitAPI uses UIKit? This is here because we want to build for OpenSource and UIApplicationInitialize is SPI, but as you mentioned on IRC, there's a better (more canonical) way to accomplish this by introducing UIKitSPI.h.
This patch caused an API test failure on iOS consistently with the test: UIPasteboardTests.DoNotPastePlainTextAsURL https://build.webkit.org/builders/Apple%20iOS%2010%20Simulator%20Release%20WK2%20(Tests)/builds/2741 https://build.webkit.org/builders/Apple%20iOS%2010%20Simulator%20Release%20WK2%20(Tests)/builds/2741/steps/run-api-tests/logs/stdio
Reverted r219070 for reason: This revision caused consistent failures of the API test UIPasteboardTests.DoNotPastePlainTextAsURL on iOS. Committed r219128: <http://trac.webkit.org/changeset/219128>
The new unit test uses a codepath that depends on -[UIPasteboard itemProviders] which is available on iOS 11+, so this isn't going to pass on the OpenSource bots, which are still on iOS 10. Furthermore, this is passing consistently on the internal bots on build-safari. These tests just need to be guarded by iOS 11+.
Reverted r219128 for reason: Spoke with engineer who originally submitted, Patch for APi test to follow. Committed r219129: <http://trac.webkit.org/changeset/219129>
Guarded the failing test in https://trac.webkit.org/r219131.