320652 - DOM Inspector broken

Status: RESOLVED FIXED

(Other Applications :: DOM Inspector, defect, P3)

Description

[Frank Wein [:mcsmurf]]

In recent SeaMonkey builds DOM Inspector seems to be broken, either the toolbars are not visible at all or you only see the menu entrys "File Edit Search View" and those open up empty menus (the toolbar buttons are without function). This is probably a regression outside of DOMI code so.
This regressed between 2005-12-14 09:00 and 2005-12-15 09:00:00
Bonsai link:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=MozillaTinderboxAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-12-14+08%3A00%3A00&maxdate=2005-12-15+11%3A00%3A00&cvsroot=%2Fcvsroot

Comment 1

[Frank Wein [:mcsmurf]]

With a debug built i got
###!!! ASSERTION: something's on the context stack already: 'mContextStack.Depth
() == 0', file h:/mozilla/tree-main/mozilla/content/xul/document/src/nsXULDocume
nt.cpp, line 2519
as assertion. This would point to Bug 186667 which might be the case here (overlay fails to load?).

Comment 2

[Hermann Schwab]

Dates from the Tinderbox: 
Checkins to module SeaMonkeyAll between 2005-12-14 08:36 and 2005-12-15 09:17 
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=SeaMonkeyAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-12-14+08%3A36&maxdate=2005-12-15+09%3A17&cvsroot=%2Fcvsroot

Comment 3

[[e-mail]]

From that bonsai list I'd pick bug 320211.

Comment 4

[Frank Wein [:mcsmurf]]

Hermann: Just fyi, i normally just take the build id (in the title bar) and add -1 hour at the beginning and +1 hour at the end of the time range to be sure i catch all checkins. If i take the exact times from the tinderbox i /might/ (yes the possiblity that this happens is very minor) miss a checkin since CVS server and cvs mirror have a minor difference. Also i think it's just easier getting the regression range like that :) (than going back in tinderbox log).

Comment 5

[Hermann Schwab]

(In reply to comment #4)
> Hermann: Just fyi, i normally just take the build id (in the title bar) and add
> -1 hour at the beginning and +1 hour at the end of the time range to be sure i
> catch all checkins. If i take the exact times from the tinderbox i /might/ (yes
> the possiblity that this happens is very minor) miss a checkin since CVS server
> and cvs mirror have a minor difference. Also i think it's just easier getting
> the regression range like that :) (than going back in tinderbox log).

Full ACK, but as I added my CC I didn't mind to add some info to maybe reduce the range of checkins from 13 to 11 people.
 
Lately I've seen very odd dates, build is started and ends 4 hours later, and there may be a difference between what you see as revision using windows explorer 'Properties', the build ID in the title bar, and the last two digits from the download directory, which mostly denoted the hour the build ended. Mostly I archive nightlies giving them the hour of the directory, sometimes I rename this to the buildId. So I started to bookmark the exact times just for fun, may be not useful, but can give a better timing in case of the tons of checkins which happen when trunk is reopened after a branch. Pacifica builds hourly Firefox binaries giving them the BuildID of the latest nightly ;-). Really funny, if you look at Talkback data, different builds, same ID. Bug 305233 filed.

Comment 6

[Andrew Schultz]

backing out bug 320211 fixes this

Comment 7

[Blake Kaplan (:mrbkap) (inactive)]

I bet this is because of the new call to EndLoad that comes from the parser calling DidBuildModel on the content sink. I'll try to see if fixing that call somehow in nsXULDocument.cpp fixes these problems tomorrow.

Comment 8

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: prototype potential patch

This needs more comments at the very least, it also needs to be tested that it actually works.

Comment 9

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: Working potential fix

I was correct in my guess for what was going on, but my last patch was not correct because mLoaded is set from nsXULDocument::EndLoad, entirely too late. This patch fixes things by making nsXULDocument.cpp not get confused by the failed overlay load.

Comment 10

[[e-mail]]

Attachment: Lightly tested hack

Comment 11

[Blake Kaplan (:mrbkap) (inactive)]

Comment on attachment 206557 [details] [diff] [review]
Lightly tested hack

I like this approach a lot better. Please comment in the places that you've added code, though, so it's clear what's going on. r=mrbkap

Comment 12

[[e-mail]]

Fix checked in.