321238 - ASSERTION: Unexpected JSContext popped!

Status: RESOLVED INVALID

(Core :: DOM: Editor, defect)

Description

[Martijn Wargers (dead)]

I get this assertion with current trunk debug build, while browsing any website (even with a blank file):

WARNING: Somehow not a plaintext editor?, file c:/mozilla/mozilla/layout/forms/n
sTextControlFrame.cpp, line 3110
###!!! ASSERTION: Unexpected JSContext popped!: '!cx', file c:/mozilla/mozilla/l
ayout/forms/nsTextControlFrame.cpp, line 3153
Break: at file c:/mozilla/mozilla/layout/forms/nsTextControlFrame.cpp, line 3153

I suspect this may also have something to do with the fact that latest nightly trunk builds are highly unstable to me, usually hanging/crashing within 10 minutes or so.

Comment 1

[Martijn Wargers (dead)]

Attachment: backtrace of the assertion

Comment 2

[Martijn Wargers (dead)]

Attachment: backtrace of the assertion

Wait, let me add the whole log.
Prior to the assertion, I get this js error:
JavaScript error: , line 0: uncaught exception: [Exception... "Component returne
d failure code: 0x80004002 (NS_NOINTERFACE) [nsISupports.QueryInterface]"  nsres
ult: "0x80004002 (NS_NOINTERFACE)"  location: "JS frame :: chrome://global/conte
nt/bindings/textbox.xml ::  :: line 126"  data: no]
Maybe it has something to do with this (or maybe not).

Comment 3

[:Gavin Sharp [email: [e-mail]]]

Regression from bug 253481, it seems?

Comment 4

[Martijn Wargers (dead)]

(In reply to comment #3)
> Regression from bug 253481, it seems?
Yes, it seems so. Backing out the editor patch and rebuilding editor and layout makes the assertions go away and the javascript error.

Comment 5

[(not currently active) Ted Mielczarek]

I assume somehow either the html:input QI to nsIDOMNSEditableElement is failing, or the editor QI to nsIPlaintextEditor is failing.  That code should only be executing on the urlbar right now though, since that's the only place in the tree the newlines attribute is used.  Is something funky with your urlbar?

Comment 6

[James Ross]

Yes; my URL bar is empty. (I see all those lovely assertions too)

Also, some webpage textboxes are empty instead of filled, like the Bugzilla summary box.

Comment 7

[James Ross]

Oh, and also - no autocomplete box works, but I figure this is the same thing. It seems to spew the error whenever any code trys to set the value, and seems to usually fail because of it.

Comment 8

[(not currently active) Ted Mielczarek]

(In reply to comment #4)
> (In reply to comment #3)
> > Regression from bug 253481, it seems?
> Yes, it seems so. Backing out the editor patch and rebuilding editor and layout
> makes the assertions go away and the javascript error.

Martijn:  Did you just back out the editor changes, and not the XBL changes?

Comment 9

[(not currently active) Ted Mielczarek]

Just for clarification, what platforms are you two building on?

Also, I'm not going to have enough time to fix this before Christmas, so if you think it's serious enough, go ahead and back out my patch and reopen bug 253481.

Comment 10

[James Ross]

I build on Windows 2000 using the MS C++ Toolkit and Windows Server 2003 SP1 Platform SDK.

Comment 11

[[e-mail]]

This isn't a regression, it's a build issue, see bug 293485.

Comment 12

[James Ross]

Except that my build env does exactly that!

Comment 13

[Martijn Wargers (dead)]

(In reply to comment #8)
> Martijn:  Did you just back out the editor changes, and not the XBL changes?
Yes, only the editor changes.

(In reply to comment #11)
> This isn't a regression, it's a build issue, see bug 293485.
So I need to do a make -f client.mk distclean, rebuild and then see if I still see the assert?

Comment 14

[Martijn Wargers (dead)]

Ok, after make -f client.mk distclean, rebuild, it functions normally.
So do the nightly trunk builds suffer from the same problem?

Comment 15

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #14)
> Ok, after make -f client.mk distclean, rebuild, it functions normally.
> So do the nightly trunk builds suffer from the same problem?

Nightlies are always clean builds, even on "dep" tinderboxen.

Comment 16

[Martijn Wargers (dead)]

Hmm, that means there must be something else that makes my nightly build very unstable :(
And I'm not getting those problems with my debug build.

Comment 17

[Martijn Wargers (dead)]

Ok, my stability problems appear to have been caused by the patch from bug 287179, which has been backed out.