WebKit Bugzilla
New
Browse
Search+
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
213112
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+
Details
Formatted Diff
Diff
Patch for landing
(4.29 KB, patch)
2020-06-23 16:41 PDT
,
Geoffrey Garen
no flags
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Geoffrey Garen
Comment 1
2020-06-11 21:59:21 PDT
Created
attachment 401706
[details]
Patch
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
<
rdar://problem/64673032
>
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug