Last Comment Bug 567956 - Sometimes inspector panels take up space in browser window as though they are a normal box
: Sometimes inspector panels take up space in browser window as though they are...
Status: RESOLVED FIXED
:
Product: Firefox
Classification: Client Software
Component: Developer Tools (show other bugs)
: Trunk
: x86_64 Windows 7
: -- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
: 570130 (view as bug list)
Depends on: 533714
Blocks:
  Show dependency treegraph
 
Reported: 2010-05-24 21:30 PDT by Blair McBride [:Unfocused] (UNAVAILABLE)
Modified: 2012-01-17 08:54 PST (History)
4 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Screenshot (308.24 KB, image/png)
2010-05-24 21:30 PDT, Blair McBride [:Unfocused] (UNAVAILABLE)
no flags Details

Description Blair McBride [:Unfocused] (UNAVAILABLE) 2010-05-24 21:30:19 PDT
Created attachment 447272 [details]
Screenshot

Sometimes, the highlighter-pane and inspector-panel panels will take up space in the browser window. Their contents are not visible, but the panels take up space as though they're normal XUL boxes (rather than panels/popups). The mainPopupSet expands to make room for them, creating a large empty space above the Menu Bar (see attached screenshot). Adding a hidden="true" attribute to these panels will fix the described symptoms.

I haven't found a way to reliably reproduce this. It's happened a couple of times when I've switched back to a Firefox window or after I've been logged in via RDP, but that may be a coincidence.
Comment 1 Philip Chee 2010-05-24 21:53:30 PDT
Known XUL bug. using hidden="true" is the current workaround used in other similar problems. But I thought Enn fixed this on trunk.
Comment 2 Rob Campbell [:rc] (:robcee) 2010-05-25 04:54:21 PDT
yeah, that's an odd one. I've seen something similar when hitting the "capsule" button in an OS X titlebar. I'll try the mentioned workaround.
Comment 3 Blair McBride [:Unfocused] (UNAVAILABLE) 2010-05-25 06:11:10 PDT
(In reply to comment #1)
> Known XUL bug. using hidden="true" is the current workaround used in other
> similar problems. But I thought Enn fixed this on trunk.

Interestingly, doing this should also improve startup time, since the XBL bindings won't get attached until the popup is shown (we discovered this with Ubiquity - it also fixed a bunch of other weirdness). So it may be a good thing to do even if the underlying popup problem is fixed.
Comment 4 Rob Campbell [:rc] (:robcee) 2010-05-25 07:07:23 PDT
I thought I was doing this and forgot that the style and dom panels haven't landed yet.

http://mxr.mozilla.org/mozilla-central/source/browser/base/content/browser.xul#223

I'm already setting that attribute on both panels and setting the attribute to false on initialization:

http://mxr.mozilla.org/mozilla-central/source/browser/base/content/inspector.js#535

Any ideas?
Comment 5 Philip Chee 2010-05-25 07:55:48 PDT
Nope, sorry. That's the way the other panels in browser.xul do it.
Comment 6 Rob Arnold [:robarnold] 2010-06-04 07:38:21 PDT
*** Bug 570130 has been marked as a duplicate of this bug. ***
Comment 7 Kevin Dangoor 2012-01-13 07:55:03 PST
I think this bug is no longer relevant. Can we close it?
Comment 8 Rob Campbell [:rc] (:robcee) 2012-01-17 08:54:43 PST
We believe this is fixed. Reopen if necessary.

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