Closed Bug 295275 Opened 19 years ago Closed 17 years ago

After floating the Watch/other window, variables do not show up when docking it again

Categories

(Other Applications Graveyard :: Venkman JS Debugger, defect, P1)

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: nbast, Assigned: rginda)

References

Details

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707

You are running Venkman version 0.9.85.

I added several watches to the Watch window.  Some of them were complex objects,
so I floated the watch window so I could make it large enough to see all the data.

When I was done, I redocked the window, but none of my watched were visible.  I
thought they might have been cleared, so I added another watch, and it also
didn't appear.

I refloated the window, and all watches were visible including the one I added
while it was docked.


Reproducible: Always

Steps to Reproduce:
1.  Add watches to watch window
2.  float the watch window
3.  dock the watch window

Actual Results:  
watches were no longer visible in the watch window

Expected Results:  
watches should remain visible
I have the same problem.
This seems to affect all windows, to varying degrees.
Severity: normal → major
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: PC → All
Version: unspecified → Trunk
Summary: After floating the Watch window, variables do not show up when docking it again → After floating the Watch/other window, variables do not show up when docking it again
*** Bug 341855 has been marked as a duplicate of this bug. ***
Same problem here with 'Open Windows', 'Local Variables', 'Breakpoints', 'Watches', 'Loaded Scripts', and 'Call Stack'.  When floating I can see thier contents, but not when docked.
Adding myself here. This bug, a year and a half old? I think this problem is really a pain. I start out the debugger in it's default layout. It takes just once, to undock a tab. Once undocked, it cannot revert back to the debugger's window. If I try, the contents are gone.

The funny thing is... when I float and then unfloat(return to default layout, I see the contents of the watch, breakpoints whatever for just a split second. Living with this problem tends to discourage the user(me) from using undocked views, and since I don't undock the views... life is pretty darned cramped. Is there an internal command I can issue to fix this? This bug would be nice to have fixed.
I don't know of a command to fix it, but you're right that it is Pretty Darn Annoying.

I probably wont be able to do any work until next weekend (away in the middle of the week), but it's going to be near the top of my list.
Assignee: rginda → silver
Priority: -- → P1
Darn, I was hoping for something like a "toggle-view watches" special parm maybe... Well I did look into some of the source tonight...

        if (!("treeBoxObject" in treeContent))
            throw "tantrum";
hahaha

One can use the internal venkman commands like 
/change-container watches [horizontal || vertical || tab]
and you will see the data is still there, but it vanishes quickly. Could it be the paintHack() ? Well let me wish you luck in finding this one.

On the Firefox Official 2.0 build... using latest venkman...
Here is what happens when I close a floated window... by menuitem or unfloating a floated view. The WARNING: NS_ENSURE_TRUE(nsDoc) failed, goes on forever.

++WEBSHELL == 5
++DOMWINDOW == 9
++DOMWINDOW == 10
vnk: } 11.762 sec
++DOMWINDOW == 11
--DOMWINDOW == 10
++WEBSHELL == 6
++DOMWINDOW == 11
++DOMWINDOW == 12
--WEBSHELL == 5
WARNING: NS_ENSURE_TRUE(nsDoc) failed, file /KNOPPIX.IMG/home/knoppix/mozilla/content/xul/content/src/nsXULElement.cpp, line 2593
WARNING: NS_ENSURE_TRUE(nsDoc) failed, file /KNOPPIX.IMG/home/knoppix/mozilla/content/xul/content/src/nsXULElement.cpp, line 2593
WARNING: NS_ENSURE_TRUE(nsDoc) failed, file /KNOPPIX.IMG/home/knoppix/mozilla/content/xul/content/src/nsXULElement.cpp, line 2593
{snip}
vnk: onclose
vnk: onclose: dispatching
vnk: Application venkman, 'JavaScript Debugger' unloading.
+++ JavaScript debugging hooks removed.
--WEBSHELL == 4
--WEBSHELL == 3
--DOMWINDOW == 11
--DOMWINDOW == 10
--DOMWINDOW == 9
--DOMWINDOW == 8
Do you mean the warning is repeated forever and ever, even after closing Venkman? Or does it only repeat until you close Venkman?

<sarcasm>I love XUL and Gecko, really I do.</sarcasm>
I could only say forever if bug squash never happens. :) I did manage to find something to use until then though... /reloadui actually works. But I had to fix a few things to use that. First these 2 have 1 statement using tov_formatRecord which should probably be xtv_formatRecord. One, a commented out dd statement.in venkman-views.js The other in venkman-dev.js, but they should be made up to date. 

But in short, I get venkman-dev.js working. Then load with 
loadd chrome://venkman/content/venkman-dev.js followed by a /reloadui command.  I include links to the 2 source lines and the third is a news archive of Rob explaining what tov_ belonged to, and what it should be now. So that is my progress on this bug so far, well besides having finally gotten my Knoppix on XP to have a working ddd gdb combo, that doesn't bug out when a new thread is started. Any luck on your end?

http://lxr.mozilla.org/mozilla/source/extensions/venkman/resources/content/venkman-dev.js#140
http://lxr.mozilla.org/mozilla/source/extensions/venkman/resources/content/venkman-views.js#1104

http://groups.google.com/group/netscape.public.mozilla.xpfe/browse_thread/thread/cae8cceffd7b3ae6/8290205ca8aa434a?lnk=st&q=venkman+loadd&rnum=2#8290205ca8aa434a

I come bearing good news! The fix is a 1-line patch. :-D

FWIW, the bug was caused by bug 221619, back here:
http://bonsai.mozilla.org/cvslog.cgi?file=mozilla/extensions/venkman/resources/content/venkman-views.js&rev=1.23

Patch in a sec.
The original change didn't take into account that this function is called with treeView set to null when *unsetting* the view for a tree. This means that while all the views work initially, as soon as you change one (this might include the floating done on startup, not checked) it is then semi-screwed because it didn't finish the unhooking.
Attachment #246502 - Flags: review?(rginda)
A 1 line patch, and just 2 more lines away from #c7

Thanks for tracking this one down.
Works for me.

This is such good news. The Venkman is back.


hmmm, after I dock back into venkman, I still have the xbl/xul error... which goes on not forever as I had thouht, but a minute or 2, then poof! Mozilla is gone! (I never let it keep running) Also, when I dock a floated window, the text on the window flashes. It is there, but flashes. Blinks is a better term.
I sure hope it is my ragged build. I am going to make an xpi and try it on a windows xp machine.


WARNING: NS_ENSURE_TRUE(nsDoc) failed, file /KNOPPIX.IMG/home/knoppix/mozilla/content/xul/content/src/nsXULElement.cpp, line 2593
--DOMWINDOW == 12
Assertion failure: !flbase[flindex], at /KNOPPIX.IMG/home/knoppix/mozilla/js/src/jsgc.c:1349
./run-mozilla.sh: line 131:  8698 Trace/breakpoint trap   "$prog" ${1+"$@"}

That last post... Well... I fixed my patching, now the console is clean. I think in my excitement I screwed my source files a bit. Fixed them, now all is well.
This needs a review, right?
Any progress on this fix being piut in to a new version? It makes a big difference. I feel guilty in that I am probably one of the only ones out there with this working, The patch does work. How about another release?
Attachment #246502 - Flags: review?(rginda) → review?(shaver)
Assignee: silver → rginda
QA Contact: caillon → venkman
Comment on attachment 246502 [details] [diff] [review]
Only set selection tree when setting tree view

r=gijs
Attachment #246502 - Flags: review?(shaver) → review+
Checking in mozilla/extensions/venkman/resources/content/venkman-views.js;
/cvsroot/mozilla/extensions/venkman/resources/content/venkman-views.js,v  <--  venkman-views.js
new revision: 1.35; previous revision: 1.34
done
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Backed out on James' request.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Checked in.
Status: REOPENED → RESOLVED
Closed: 17 years ago17 years ago
Resolution: --- → FIXED
Product: Other Applications → Other Applications Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: