Closed Bug 116643 Opened 23 years ago Closed 22 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: 23 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: 23 years ago → 22 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.