Closed Bug 116643 Opened 24 years ago Closed 23 years ago

DOM Inspector hangs mozilla

Categories

(Other Applications :: DOM Inspector, defect)

Product:
Other Applications
Component:
DOM Inspector
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
VERIFIED WORKSFORME

People

(Reporter: zipo13, Assigned: hewitt)

References

Details

(Keywords: hang, platform-parity, stackwanted)

From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.7+) Gecko/20011222 BuildID: 2001 12 22 08 Dom inspector hangs mozilla with any URL Reproducible: Always Steps to Reproduce: 1.Open dom inspector 2.enter any url - www.yahoo.com will do Actual Results: Mozilla hangs
I've found that this url http://www.w3.org/2001/sw/Overview.rss hangs the Inspector (and of course with it Mozilla). I've played with it using lots of different pages though, and only that one hangs it for me.
something in localstore.rdf is causing this. I'm not sure what changed but deleting all traces of dom inspector from localstore.rdf seems to make the problem go away.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Also seeing this in Windows 2000 - Build 2001122308
I've seen that DOM Inspector hangs when the page being 'inspected' changes (with a reload timeout, for instance), when the tree was open to a modified/deletes element, and when you then close the tree :)
Michael and Julien comments sounds like a different bug
Keywords: hang
*** Bug 116904 has been marked as a duplicate of this bug. ***
*** Bug 117086 has been marked as a duplicate of this bug. ***
*** Bug 117254 has been marked as a duplicate of this bug. ***
all the duplicates are on Windows... anyone seeing this on Linux or Mac?
Tried every URL in this bug and the dups: No hang using Linux 2001122906
Keywords: pp
I tried deleting portions of localstore.rdf and the entire file, it doesn't change a thing, the dom inspector still hangs on every www site.
It's doing it for me... including when I have the "DOM Inspector" tab open on the sidebar. Once I open it, as soon as I go to another Web site, the browser hangs and I have to Alt-Ctl-Del it. Then when I open the browser again, the sidebar is completely blank (just a grey rectangle), and I have to use the View menu to turn off the sidebar and then turn it on again, at which point it's OK again.
Keywords: mozilla0.9.8
I've found that the DOM inspector hangs if the page being inspected doesn't have many top-level children (typically 2 for HTML :-) but if there are enough children to force the outliner scroll bar to appear then the inspector does not hang until I resize the window larger.
In a recent nightly it stopped hanging. There are still problems with it, but it's no longer hanging (+'s in the tree view don't always switch to -'s when you toggle them)
*** Bug 117243 has been marked as a duplicate of this bug. ***
Still hanging for me I have Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.7+) Gecko/20020102
A stack of the hang would be very useful here.
How does one go about obtaining a stack of the hang? I can reproduce this 100% of the time, with a fresh profile, and will provide the stack if someone can tell me how (feel free to email me directly if you don't want to spam the whole cc list). Win2K build 2002010303.
I *think* in order to get the stack, you need to compile mozilla in msvc++ and reproduce the hang. When that happens, you can break and get a list of all the functions in the stack.
Matti, could you help with a stacktrace here?
Keywords: stackwanted
win2k build 20020104.. (opt) and 20011230 (debug) Sorry: I can't reproduce the hang (tested all URLs from the dupes). BTW:Have you tried a second test profile ?
I no longer get this hang with Win2K build 2002010608. Before it happened 100% of the time but now I can't make it happen.
You are right I can't see it too. Another thing I can see is the dom inspector tab in my sidebar I think it was taken out - maybe it was the cause to the problem in the first place?
I don't see this anymore either. Works both stand-alone and in side-bar.
Couldn't reproduce the bug I said before... even on 0.9.7 :)
Yup, all working fine for me now, 2002010703, on the site that hung me before, and a couple of others.
haven't seen this in a long time
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
Still hangs, Linux 2002 06/29 #4. I'd stopped using Inspector because hanging was fairly frequently. Steps I take are usually: 1) start inspector 2) load url 3) browse around the tree, look at various things such as computed values etc 4) highlight a url from somewhere 5) click in url bar 6) backspace to erase 7) paste url 8) click on inspect At this point all of moz is hung hard, it's chewing up a fair bit of cpu time -- is constantly in Run mode. When "skill mozilla-bin" is run, it takes about 10-15 seconds for mozilla to die. Other processes are not affected. (side note, crashed mozillas take enormous amounts of cpu/ram when they restart, then they subside back to ~50megs of ram and mostly idle cpu wise, the desktop is unusable until moz has worked out it's issue)
Status: RESOLVED → REOPENED
OS: Windows 98 → All
Resolution: WORKSFORME → ---
please don't reopen bugs that have been closed for nearly half a year. this bug does not have *any* useful debugging content, which means you're re-starting a bug with four pages of useless information. If you can reproduce this, please get a stack trace, a bug about any part of mozilla hanging is not useful without either a hint about why it's hanging, or a stack showing where it's hanging.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 23 years ago
Resolution: --- → WORKSFORME
RS VRFY WFM - Please file a new bug when you get enough information for someone to actually research the problem. Feel free to indicate the new bug number in this bug.
Status: RESOLVED → VERIFIED
Fine, I'll take the exact comment 28 and create a new bug out of it. It says exactly how to reproduce this. Last time I checked, a very small percentage of people actually have (a) a debug build and (b) gdb. That makes stack data mostly useless since most of the libraries in the nightlies don't have stack frame information. I thought the point was to add useful information to bugs. Not to mention so many dupes against this seemingly invisible bug with which I gave a precise recipe for causing it. Bug 115102 created.
make that bug 155102 just for correctness
Product: Core → Other Applications
QA Contact: timeless → dom-inspector
You need to log in before you can comment on or make changes to this bug.