Closed
Bug 814641
Opened 12 years ago
Closed 12 years ago
[toolbox] Panels appear behind the devtools window after undocking
Categories
(DevTools :: Debugger, defect, P2)
Tracking
(Not tracked)
RESOLVED
FIXED
Firefox 21
People
(Reporter: vporof, Assigned: Optimizer)
References
Details
Attachments
(4 files, 1 obsolete file)
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
Reporter | ||
Updated•12 years ago
|
Summary: Panels appear behind the devtools window after undocking → [toolbox] Panels appear behind the devtools window after undocking
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.
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).
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".
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.
Reporter | ||
Comment 6•12 years ago
|
||
This is what happens for STR 1, with the Operators popup shown when focusing the 'Filter scripts' textbox.
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.
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!
Updated•12 years ago
|
Priority: -- → P1
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.
Assignee | ||
Updated•12 years ago
|
Whiteboard: [has-patch]
Comment 11•12 years ago
|
||
Comment on attachment 694886 [details] [diff] [review] patch Wooooo!
Attachment #694886 -
Flags: review?(paul) → review+
Updated•12 years ago
|
Whiteboard: [has-patch] → [land-in-fx-team]
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 :)
Reporter | ||
Updated•12 years ago
|
Attachment #694886 -
Flags: review+ → review-
Assignee | ||
Updated•12 years ago
|
Whiteboard: [land-in-fx-team]
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)
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.
Assignee | ||
Comment 15•12 years ago
|
||
Added level:top at all the three places where panel is used.
Attachment #694886 -
Attachment is obsolete: true
Attachment #694921 -
Flags: review?(vporof)
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>.
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.
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?
Reporter | ||
Updated•12 years ago
|
Attachment #694921 -
Flags: review?(vporof) → review+
Reporter | ||
Updated•12 years ago
|
Whiteboard: [leave open][land-in-fx-team]
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
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"?
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)
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>
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
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
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.
Updated•12 years ago
|
Priority: P1 → P2
Comment 26•12 years ago
|
||
https://hg.mozilla.org/integration/fx-team/rev/97d131390b0b
Whiteboard: [leave open][land-in-fx-team] → [leave open]
Updated•12 years ago
|
Attachment #694921 -
Attachment description: real fix → real fix (fixed in fx-team)
Updated•12 years ago
|
Attachment #694921 -
Flags: review+
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.
Flags: needinfo?(paul)
Assignee | ||
Comment 29•12 years ago
|
||
Adding some layers experts. Please see the addon in the attachment and comment #27
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.
Flags: needinfo?(paul)
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.
Flags: needinfo?
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.
Flags: needinfo?
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
Updated•12 years ago
|
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).
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.
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.
Comment 37•12 years ago
|
||
Ok, thanks.
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Whiteboard: [leave open]
Target Milestone: --- → Firefox 21
Updated•11 years ago
|
No longer blocks: DevToolsPaperCuts
Updated•6 years ago
|
Product: Firefox → DevTools
You need to log in
before you can comment on or make changes to this bug.
Description
•