Reland "ash: Dismantle crosapi's cros_display_config.mojom, part 1" [chromium/src : main]
Georg Neis (Gerrit)
New activity on the change![]( "Open in Gerrit")
Related details
- Hidehiko Abe
Code-Coverage
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Hidehiko Abe (Gerrit)
Hidehiko Abe added 1 comment![]( "Open in Gerrit")
shortly). See crbug.com/489591497 for details. A proper fix is beingthe bug does not provide details of the failure scenarios. Could you update the bug to have more details accordingly?
Also, what is the proper fix you're planning to make? As discussed, IIUC, the timing issue is still there even if we post a task, IIRC...?
Related details
- Georg Neis
Code-Coverage
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Georg Neis (Gerrit)
Georg Neis added 1 comment![]( "Open in Gerrit")
shortly). See crbug.com/489591497 for details. A proper fix is beingthe bug does not provide details of the failure scenarios. Could you update the bug to have more details accordingly?
Also, what is the proper fix you're planning to make? As discussed, IIUC, the timing issue is still there even if we post a task, IIRC...?
Yeah, was planning to add a note to the bug. Done.
Also, what is the proper fix you're planning to make?
Something along the lines of what we discussed, i.e. adding an initial OnWillAddDisplay observation that lets observers (perhaps at most one) modify the display parameters.
As discussed, IIUC, the timing issue is still there even if we post a task, IIRC...?
By posting a task we are making sure that the policy component's display property change happens after all observers have been notified about the added display. That solves the concrete problem we ran into. It does not solve the fundamental problem that observers may depend on OnDisplayAdded firing before OnDisplayMetricsChanged while nothing enforces it, though I'm not aware of other current instances of it.
Related details
- Hidehiko Abe
Code-Coverage
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Hidehiko Abe (Gerrit)
Hidehiko Abe added 1 comment![]( "Open in Gerrit")
shortly). See crbug.com/489591497 for details. A proper fix is beingGeorg Neisthe bug does not provide details of the failure scenarios. Could you update the bug to have more details accordingly?
Also, what is the proper fix you're planning to make? As discussed, IIUC, the timing issue is still there even if we post a task, IIRC...?
Yeah, was planning to add a note to the bug. Done.
Also, what is the proper fix you're planning to make?
Something along the lines of what we discussed, i.e. adding an initial OnWillAddDisplay observation that lets observers (perhaps at most one) modify the display parameters.
As discussed, IIUC, the timing issue is still there even if we post a task, IIRC...?
By posting a task we are making sure that the policy component's display property change happens after all observers have been notified about the added display. That solves the concrete problem we ran into. It does not solve the fundamental problem that observers may depend on OnDisplayAdded firing before OnDisplayMetricsChanged while nothing enforces it, though I'm not aware of other current instances of it.
- Georg Neis
Code-Coverage
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |