Ubuntu
mir package

Surface unocclussion is racy

Bug #1408168 reported by Robert Carr
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mir
Triaged
Medium
Unassigned
mir (Ubuntu)
Triaged
Medium
Unassigned

Bug Description

Consider the following scenario as I saw investigating: https://bugs.launchpad.net/mir/+bug/1407783

1. Two surfaces on top of eachother
2. Send an event to first surface, wait for received signal.
3. Hide first surface
4. Send an event to second surface

It turns out the second surface will not always receive the event! I found the root: ms::SurfaceStack::for_each is filtering by occlusion. So of course, if the second event is synthesized before the compositor feedback occludes the second surface the surface will not be presented to the input stack and the event will be dropped.

This behavior is unfortunately required by: https://bugs.launchpad.net/bugs/1359264

So in order to address CI failures I have added extra synchronization in the test (referenced in bug 1407783) however, this remains a race which could appear in real scenarios (albeit somewhat marginal scenarios).

See original description
Daniel van Vugt (vanvugt)
Changed in mir:
milestone: none → 0.10.0
assignee: nobody → Robert Carr (robertcarr)
importance: Undecided → Medium
status: New → In Progress
Daniel van Vugt (vanvugt)
Changed in mir:
status: In Progress → Triaged
milestone: 0.10.0 → none
assignee: Robert Carr (robertcarr) → nobody
description: updated
Revision history for this message
Michał Sawicz (saviq) wrote :

Syncing task from Mir.

Changed in mir (Ubuntu):
importance: Undecided → Medium
status: New → Triaged
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.