RESOLVED FIXED213112
Remove WTF::setMainThreadCallbacksPaused
https://bugs.webkit.org/show_bug.cgi?id=213112
Summary Remove WTF::setMainThreadCallbacksPaused
Geoffrey Garen
Reported 2020-06-11 21:55:17 PDT
Remove WTF::setMainThreadCallbacksPaused
Attachments
Patch (4.32 KB, patch)
2020-06-11 21:59 PDT, Geoffrey Garen
thorton: review+
Patch for landing (4.29 KB, patch)
2020-06-23 16:41 PDT, Geoffrey Garen
no flags
Geoffrey Garen
Comment 1 2020-06-11 21:59:21 PDT
Simon Fraser (smfr)
Comment 2 2020-06-11 22:32:25 PDT
Comment on attachment 401706 [details] Patch What impact will removing this have on JS debugging? It's been there since 2010.
Tim Horton
Comment 3 2020-06-11 23:04:41 PDT
Comment on attachment 401706 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=401706&action=review > Source/WTF/ChangeLog:16 > + even queue. That should suspend JavaScript-visible stuff without s/even/event/ Also... if we can really do this, why don't we use this for JS-synchronous-but-ideally-not-engine-synchronous things like alert()?
Geoffrey Garen
Comment 4 2020-06-12 09:38:18 PDT
> Also... if we can really do this, why don't we use this for > JS-synchronous-but-ideally-not-engine-synchronous things like alert()? Use... what? :P alert() still needs to run a nested run loop or a sync IPC because it's not possible to tear down the whole stack and return to the main run loop -- that's not currently a feature of C++ or of the JS engine. Also, the debugger intends to allow a little more continuing execution than alert(). For example, the debugger intends to allow scrolling, selection, re-layout, and nested JS execution, and alert() does not.
Tim Horton
Comment 5 2020-06-12 10:03:32 PDT
Aha! Ok, makes sense.
Geoffrey Garen
Comment 6 2020-06-12 10:18:12 PDT
> What impact will removing this have on JS debugging? It's been there since > 2010. This code is all about how WebCore behaves when stopped at a breakpoint. Some edge case oddities will be fixed. For example, large images will be able to paint now. If I've overlooked something, some JS code will still run. So, you won't be as stopped as you wanted to be. The good news is, we can find and fix that kind of bug by migrating the code to the explicit JS event queue, which is much more reliable than just pausing all scheduled main thread code, including non-JS code. All of this being said, EWS says I did break a WK2 inspector test. Time for some fun debugging.
Geoffrey Garen
Comment 7 2020-06-12 16:38:26 PDT
> All of this being said, EWS says I did break a WK2 inspector test. Time for > some fun debugging. Actually, that inspector test was broken by r262904, not this patch. So, back up for review.
Geoffrey Garen
Comment 8 2020-06-23 16:38:41 PDT
Re-testing rdar://problem/14133001 still passes.
Geoffrey Garen
Comment 9 2020-06-23 16:41:56 PDT
Created attachment 402607 [details] Patch for landing
EWS
Comment 10 2020-06-23 17:27:48 PDT
Committed r263432: <https://trac.webkit.org/changeset/263432> All reviewed patches have been landed. Closing bug and clearing flags on attachment 402607 [details].
Radar WebKit Bug Importer
Comment 11 2020-06-23 17:28:17 PDT
Note You need to log in before you can comment on or make changes to this bug.