ASSERTION: Unexpected JSContext popped!

RESOLVED INVALID

Status

()

Core
Editor
--
major
RESOLVED INVALID
13 years ago
12 years ago

People

(Reporter: Martijn Wargers (zombie), Assigned: Joe Francis)

Tracking

({assertion})

Trunk
x86
Windows XP
assertion
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

13 years ago
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.
(Reporter)

Comment 1

13 years ago
Created attachment 206611 [details]
backtrace of the assertion
(Reporter)

Comment 2

13 years ago
Created attachment 206612 [details]
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).
Attachment #206611 - Attachment is obsolete: true
Regression from bug 253481, it seems?
(Reporter)

Comment 4

13 years ago
(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.
Blocks: 253481
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

13 years ago
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

13 years ago
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.
(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?
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

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

Comment 11

13 years ago
This isn't a regression, it's a build issue, see bug 293485.
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → INVALID

Comment 12

13 years ago
Except that my build env does exactly that!
(Reporter)

Comment 13

13 years ago
(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?

(Reporter)

Comment 14

13 years ago
Ok, after make -f client.mk distclean, rebuild, it functions normally.
So do the nightly trunk builds suffer from the same problem?
(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.
(Reporter)

Comment 16

13 years ago
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.
(Reporter)

Comment 17

13 years ago
Ok, my stability problems appear to have been caused by the patch from bug 287179, which has been backed out. 
You need to log in before you can comment on or make changes to this bug.