This applies currently to WebKitMediaSession, IDBDatabase, IDBRequest, MediaDevices and ActiveDOMObjects using setPendingActivity/unsetPendingActivity.
Created attachment 348217 [details] WIP
Comment on attachment 348217 [details] WIP Attachment 348217 [details] did not pass bindings-ews (mac): Output: https://webkit-queues.webkit.org/results/9001574 New failing tests: (JS) JSTestInterface.cpp (JS) JSTestNamedConstructor.cpp
Comment on attachment 348217 [details] WIP Attachment 348217 [details] did not pass mac-debug-ews (mac): Output: https://webkit-queues.webkit.org/results/9002727 Number of test failures exceeded the failure limit.
Created attachment 348243 [details] Archive of layout-test-results from ews114 for mac-sierra The attached test failures were seen while running run-webkit-tests on the mac-debug-ews. Bot: ews114 Port: mac-sierra Platform: Mac OS X 10.12.6
Comment on attachment 348217 [details] WIP Attachment 348217 [details] did not pass win-ews (win): Output: https://webkit-queues.webkit.org/results/9003673 New failing tests: http/tests/navigation/page-cache-xhr.html http/tests/xmlhttprequest/xhr-response-constructor-subframe.html
Created attachment 348249 [details] Archive of layout-test-results from ews202 for win-future The attached test failures were seen while running run-webkit-tests on the win-ews. Bot: ews202 Port: win-future Platform: CYGWIN_NT-6.1-2.10.0-0.325-5-3-x86_64-64bit
Comment on attachment 348217 [details] WIP What happens in the back-forward cache? Is the document considered stopped in that case? If so, how do you avoid GC?
(In reply to Geoffrey Garen from comment #7) > Comment on attachment 348217 [details] > WIP > > What happens in the back-forward cache? Is the document considered stopped > in that case? If so, how do you avoid GC? No, state is suspended while in page cache, not stopped.
(In reply to Chris Dumez from comment #8) > (In reply to Geoffrey Garen from comment #7) > > Comment on attachment 348217 [details] > > WIP > > > > What happens in the back-forward cache? Is the document considered stopped > > in that case? If so, how do you avoid GC? > > No, state is suspended while in page cache, not stopped. As in we call suspend() on the active dom objects before entering page cache, never stop(). Stop() is only called when the script execution context is about to be destroyed.
Comment on attachment 348217 [details] WIP View in context: https://bugs.webkit.org/attachment.cgi?id=348217&action=review > Source/WebCore/dom/ScriptExecutionContext.h:133 > + virtual bool isStopped() = 0; There is already ScriptExecutionContext::activeDOMObjectsAreStopped()
Created attachment 348937 [details] Patch
Comment on attachment 348937 [details] Patch Attachment 348937 [details] did not pass win-ews (win): Output: https://webkit-queues.webkit.org/results/9104756 New failing tests: http/tests/navigation/page-cache-xhr.html http/tests/xmlhttprequest/xhr-response-constructor-subframe.html
Created attachment 348960 [details] Archive of layout-test-results from ews203 for win-future The attached test failures were seen while running run-webkit-tests on the win-ews. Bot: ews203 Port: win-future Platform: CYGWIN_NT-6.1-2.9.0-0.318-5-3-x86_64-64bit
Comment on attachment 348937 [details] Patch Attachment 348937 [details] did not pass win-ews (win): Output: https://webkit-queues.webkit.org/results/9105570 New failing tests: http/tests/navigation/page-cache-xhr.html http/tests/xmlhttprequest/xhr-response-constructor-subframe.html
Created attachment 348963 [details] Archive of layout-test-results from ews200 for win-future The attached test failures were seen while running run-webkit-tests on the win-ews. Bot: ews200 Port: win-future Platform: CYGWIN_NT-6.1-2.9.0-0.318-5-3-x86_64-64bit
Comment on attachment 348937 [details] Patch This has been requesting review for more than one year. If this is still needed, please rebase and re-request review.