594374 - Opening Add-on detail view first flashes previously opened add-on page

Status: RESOLVED INACTIVE

(Toolkit :: Add-ons Manager, defect)

Description

[Fritz]

User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b6pre) Gecko/20100908 Firefox/4.0b6pre
Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b6pre) Gecko/20100908 Firefox/4.0b6pre

Opening Add-on detail view first flashes previously opened add-on page.  Maybe this is because opening of detailed view is called before contents of detailed view is refreshed?

Reproducible: Always

Steps to Reproduce:
1. Open Add-on manager
2. Open detailed view of first add-on
3. Go back to list view
4. Open detailed view of another add-on
Actual Results:  
You see the detail view of the first add-on, image included, flash on the screen before the second add-on detailed view is loaded.

Expected Results:  
Normal loading of the add-on

Comment 1

[(mostly gone) XtC4UaLL [:xtc4uall]]

I see this too for a few ms.

Comment 2

[Dave Townsend [:mossop]]

Bug 590218 is about styling, this is something else.

Comment 3

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Fallout from the various recent changes to detail view. Will fix up the styling of the "loading" message while I'm at it.

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+2] (away July 24th - August 16th)]

It's still visible but that fast, that it's hard to distinguish both versions.

Comment 5

[Blair McBride [:Unfocused] (UNAVAILABLE)]

(In reply to comment #4)
> It's still visible

Seems I fixed the main regression, but we've always cleared the loading message too early. We clear it once the async call completes, but before any of the UI is actually updated. Patch coming up.

Comment 6

[Blair McBride [:Unfocused] (UNAVAILABLE)]

(In reply to comment #5)
> but we've always cleared the loading message
> too early. We clear it once the async call completes, but before any of the UI
> is actually updated.

*sigh* Scratch that. Forgot the main loading attribute (which controls the visibility of the main content of the details view) is handled by the view manager now (which gets notified after all the UI is updated). gDetailsView.clearLoading() only clears the additional loading message - it doesn't show the main content anymore.

So as far as I can tell, this is indeed fixed. Tested manually by adding a forced delay in various parts of gDetailsView.show() and gDetailsView._updateView().

Comment 7

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Attachment: Test v1

This tests the problem that was solved in bug 601022.

Comment 8

[Dave Townsend [:mossop]]

Comment on attachment 495805 [details] [diff] [review]
Test v1

Slightly concerned over the racing timeouts here but it looks like they should only ever fire in order

Comment 9

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Had forgotten about this.. just rebased to get it landed, and the test is failing now. Gonna investigate sometime this week.

Comment 10

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.