[FIX]crash in [@ nsXBLPrototypeHandler::AppendHandlerText]

VERIFIED FIXED in mozilla1.9alpha1



12 years ago
12 years ago


(Reporter: arno, Assigned: bzbarsky)


({crash, verified1.8.0.10, verified1.8.1.2})

crash, verified1.8.0.10, verified1.8.1.2
Bug Flags:
blocking1.8.1.2 +
blocking1.8.0.10 +

Firefox Tracking Flags

(Not tracked)


(crash signature, URL)


(5 attachments)



12 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20060830 Firefox/ (Debian-1.5.dfsg+
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20060830 Firefox/ (Debian-1.5.dfsg+

Hi, I noticed a crash. It happens when in a xbl file you have a handler element with a command attribute if you are not in chrome.
 See url test case for an example.

I investigated and discovered that that crash happens in nsXBLPrototypeHandler::AppendHandlerText (file content/xbl/src/nsXBLPrototypeHandler.cpp)

in nsXBLContentSink::OnOpenContainer (file content/xbl/src/nsXBLContentSink.cpp) 
there is : 

  if (command && !mIsChromeOrResource)
    // Make sure the XBL doc is chrome or resource if we have a command
    // shorthand syntax.
    return; // Don't even make this handler.

so in case command attribute is set, and url scheme is not chrome (or ressource), mHandler is not created.

but in nsXBLContentSink::FlushText (called from nsXBLContentSink::HandleEndElement), there is :
    if (mSecondaryState == eXBL_InHandler) {

AppendHandler method of mHandler is called but mHandler has not been created (and is therefor still nsnuss).
So, my browser crashes.
I make a small patch that seems to solve the problem, but may we could issue a console warning or do something more appropriate.

Reproducible: Always

Steps to Reproduce:
1. go to http://ffsearchplugins.free.fr/bugzilla/example.xul
Actual Results:  

Expected Results:  
should not crash :)

Comment 1

12 years ago
Created attachment 247402 [details] [diff] [review]
mentionned patch


12 years ago
Component: General → XBL
Product: Firefox → Core
Version: unspecified → 1.8 Branch


12 years ago
Keywords: crash
Summary: crash in nsXBLPrototypeHandler::AppendHandlerText → crash in [@ nsXBLPrototypeHandler::AppendHandlerText]
As a wild guess I think it might be better if mSecondaryState didn't lie.
Yeah, definitely.  The problem is that the current code (with or without the proposed null-check) will stick the text in the wrong handler if there's a handler preceding the "command" handler in question...
Ever confirmed: true
Flags: wanted1.8.0.x?
Flags: blocking1.9?
Flags: blocking1.8.1.2?
Hardware: PC → All
Version: 1.8 Branch → Trunk
Created attachment 247452 [details]
XBL for testcase
Created attachment 247453 [details]
Created attachment 247454 [details] [diff] [review]

Treat this situation as an error and bail on the binding.  Also treat OOM constructing a handler as an error.
Attachment #247454 - Flags: superreview?(bugmail)
Attachment #247454 - Flags: review?(bugmail)
QA Contact: general → ian
I should note that there's no need to cc me on XBL bugs if you properly reassign them -- I watch the default XBL assignee.  But you do need to properly reassign...
Assignee: nobody → bzbarsky
Priority: -- → P1
Summary: crash in [@ nsXBLPrototypeHandler::AppendHandlerText] → [FIX]crash in [@ nsXBLPrototypeHandler::AppendHandlerText]
Target Milestone: --- → mozilla1.9alpha
Attachment #247454 - Flags: superreview?(bugmail)
Attachment #247454 - Flags: superreview+
Attachment #247454 - Flags: review?(bugmail)
Attachment #247454 - Flags: review+
Fix checked in.  Not sure what to do with branches; localization is frozen, right?  I suppose I could just not report the error there (and silently bail).
Last Resolved: 12 years ago
Resolution: --- → FIXED
Flags: wanted1.8.0.x? → blocking1.8.0.10?

Comment 9

12 years ago
bz:  Let's fix the crash and not worry about reporting the error for the branches.
Flags: blocking1.8.1.2?
Flags: blocking1.8.1.2+
Flags: blocking1.8.0.10?
Flags: blocking1.8.0.10+
Still need a branch patch
Created attachment 250795 [details] [diff] [review]
Branch patch
Attachment #250795 - Flags: approval1.8.1.2?
Attachment #250795 - Flags: approval1.8.0.10?

Comment 12

12 years ago
Comment on attachment 250795 [details] [diff] [review]
Branch patch

Approved for the branches, a=jay for drivers.
Attachment #250795 - Flags: approval1.8.1.2?
Attachment #250795 - Flags: approval1.8.1.2+
Attachment #250795 - Flags: approval1.8.0.10?
Attachment #250795 - Flags: approval1.8.0.10+
Fixed on both branches.
Keywords: fixed1.8.0.10, fixed1.8.1.1
Keywords: fixed1.8.1.1 → fixed1.8.1.2
verified fixed on the 1.8.0 branch using Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv: Gecko/20070111 Firefox/ No crash using http://ffsearchplugins.free.fr/bugzilla/example.xul.

Also verified fixed on the 1.8 branch using Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv: Gecko/20070109 BonEcho/ No crash using http://ffsearchplugins.free.fr/bugzilla/example.xul.

Adding the relevant verified keywords.

Keywords: fixed1.8.0.10, fixed1.8.1.2 → verified1.8.0.10, verified1.8.1.2
Verified fixed, using:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a3pre) Gecko/20070207 Minefield/3.0a3pre
Flags: blocking1.9?
Crash Signature: [@ nsXBLPrototypeHandler::AppendHandlerText]
You need to log in before you can comment on or make changes to this bug.