Unable to move back from storage to mirror screen when certain conditions are met

Bug #2060964 reported by Olivier Gayot
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
subiquity
Triaged
Low
Unassigned

Bug Description

when testing semi offline installs, I ended up triggering a bug which prevents the user from going back from the Storage screen.

The order of the screens is "... -> Mirror -> Refresh -> Storage -> ...".

After moving from Mirror to Storage, hitting Back moves us the Refresh page again ; which in certain circumstances does not display a UI and instead moves forward to the Storage screen automatically.

https://asciinema.org/a/gF5VuZxVdakZrQ72hmyvRj48P

Steps to reproduce:

* Do a fully offline install
* If the Refresh screen shows a "Contacting the snap store..." animation, let it timeout.
* Then press back when on the Storage screen
* Let the Refresh screen timeout again
* Then press back ... This time it looks like nothing happened, because the refresh screen moved us forward again.

This is affecting https://github.com/canonical/subiquity/pull/1968

Revision history for this message
Olivier Gayot (ogayot) wrote :

Presumably, this is the code that automatically moves forward when status.availability = RefreshCheckState.UNKNOWN:

https://github.com/canonical/subiquity/blob/979f546f27fb8cfbfe9d0ac4f763b86b49718d41/subiquity/ui/views/refresh.py#L165

Olivier Gayot (ogayot)
Changed in subiquity:
importance: Undecided → Medium
status: New → Triaged
importance: Medium → Low
Revision history for this message
Olivier Gayot (ogayot) wrote :

The right way to "skip" a screen is to raise the Skip exception from make_ui. That said we have no way to make a distinction between {"availability": "UNKNOWN"} as in "We are still checking" and {"availability": "UNKNOWN"} as in "We checked and we failed to find out" when we call /refresh with wait=False.

In the latter scenario, we need a call to /refresh?wait=True, which we can't really do as part of the make_ui call.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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