RESOLVED FIXED 199925
Web Inspector: Page: mark any WebCore::Setting inspector override as UNLIKELY
https://bugs.webkit.org/show_bug.cgi?id=199925
Summary Web Inspector: Page: mark any WebCore::Setting inspector override as UNLIKELY
Devin Rousso
Reported 2019-07-18 17:46:55 PDT
This way, if the inspector crashes, we don't still use the overridden settings value.
Attachments
Patch (2.12 KB, patch)
2019-07-18 17:52 PDT, Devin Rousso
no flags
Patch (2.10 KB, patch)
2019-07-22 11:40 PDT, Devin Rousso
no flags
Devin Rousso
Comment 1 2019-07-18 17:52:59 PDT
Joseph Pecoraro
Comment 2 2019-07-18 20:51:16 PDT
Comment on attachment 374433 [details] Patch Ideally this is already always nullopt if there is no inspector frontend, right? Maybe we should just ASSERT(InspectorInstrumentation::hasFrontends()) inside the if.
Joseph Pecoraro
Comment 3 2019-07-18 20:52:17 PDT
(In reply to Devin Rousso from comment #0) > This way, if the inspector crashes, we don't still use the overridden > settings value. Shouldn't the InspectorPageAgent have cleaned up after itself in: void InspectorPageAgent::willDestroyFrontendAndBackend(Inspector::DisconnectReason) { ErrorString unused; disable(unused); } Which should set all override values to nullopt.
Devin Rousso
Comment 4 2019-07-18 21:31:22 PDT
(In reply to Joseph Pecoraro from comment #3) > (In reply to Devin Rousso from comment #0) > > This way, if the inspector crashes, we don't still use the overridden settings value. > > Shouldn't the InspectorPageAgent have cleaned up after itself in: > > void > InspectorPageAgent::willDestroyFrontendAndBackend(Inspector::DisconnectReason) > { > ErrorString unused; > disable(unused); > } > > Which should set all override values to nullopt. Yes, but what about if the inspector crashes? We could potentially end up in a state where the override didn't get removed. Due to the potentially sensitive nature of some of these settings (e.g. CORS), this is an added precaution.
Joseph Pecoraro
Comment 5 2019-07-22 11:18:02 PDT
(In reply to Devin Rousso from comment #4) > (In reply to Joseph Pecoraro from comment #3) > > (In reply to Devin Rousso from comment #0) > > > This way, if the inspector crashes, we don't still use the overridden settings value. > > > > Shouldn't the InspectorPageAgent have cleaned up after itself in: > > > > void > > InspectorPageAgent::willDestroyFrontendAndBackend(Inspector::DisconnectReason) > > { > > ErrorString unused; > > disable(unused); > > } > > > > Which should set all override values to nullopt. > Yes, but what about if the inspector crashes? If the: • Inspected Page Web Content Process crashes - this state goes away and a new process will be spawned with its own WebCore::Settings • Inspector Web Content Process crashes - InspectorPageAgent::willDestroyFrontendAndBackend should run since a frontend went away • UIProcess Crashes - all of these processes go away Am I overlooking something?
Devin Rousso
Comment 6 2019-07-22 11:37:33 PDT
(In reply to Joseph Pecoraro from comment #5) > • Inspector Web Content Process crashes > - InspectorPageAgent::willDestroyFrontendAndBackend should run since a frontend went away Oh, I didn't know we did that =D In that case, I agree that this isn't "necessary". I'll change it to just be an `ASSERT`.
Devin Rousso
Comment 7 2019-07-22 11:40:55 PDT
Joseph Pecoraro
Comment 8 2019-07-22 12:37:54 PDT
Comment on attachment 374615 [details] Patch r=me
WebKit Commit Bot
Comment 9 2019-07-22 12:46:10 PDT
Comment on attachment 374615 [details] Patch Clearing flags on attachment: 374615 Committed r247697: <https://trac.webkit.org/changeset/247697>
WebKit Commit Bot
Comment 10 2019-07-22 12:46:12 PDT
All reviewed patches have been landed. Closing bug.
Radar WebKit Bug Importer
Comment 11 2019-07-22 12:47:50 PDT
Note You need to log in before you can comment on or make changes to this bug.