584693 - "Get Add-ons" pane in Add-ons Tab shows web page of http://www.mozilla.org/, when the manager reopened. And reload(F5) displays http://www.mozilla.org/ once and then displays correct page

Status: VERIFIED FIXED

(Toolkit :: Add-ons Manager, defect)

Description

[Alice0775 White]

User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b4pre) Gecko/20100805 Minefield/4.0b4pre ID:20100805041002
Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b4pre) Gecko/20100805 Minefield/4.0b4pre ID:20100805041002

When I re-open Add-ons Manager,
"Get Add-ons" pane shows web page of http://www.mozilla.org/ .

It should be "Add on style. Add on function. Add features to Firefox...."( https://services.addons.mozilla.org/en-US/firefox/discovery/4.0b4pre/WINNT.....).

Reproducible: Always

Steps to Reproduce:
1. Start Minefield with new profile
2. Open Add-ons Manager (Alt > Tools > Add-ons)
3. Select "Get Add-ons" in left pane of the Add-ons Manager.
4. Close the Add-ons Manager.
5. Open Add-ons Manager again (Alt > Tools > Add-ons)

Actual Results:
 "Get Add-ons" pane shows web page of http://www.mozilla.org/

Expected Results:
 It should be "Add on style. Add on function. Add features to Firefox...."( https://services.addons.mozilla.org/en-US/firefox/discovery/4.0b4pre/WINNT.....).


Regression Window:
Works(But not persist document in the right pane):
http://hg.mozilla.org/mozilla-central/rev/1ac135c8a484
Mozilla/5.0 (Windows; Windows NT 6.1; WOW64; rv:2.0b3pre) Gecko/20100729 Minefield/4.0b3pre ID:20100729204651
Fails
http://hg.mozilla.org/mozilla-central/rev/92c3a3a02405
Mozilla/5.0 (Windows; Windows NT 6.1; WOW64; rv:2.0b3pre) Gecko/20100729 Minefield/4.0b3pre ID:20100729224559
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=1ac135c8a484&tochange=92c3a3a02405
Candidate Bug:
Bug 571598 - Allow XUL documents loaded in about urls to persist attributes

Comment 1

[Alice0775 White]

In addition to the Comment#0,

When I Reload(F5) any pane of Add-ons manager, A collect pane is displayed after http://www.mozilla.org/ page was displayed for an instant.

Comment 2

[Dave Townsend [:mossop]]

Side effect of persisting the selected pane yes. The code doesn't expect that view to be visible immediately.

Comment 4

[Dave Townsend [:mossop]]

David made the mistake of asking about this bug, now he can fix it

Comment 6

[Dave Townsend [:mossop]]

Attachment: patch rev 1

Sets the default homepage of the browser to about:blank and then attempts to go home from initialize if show has already been called. Also makes us only notify that the view has changed or initialized after the page loads.

Comment 7

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Comment on attachment 474266 [details] [diff] [review]
patch rev 1

>+  loaded: false,

Add a comment somewhere as to why this needs to be tracked - its not obvious that the pane can be shown before its finished initializing (in fact, its somewhat counter-intuitive).

>+      }
>+      else {

Nit: No newline.

Comment 8

[Dave Townsend [:mossop]]

Attachment: patch rev 2

Spinning back for another review. In testing I realised that this was breaking future tests that were relying on the initial view to be the extensions list. I've been over every browser chrome tests and made them open the extensions list if they weren't already selected an initial view somewhere so hopefully we won't hit this again.

Comment 9

[cmtalbert]

landed: http://hg.mozilla.org/mozilla-central/rev/898ac02c84b0

Comment 10

[u88484]

Haven't seen this issue today so marking verified fixed

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b7pre) Gecko/20100916 Firefox/4.0b7pre

Comment 11

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Verified fixed with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b7pre) Gecko/20100917 Firefox/4.0b7pre

Dave, do the automated tests cover all possible paths?

Comment 12

[Dave Townsend [:mossop]]

I believe so