Have navigator.serviceWorker() actually return a ServiceWorkerContainer object
Created attachment 317303 [details] Patch
Comment on attachment 317303 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=317303&action=review > Source/WebCore/workers/ServiceWorkerContainer.cpp:66 > + rejectLater(WTFMove(promise), "ready"); It seems unnecessary to reject later, why not doing it now?
(In reply to youenn fablet from comment #2) > Comment on attachment 317303 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=317303&action=review > > > Source/WebCore/workers/ServiceWorkerContainer.cpp:66 > > + rejectLater(WTFMove(promise), "ready"); > > It seems unnecessary to reject later, why not doing it now? My experience with promises in our bindings is minimal - Do we definitely properly handle synchronous responses to promises in all cases? I assumed the answer is "no" so I didn't go that route. I'm not particularly concerned about this as this is true early scaffolding code. It will go away shortly!
> My experience with promises in our bindings is minimal - Do we definitely > properly handle synchronous responses to promises in all cases? Yes, this is correctly handled.
Comment on attachment 317303 [details] Patch Attachment 317303 [details] did not pass mac-ews (mac): Output: http://webkit-queues.webkit.org/results/4255811 New failing tests: imported/w3c/web-platform-tests/FileAPI/historical.https.html
Created attachment 317308 [details] Archive of layout-test-results from ews102 for mac-elcapitan The attached test failures were seen while running run-webkit-tests on the mac-ews. Bot: ews102 Port: mac-elcapitan Platform: Mac OS X 10.11.6
Comment on attachment 317303 [details] Patch Attachment 317303 [details] did not pass mac-debug-ews (mac): Output: http://webkit-queues.webkit.org/results/4255854 New failing tests: imported/w3c/web-platform-tests/FileAPI/historical.https.html
Created attachment 317316 [details] Archive of layout-test-results from ews113 for mac-elcapitan The attached test failures were seen while running run-webkit-tests on the mac-debug-ews. Bot: ews113 Port: mac-elcapitan Platform: Mac OS X 10.11.6
Comment on attachment 317303 [details] Patch Attachment 317303 [details] did not pass ios-sim-ews (ios-simulator-wk2): Output: http://webkit-queues.webkit.org/results/4255925 New failing tests: http/tests/security/cross-origin-indexeddb.html
Created attachment 317317 [details] Archive of layout-test-results from ews122 for ios-simulator-wk2 The attached test failures were seen while running run-webkit-tests on the ios-sim-ews. Bot: ews122 Port: ios-simulator-wk2 Platform: Mac OS X 10.12.5
(In reply to Build Bot from comment #9) > > Attachment 317303 [details] did not pass ios-sim-ews (ios-simulator-wk2): > > New failing tests: > http/tests/security/cross-origin-indexeddb.html Not caused by this.
(In reply to Build Bot from comment #7) > Comment on attachment 317303 [details] > Patch > > Attachment 317303 [details] did not pass mac-debug-ews (mac): > Output: http://webkit-queues.webkit.org/results/4255854 > > New failing tests: > imported/w3c/web-platform-tests/FileAPI/historical.https.html This one probably is! Looking...
(In reply to Brady Eidson from comment #12) > (In reply to Build Bot from comment #7) > > Comment on attachment 317303 [details] > > Patch > > > > Attachment 317303 [details] did not pass mac-debug-ews (mac): > > Output: http://webkit-queues.webkit.org/results/4255854 > > > > New failing tests: > > imported/w3c/web-platform-tests/FileAPI/historical.https.html > > This one probably is! Looking... Yup, WK1 results needed.
Created attachment 317322 [details] Patch
Comment on attachment 317322 [details] Patch Attachment 317322 [details] did not pass mac-ews (mac): Output: http://webkit-queues.webkit.org/results/4256709 New failing tests: imported/w3c/web-platform-tests/FileAPI/historical.https.html
Created attachment 317324 [details] Archive of layout-test-results from ews103 for mac-elcapitan The attached test failures were seen while running run-webkit-tests on the mac-ews. Bot: ews103 Port: mac-elcapitan Platform: Mac OS X 10.11.6
Since you might need to reupload a new patch, could you remove the rejectLater thing at the same time?
Comment on attachment 317322 [details] Patch Attachment 317322 [details] did not pass mac-debug-ews (mac): Output: http://webkit-queues.webkit.org/results/4256723 New failing tests: imported/w3c/web-platform-tests/FileAPI/historical.https.html
Created attachment 317325 [details] Archive of layout-test-results from ews114 for mac-elcapitan The attached test failures were seen while running run-webkit-tests on the mac-debug-ews. Bot: ews114 Port: mac-elcapitan Platform: Mac OS X 10.11.6
Created attachment 317326 [details] Patch for EWS/Landing
(In reply to Brady Eidson from comment #20) > Created attachment 317326 [details] > Patch for EWS/Landing Will CQ+ once EWS says 👍
Comment on attachment 317326 [details] Patch for EWS/Landing Clearing flags on attachment: 317326 Committed r220310: <http://trac.webkit.org/changeset/220310>
All reviewed patches have been landed. Closing bug.
<rdar://problem/33737977>
(In reply to youenn fablet from comment #17) > Since you might need to reupload a new patch, could you remove the > rejectLater thing at the same time? Ugh, sorry missed this in the middle of the layout test failure messages. As mentioned, they're not long for this world. Be gone soon.