814641 - [toolbox] Panels appear behind the devtools window after undocking

Status: RESOLVED FIXED

(DevTools :: Debugger, defect, P2)

Description

[Victor Porof [:vporof][:vp]]

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

Comment 1

[Paul Rouget [:paul]]

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

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

Comment 2

[Paul Rouget [:paul]]

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).

Comment 3

[Paul Rouget [:paul]]

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".

Comment 4

[Victor Porof [:vporof][:vp]]

Attachment: STR 1

This is what happens for STR 1.

Comment 5

[Victor Porof [:vporof][:vp]]

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.

Comment 6

[Victor Porof [:vporof][:vp]]

Attachment: STR 1, other popup

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

Comment 7

[Paul Rouget [:paul]]

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

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

Comment 8

[Victor Porof [:vporof][:vp]]

(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!

Comment 10

[Girish Sharma [:Optimizer]]

Attachment: patch

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.

Comment 11

[Paul Rouget [:paul]]

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

Wooooo!

Comment 12

[Victor Porof [:vporof][:vp]]

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 :)

Comment 13

[Girish Sharma [:Optimizer]]

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)

Comment 14

[Girish Sharma [:Optimizer]]

(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.

Comment 15

[Girish Sharma [:Optimizer]]

Attachment: real fix (fixed in fx-team)

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

Comment 16

[Victor Porof [:vporof][:vp]]

(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>.

Comment 17

[Victor Porof [:vporof][:vp]]

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.

Comment 18

[Victor Porof [:vporof][:vp]]

(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?

Comment 19

[Girish Sharma [:Optimizer]]

(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

Comment 20

[Victor Porof [:vporof][:vp]]

(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"?

Comment 21

[Girish Sharma [:Optimizer]]

(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)

Comment 22

[Victor Porof [:vporof][:vp]]

(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>

Comment 23

[Girish Sharma [:Optimizer]]

(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

Comment 24

[Girish Sharma [:Optimizer]]

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

Comment 25

[Girish Sharma [:Optimizer]]

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.

Comment 26

[Paul Rouget [:paul]]

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

Comment 27

[Girish Sharma [:Optimizer]]

Attachment: restartless addon testcase

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.

Comment 28

[Panos Astithas (he/him) [:past] (please ni?)]

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

Comment 29

[Girish Sharma [:Optimizer]]

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

Comment 30

[Paul Rouget [:paul]]

(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.

Comment 31

[Girish Sharma [:Optimizer]]

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

Comment 32

[Panos Astithas (he/him) [:past] (please ni?)]

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.

Comment 33

[Girish Sharma [:Optimizer]]

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

Comment 34

[Paul Rouget [:paul]]

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).

Comment 35

[Rob Campbell [:rc] (:robcee)]

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.

Comment 36

[Girish Sharma [:Optimizer]]

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.

Comment 37

[Rob Campbell [:rc] (:robcee)]

Ok, thanks.