Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Code-Review | +1 |
DCHECK(!delegate_);
I thought we were supposed to use `CHECK` instead of `DCHECK` nowadays?
void set_delegate(Delegate* delegate) {
Nit: Should this be `SetDelegate`?
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
DCHECK(!delegate_);
I thought we were supposed to use `CHECK` instead of `DCHECK` nowadays?
I don't think the guidance in https://chromium.googlesource.com/chromium/src/+/main/styleguide/c++/checks.md is very clear about this point. I can change it if you or Frank prefer CHECK.
void set_delegate(Delegate* delegate) {
Nit: Should this be `SetDelegate`?
I left this named using getter style naming, because it's essentially a getter. But if you or Frank prefer, I can rename it.
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Code-Review | +1 |
DCHECK(!delegate_);
Daniel ChengI thought we were supposed to use `CHECK` instead of `DCHECK` nowadays?
I don't think the guidance in https://chromium.googlesource.com/chromium/src/+/main/styleguide/c++/checks.md is very clear about this point. I can change it if you or Frank prefer CHECK.
This document says "Prefer CHECK() and NOTREACHED_NORETURN() as they ensure that if an invariant fails, the program does not continue in an unexpected state, and we hear about the failure either through a test failure or a crash report".
Having said that, Frank is OOO until next week. I'm fine landing it as is and come back to it if Frank prefers CHECK.
void set_delegate(Delegate* delegate) {
Daniel ChengNit: Should this be `SetDelegate`?
I left this named using getter style naming, because it's essentially a getter. But if you or Frank prefer, I can rename it.
I don't feel strongly about it. I tend to prefer consistency in this case but as said below. We can land as is and revisit if Frank feels like it.
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
DCHECK(!delegate_);
Daniel ChengI thought we were supposed to use `CHECK` instead of `DCHECK` nowadays?
FrI don't think the guidance in https://chromium.googlesource.com/chromium/src/+/main/styleguide/c++/checks.md is very clear about this point. I can change it if you or Frank prefer CHECK.
This document says "Prefer CHECK() and NOTREACHED_NORETURN() as they ensure that if an invariant fails, the program does not continue in an unexpected state, and we hear about the failure either through a test failure or a crash report".
Having said that, Frank is OOO until next week. I'm fine landing it as is and come back to it if Frank prefers CHECK.
I changed this to a CHECK(), though I combined them and added a comment for clarity.
void set_delegate(Delegate* delegate) {
Daniel ChengNit: Should this be `SetDelegate`?
FrI left this named using getter style naming, because it's essentially a getter. But if you or Frank prefer, I can rename it.
I don't feel strongly about it. I tend to prefer consistency in this case but as said below. We can land as is and revisit if Frank feels like it.
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. |
5 is the latest approved patch-set.
The change was submitted with unreviewed changes in the following files:
```
The name of the file: chrome/browser/picture_in_picture/auto_pip_setting_overlay_view.h
Insertions: 4, Deletions: 5.
The diff is too large to show. Please review the diff.
```
[MSan] Fix use-after-dtor in VideoOverlayWindowViews
VideoOverlayWindowViews observes the overlay view (if any). If the
overlay view is manually removed, VideoOverlayWindowViews unregisters
itself as an observer. However, if the VideoOverlayWindowViews is
destroyed without manually removing the overlay view, it never
unregisters itself. This results in a MSan use-after-dtor error, since:
- the overlay view is a child view
- destroying a view triggers observer calls
- but child views are not destroyed until the View base class is
destroyed
- and the ViewObserver base class is destroyed before the View base
class
While it would be easy to simply destroy the View base class before the
ViewObserver base class, dispatching observations at destruction is
pointless, since it will never call VideoOverlayWindowViews's
implementation.
Using ScopedObservation here is also a bit awkward; ScopedObservation
itself needs to store a pointer to the observee, which means
VideoOverlayWindowViews ends up with three (!!) pointers to the overlay
view: the raw_ptr, the ScopedObservation (as a ViewObserver), and the
ScopedObservation (as an AutoPipSettingOverlayViewObserver).
It is possible to simply get the pointer to the overlay view out of the
ScopedObservation, but the manual removal of the overlay view remains
awkward.
Instead, just add a conditional RemoveObserver() call in the destructor.
As a bonus, convert the ObserverList in AutoPipSettingOverlayView to
just use the delegate pattern: a given AutoPipSettingOverlayView only
ever has a single AutoPipSettingOverlayViewObserver at a time. This
makes it easier to unregister the ViewObserver, since the RemoveObserver
call no longer needs to be qualified.
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |