Hi, Tom, I found a place where we need to null check the browser in the permission dialog stack, or the browser would crash when clicking allow in the permission dialog. Not sure I'm the right person to bring it to the permission owners though, so ptal. Thx
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Commit-Queue | +2 |
Thanks for the catch - the null-check here is fine to land (owners are aware of our intent and changes and if we need to land fixes like this it's ok)
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
1 is the latest approved patch-set.
No files were changed between the latest approved patch-set and the submitted one.
Guard against null Browser in PermissionPromptBubbleBaseView
PermissionPromptBubbleBaseView::RunButtonCallback() passed the result of
GetBrowser() straight into BrowserView::GetBrowserViewForBrowser(),
which dereferences its argument. GetBrowser() returns null for
permission promptswhose host is not backed by a Browser (for example a
standalone Document Picture-in-Picture window), so clicking a prompt
button crashed with a null dereference before the code could reach the
fallback path that drives the delegate directly.
Skip the BrowserView lookup when there is no Browser. The existing
`browser_view &&` guard then bypasses the toolbar-chip path and the
prompt decision is propagated to the delegate via the direct Accept/Deny
switch.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |