Victor Porof [:vporof][:vp] Reporter
	Description • 12 years ago

STR (assuming the window is in a docked state):

1. Open debugger on http://htmlpad.org/debugger/
2. Right click on line 9 and "Add conditional breakpoint"
3. Notice how a conditional expression popup appears in the breakpoints pane
4. Undock the window
5. Right click on line 10 and "Add conditional breakpoint"
-> The popup appears behind the window, making it unusable


Possibly related (more worrisome problem) STR (again, assuming the window is in a docked state):

1. Open debugger
2. Undock the window
3. Close the window
4. Open the debugger (the window should already be undocked by now)
5. Dock the window
6. Try to add a conditional breakpoint or focus the "Filter Scripts" textbox
-> No panels will ever be visible or accessible

	Paul Rouget [:paul]
	Comment 1 • 12 years ago

For STR 1, I can't reproduce on Linux.

For STR 2, I see the panel, but it's not correctly aligned.

	Paul Rouget [:paul]
	Comment 2 • 12 years ago

Actually, for STR 2, the alignment problem is not the real bug. The sidepanel didn't show up (so the panel had nothing to be aligned with).

	Paul Rouget [:paul]
	Comment 3 • 12 years ago

So I confirm STR 2, with this exception:

> Error: An error occurred updating the cmd_undo command: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMXULCommandDispatcher.getControllerForCommand]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: chrome://global/content/globalOverlay.js :: goUpdateCommand :: line 71"  data: no]
> Source File: chrome://global/content/globalOverlay.js
> Line: 81

But not STR 1.

In comment 1, when I said "panel" I meant "popup".

	Victor Porof [:vporof][:vp] Reporter
	Comment 4 • 12 years ago

This is what happens for STR 1.

	Victor Porof [:vporof][:vp] Reporter
	Comment 5 • 12 years ago

For STR 2, indeed, it now seems that the side panels never untoggle when they should. The button to toggle them (far right, in the debugger toolbar) doesn't work either.

	Victor Porof [:vporof][:vp] Reporter
	Comment 6 • 12 years ago

This is what happens for STR 1, with the Operators popup shown when focusing the 'Filter scripts' textbox.

	Paul Rouget [:paul]
	Comment 7 • 12 years ago

I think these are 2 different issues. I filed bug 820343 for STR 2.

STR1 is probably a mac (and windows?) problem.

	Victor Porof [:vporof][:vp] Reporter
	Comment 8 • 12 years ago

(In reply to Paul Rouget [:paul] from comment #7)
> I think these are 2 different issues. I filed bug 820343 for STR 2.
> 

Sounds like it. Thanks!

	Girish Sharma [:Optimizer] Assignee
	Comment 10 • 12 years ago

Although this seems to be a platform issue. The fix is simple. This issue does not happen on linux as the level has "top" as default value. Doing the same by default in debugger.xul fixes the problem.

	Paul Rouget [:paul]
	Comment 11 • 12 years ago

Comment on attachment 694886 [details] [diff] [review]
patch

Wooooo!

	Victor Porof [:vporof][:vp] Reporter
	Comment 12 • 12 years ago

Unfortunately, this doesn't entirely fix the issue. The panels don't even appear anymore in some scenarios.

STR:
1. Open debugger with toolbox undocked
2. Dock the toolbox
3. Click on the search box

Btw, there are multiple panels in the debugger UI. Some of them are defined in xul. Some of them are created in js :)

	Girish Sharma [:Optimizer] Assignee
	Comment 13 • 12 years ago

FWIW, this problem does not arrive for normal panels. If we do not want to go through core changes, we can shift to normal panels with some styling (as they are ugly be default)

	Girish Sharma [:Optimizer] Assignee
	Comment 14 • 12 years ago

(In reply to Victor Porof [:vp] from comment #12)
> Unfortunately, this doesn't entirely fix the issue. The panels don't even
> appear anymore in some scenarios.
> 
> STR:
> 1. Open debugger with toolbox undocked
> 2. Dock the toolbox
> 3. Click on the search box

This is the case on latest m-c too, it is not due to this patch. Most probably its the same bug as Bug 820343 , so it should block this patch.

> Btw, there are multiple panels in the debugger UI. Some of them are defined
> in xul. Some of them are created in js :)

Fixing and resubmitting.

	Girish Sharma [:Optimizer] Assignee
	Comment 15 • 12 years ago

Added level:top at all the three places where panel is used.

	Victor Porof [:vporof][:vp] Reporter
	Comment 16 • 12 years ago

(In reply to Girish Sharma [:Optimizer] from comment #14)
> (In reply to Victor Porof [:vp] from comment #12)
> > Unfortunately, this doesn't entirely fix the issue. The panels don't even
> > appear anymore in some scenarios.
> > 
> > STR:
> > 1. Open debugger with toolbox undocked
> > 2. Dock the toolbox
> > 3. Click on the search box
> 
> This is the case on latest m-c too, it is not due to this patch. Most
> probably its the same bug as Bug 820343 , so it should block this patch.
> 

It is not the same bug. The side panels have no relation whatsoever to a xul <panel>.

	Victor Porof [:vporof][:vp] Reporter
	Comment 17 • 12 years ago

My theory is that the panels are shown behind the main browser window after the toolbox is docked following the steps described in comment 12. You can test this behavior by the fact that it takes two clicks to focus the source editor after focusing the search box (one click "closes" the popup, the next focuses the editor). 

Adding a "top" level attribute to all the panels only fixes half of the problem. I am happy with this, but we need to leave this bug open and find a real solution.

	Victor Porof [:vporof][:vp] Reporter
	Comment 18 • 12 years ago

(In reply to Girish Sharma [:Optimizer] from comment #13)
> FWIW, this problem does not arrive for normal panels. If we do not want to
> go through core changes, we can shift to normal panels with some styling (as
> they are ugly be default)

What are you talking about?

	Girish Sharma [:Optimizer] Assignee
	Comment 19 • 12 years ago

(In reply to Victor Porof [:vp] from comment #17)
> My theory is that the panels are shown behind the main browser window after
> the toolbox is docked following the steps described in comment 12. You can
> test this behavior by the fact that it takes two clicks to focus the source
> editor after focusing the search box (one click "closes" the popup, the next
> focuses the editor). 
> 
> Adding a "top" level attribute to all the panels only fixes half of the
> problem. I am happy with this, but we need to leave this bug open and find a
> real solution.

True that 2 clicks are required. But they are not painted behind the browser window. Read https://bugzilla.mozilla.org/show_bug.cgi?id=820343#c3

(In reply to Victor Porof [:vp] from comment #18)
> (In reply to Girish Sharma [:Optimizer] from comment #13)
> > FWIW, this problem does not arrive for normal panels. If we do not want to
> > go through core changes, we can shift to normal panels with some styling (as
> > they are ugly be default)
> 
> What are you talking about?

The problem that 
1) arrow panel appears behind the undocked toolbox window.
2) following STRs in comment 12 is also fixed

	Victor Porof [:vporof][:vp] Reporter
	Comment 20 • 12 years ago

(In reply to Girish Sharma [:Optimizer] from comment #19)
> 2) following STRs in comment 12 is also fixed

What do you mean by "normal panels"?

	Girish Sharma [:Optimizer] Assignee
	Comment 21 • 12 years ago

(In reply to Victor Porof [:vp] from comment #20)
> (In reply to Girish Sharma [:Optimizer] from comment #19)
> > 2) following STRs in comment 12 is also fixed
> 
> What do you mean by "normal panels"?

The one's without type="arrow" (the one you also use in making the scripts list)

	Victor Porof [:vporof][:vp] Reporter
	Comment 22 • 12 years ago

(In reply to Girish Sharma [:Optimizer] from comment #21)
> (In reply to Victor Porof [:vp] from comment #20)
> > (In reply to Girish Sharma [:Optimizer] from comment #19)
> > > 2) following STRs in comment 12 is also fixed
> > 
> > What do you mean by "normal panels"?
> 
> The one's without type="arrow" (the one you also use in making the scripts
> list)

That's not a panel, that's a <menulist>

	Girish Sharma [:Optimizer] Assignee
	Comment 23 • 12 years ago

(In reply to Victor Porof [:vp] from comment #22)
> (In reply to Girish Sharma [:Optimizer] from comment #21)
> > (In reply to Victor Porof [:vp] from comment #20)
> > > (In reply to Girish Sharma [:Optimizer] from comment #19)
> > > > 2) following STRs in comment 12 is also fixed
> > > 
> > > What do you mean by "normal panels"?
> > 
> > The one's without type="arrow" (the one you also use in making the scripts
> > list)
> 
> That's not a panel, that's a <menulist>

I meant this : http://mxr.mozilla.org/mozilla-central/source/browser/devtools/debugger/debugger-toolbar.js#1056

	Girish Sharma [:Optimizer] Assignee
	Comment 24 • 12 years ago

This [1] screencast demonstrates that arrow panels are not drawn at all, neither in front, nor behind the browser window. But they are still there, just not drawn.

[1] http://youtu.be/LdJMSeTQz24

	Girish Sharma [:Optimizer] Assignee
	Comment 25 • 12 years ago

This bug is in dire need of landing. Its very frustrating to switch windows every time you click on the filter lists box.

Please land as soon as possible, for the other half part of the bug, I am creating a minimal test case to demonstrate that this is a dlbi (or similar) regression, rather than being a devtools bug.

I have also discussed the same with tnikkel on irc.

	Paul Rouget [:paul]
	Comment 26 • 12 years ago

https://hg.mozilla.org/integration/fx-team/rev/97d131390b0b

	Girish Sharma [:Optimizer] Assignee
	Comment 27 • 12 years ago

Follow these STR

1) Install the addon, one window will popup.
2) Either go to A or B
3) Go to add-ons manager and disable the addon.
4) Enable it again, a window pops up.
4) If you went to A in step 2, go to B and viceversa.

A:
1) Press Ctrl + T shortcut while the window is in focus.
2) A arrow notification pops up saying "Blah Blah".
3) Hover over the blah blah and mouse pointer changes to waiting.
4) Close the window.

B:
1) Press the Swap button.
2) The window closes and the iframe is swapped to the bottom of the selected tab.
3) Focusing any textbox in the iframe, press Ctrl + T
4) Nothing seems to happen, but hover your mouse over the text "debugger.xul".
5) Mouse cursor changes to waiting. Also, to focus the other textbox, you require two clicks.
6) That is because, the popup saying "Blah Blah" is right there, just not drawn/painted. So one click is used to close the popup.
7) Close the tab.

The problem persists through Nightly to as far as Firefox 16 (I stopped checking after that). So it is not a dlbi regression. Its a layer issue.

@Paul, please confirm that the code replicates the docking behavior of toolbox properly.

	Panos Astithas (he/him) [:past] (please ni?)
	Comment 28 • 12 years ago

https://hg.mozilla.org/mozilla-central/rev/97d131390b0b

	Girish Sharma [:Optimizer] Assignee
	Comment 29 • 12 years ago

Adding some layers experts. Please see the addon in the attachment and comment #27

	Paul Rouget [:paul]
	Comment 30 • 12 years ago

(In reply to Girish Sharma [:Optimizer] from comment #27)
> Created attachment 697114 [details]
> restartless addon testcase
> 
> Follow these STR

Apparently, I can't reproduce on Linux. Going through B, I see arrow panel.

	Girish Sharma [:Optimizer] Assignee
	Comment 31 • 12 years ago

Can anyone confirm the same (or the opposite) for Mac and Windows. For Window 7, I do not see the panels.

	Panos Astithas (he/him) [:past] (please ni?)
	Comment 32 • 12 years ago

I can confirm that OS X doesn't show the panel in the B case and it takes 2 clicks to focus a textbox. I never see the "waiting cursor" that you mention though.

	Girish Sharma [:Optimizer] Assignee
	Comment 33 • 12 years ago

Note: In latest Nightly's on Windows, I can see the arrow panel using the STR in comment #12 , but still not able to see the panel using the STR in comment #27

	Paul Rouget [:paul]
	Comment 34 • 12 years ago

Apparently, this could be caused by a CSS transition problem (see bug 832920), that would explain why we can't reproduce on Linux (no transition for panels).

	Rob Campbell [:rc] (:robcee)
	Comment 35 • 12 years ago

Does this need to be open still? Do we need followup bugs so we can close this one?

I don't like leaving bugs open without a clear reason of why they are and what we're planning to do about it.

	Girish Sharma [:Optimizer] Assignee
	Comment 36 • 12 years ago

It can be closed as the actual bug was fixed by the patch that landed. I don't really know why the leave open was put up as the issue still remaining is quite a bigger issue and is due to docshell swapping and transitioning not working after that (supposedly) which is to be handled by bug 832920.

	Rob Campbell [:rc] (:robcee)
	Comment 37 • 12 years ago

Ok, thanks.