| Commit-Queue | +1 |
Hey Solomon! Could you please help with a review of this change? 😊
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Hi Devlin, Solomon seems to be unavailable. Could you please help with this one? 😊
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Fix by:Is it possible to write a test, or is there already test coverage?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Hi Devlin, Solomon seems to be unavailable. Could you please help with this one? 😊
Solomon seems to be on it; I'll take a pass after him (it can sometimes take us a day or so to get to a CL). Please add me back to the attention set then.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Is it possible to write a test, or is there already test coverage?
Thanks for the suggestion, Solomon! I looked into adding a regression unit test, but I don't think a meaningful one is possible.
A runtime test would have to call `DispatchOnInstalledEvent` with a `MayBeDangling<void>` argument and then destroy the underlying `BrowserContext` before the task runs. But `MayBeDangling<T>` opts the pointer out of the dangling-ptr check by design, so such a test would never crash. It would always pass without exercising the bug.
We can't substitute `base::Unretained` to force the check either: the bind machinery rejects it at compile time for `MayBeDangling<void>` parameters, and even if it didn't, it would misrepresent the call site because production code does not pass an unretained pointer here.
Correctness is guaranteed at compile time by the `MayBeDangling<void>` parameter type: every caller is forced to use `base::UnsafeDangling()`, and a future regression in the signature would fail to compile rather than silently break at runtime.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |