Closed Bug 295275 Opened 20 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: