In the case that the Layers tab isn't even enabled, we're still loading three.js. We should avoid loading it until the first time we show the Layers tab.
<rdar://problem/47832436>
Created attachment 375529 [details] Patch One possible "solution" that's quite hacky :|
Comment on attachment 375529 [details] Patch Attachment 375529 [details] did not pass win-ews (win): Output: https://webkit-queues.webkit.org/results/12863904 New failing tests: fast/block/float/float-with-anonymous-previous-sibling.html
Created attachment 375535 [details] Archive of layout-test-results from ews212 for win-future The attached test failures were seen while running run-webkit-tests on the win-ews. Bot: ews212 Port: win-future Platform: CYGWIN_NT-10.0-17763-3.0.5-338.x86_64-x86_64-64bit
Comment on attachment 375529 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=375529&action=review > Source/WebInspectorUI/UserInterface/Views/Layers3DContentView.js:149 > + request.open("GET", url, false); Note that the syncronous XHR on the main thread is already deprecated in Chrome and Firefox. If WebKit deprecates it, this would stop working.
Comment on attachment 375529 [details] Patch r=me on the general approach Is there some reason this can't be a fetch instead?
(In reply to Brian Burg from comment #6) > Is there some reason this can't be a fetch instead? `fetch` is async. The big "issue" with any attempt at lazy-loading something is that we need a way to basically block everything else (or queue it) until the lazy-loading is done. I'd tried prototyping something like this in the past for <https://webkit.org/b/172249>, but one of the issues I encountered was that there are SO many entry points to a tab (or it's main content view) that blocking/queuing them all is a tall order. In this case, thinking about it more, since THREE.js is only used in this file, I could create a local defer queue. I'll experiment and see.