the software centre flash

Bug #965093 reported by longgangfan
28
This bug affects 3 people
Affects Status Importance Assigned to Milestone
software-center (Ubuntu)
Fix Released
Low
Natalia Bidart

Bug Description

when I select a software in the software centre and click the button "install", the software centre and all the desktop will flash. I don't know why.

SRU TEST CASE:
1. Launch the current Ubuntu Software Center in Precise.
2. Watch the lobby view after launch. After about 10-15 seconds, notice that the view "flashes" a white screen for a very short moment.
4. Close Ubuntu Software Center.
5. Update to the version of software-center in precise-proposed.
6. Launch Ubuntu Software Center again and watch the lobby view. Verify that there is no longer a "flash" in the view after about 10-15 seconds.

SRU REGRESSION POTENTIAL:
Regression risk is very small and would likely be little more than a tiny, still-noticaeable "flash" in the UI after the 10-15 second period.

Related branches

Revision history for this message
Daniel Lawrence (dannyla) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better.

Please execute the following command, as it will automatically gather debugging information, in a terminal:

apport-collect 965093

When reporting bugs in the future please use apport by using 'ubuntu-bug' and the name of the package affected. You can learn more about this functionality at https://wiki.ubuntu.com/ReportingBugs.

affects: ubuntu-sso-client (Ubuntu) → software-center (Ubuntu)
Changed in software-center (Ubuntu):
status: New → Incomplete
Revision history for this message
Dave Morley (davmor2) wrote :

There is a very minor flash of USC alone when the install progress bar appears, like the page is redrawn.

Changed in software-center (Ubuntu):
status: Incomplete → Confirmed
Michael Vogt (mvo)
Changed in software-center (Ubuntu):
importance: Undecided → Low
Dave Morley (davmor2)
tags: added: ca-escalated
Revision history for this message
Michael Vogt (mvo) wrote :

This happens when the update-software-center-agent finishes, you will see on th terminal:
2012-04-19 16:23:48,484 - softwarecenter.ui.gtk3.app - INFO - software-center-agent finished with status 0

when this happens. We need to investigate why we refresh the entire UI its certainly not needed to refresh e.g. the banners :)

Changed in software-center (Ubuntu):
assignee: nobody → Natalia Bidart (nataliabidart)
status: Confirmed → In Progress
Revision history for this message
Natalia Bidart (nataliabidart) wrote :

Once the db is reopened, 'reopen' signal is emitted and the following callbacks are executed:

softwarecenter/ui/gtk3/panes/availablepane.py(601)on_db_reopen()
-> self.refresh_apps()

the call above will set the whole SC screen (except for the toolbar) to white. This is caused by the call:

    415 self.show_appview_spinner()

and later (on_query_complete):

    285 self.hide_appview_spinner()

The same happens if the user is in the installed pane, when the callback for db_reopen does:

    652 self._build_categorised_installedview(keep_state)

(which shows and hides a spinner).

Michael, would it be safe to remove the showing and hiding of the spinner?

Revision history for this message
Michael Vogt (mvo) wrote :

Hello Natalia,

sorry for my slow reply and thanks a bunch for your analysis. The spinner is intended to only "unmask" itself when there
is a operation that takes a certain amount of time. The refresh is very quick so ideally it would be below this threshold.

The spinner is implemented as a "SpinnerNotebook" in ui/gtk3/widgets/spinner.py". Check the "show_spinner()" and
"hide_spinner()" and "_unmask_spinner()" code there. Unfortunately it appears like the implementation is buggy and
it will unconditionally switch to the notebook page with the spinner even if the operation is very quick.

I think the ideal fix is to ensure that the notebook page is only changed when the timeout happens and also that the
timeout id is saved in show_spinner and removed in hide_spinner if the
timeout has not yet fired. The current timeout of 100ms is probably a bit low, would be nice to know if there is
research data for a better one, my gutfeeling is that ~250ms - 500ms is a better default. Plus a test for this new
code :)

I hope this helps getting started, if there are any questions or concerns with the approach, I'm happy to talk about it on irc
or mumble.

Changed in software-center (Ubuntu):
status: In Progress → Fix Committed
tags: removed: ca-escalated
description: updated
description: updated
Changed in software-center (Ubuntu):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

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