Closed Bug 617325 Opened 14 years ago Closed 14 years ago

With "Get Add-ons" category selected, toolbars are visible when opening the add-ons manager

Categories

(Toolkit :: Add-ons Manager, defect)

Product:
Toolkit
Component:
Add-ons Manager
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla2.0b9
Tracking Flags:
Tracking Status
blocking2.0 --- final+

People

(Reporter: aaronmt, Assigned: mossop)

References

Details

Attachments

(1 file)

patch rev 1
5.20 KB, patch
Gavin
: review+
Details | Diff | Splinter Review 
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b8pre) Gecko/20101207 Firefox/4.0b8pre

When opening up the add-ons manager, chrome components (navigation toolbar) will appear in the browser after a short delay while the manager is loading.

STR
1. Create a new profile.
2. Open the Add-ons Manager. 

The navigation toolbar will appear once the manager is loaded.
This only happens when we open the add-ons manager with "get add-ons" selected.
OS: Mac OS X → All
Hardware: x86 → All
Summary: Chrome still visible on opening of add-ons manager → With "Get Add-ons" category selected, toolbars are visible when opening the add-ons manager
Mozilla/5.0 (Windows NT 6.0; rv:2.0b8pre) Gecko/20101207 Firefox/4.0b8pre

Confirmed.
blocking2.0: --- → ?
Looks like the main browser progress listener is magically getting the onLocationChange event from the inner frame which is sorta broken.
blocking2.0: ? → final+
Randomly wondering if this is related to bug 602256
Confirmed, the webprogress listener in browser.js which is registered on the tabbrowser (and so basically receives the webprogress events for the visible browser) is getting an onLocationChange for the url in the inner-browser in the add-ons manager. This doesn't sound right from what I understand but maybe it is normal?
Blocks: 617482
No longer blocks: 617482
web progress listeners get notifications for all location changes in the docshell tree rooted at the place they're registered, no?  In particular, see the comment at http://hg.mozilla.org/mozilla-central/file/d2f3fcf3b1db/browser/base/content/tabbrowser.xml#l555
Ah I wasn't aware of that. Easily solved then
Assignee: nobody → dtownsend
Whiteboard: [has patch][waiting on try]
Test timed out on linux debug run
Whiteboard: [has patch][waiting on try] → [has patch]
Yeah, the code added to browser.js's onLocationChange should be inside the aWebProgress.DOMWindow==content block.
Attached patch patch rev 1 — — Splinter Review 

        Attachment #497594 -
        Flags: review?(gavin.sharp)

    
  
Whiteboard: [has patch] → [has patch][needs review gavin]

        Attachment #497594 -
        Flags: review?(gavin.sharp) → review+
Whiteboard: [has patch][needs review gavin] → [has patch]

    
    

    
  
Landed: http://hg.mozilla.org/mozilla-central/rev/faf2e261308f
Status: NEW → RESOLVED
Closed: 14 years ago
Flags: in-testsuite+
Flags: in-litmus-
Resolution: --- → FIXED
Whiteboard: [has patch]
Target Milestone: --- → mozilla2.0b9

    
    

    
  
Verified fixed with  Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b9pre) Gecko/20101217 Firefox/4.0b9pre ID:20101217030324
Status: RESOLVED → VERIFIED

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: