I believe this is a guaranteed null-deref, so not security-sensitive....

Comment on attachment 668710 [details] [diff] [review] Deal with JS_ValueToString failing. Review of attachment 668710 [details] [diff] [review]: ----------------------------------------------------------------- Just one question. Wouldn't it make sense if an init method that can fail, handled the null case internally? Personally I would put the null check inside nsDependentJSString::init too just in case someone else does the same mistake as I did. Anyway, that being said r+ and thanks for fixing it.

We could do that, at the cost of an extra null-check for every single existing consumer...

Comment on attachment 668710 [details] [diff] [review] Deal with JS_ValueToString failing. [Approval Request Comment] Bug caused by (feature/regressing bug #): Bug 763897 User impact if declined: Null-deref crashes that web pages can trigger Testing completed (on m-c, etc.): Tested on the attached testcase Risk to taking this patch (and alternatives if risky): Very low risk. Just adds a missing null-check and exception, instead of crash. String or UUID changes made by this patch: None.

Comment on attachment 668710 [details] [diff] [review] Deal with JS_ValueToString failing. [Triage Comment] Reproducible crash regression with a very low risk fix - approving for Aurora 17. Please land early Monday to make the next merge.

Confirmed crash on 2012-10-4 Verified fixed on build 2012-11-13, 17.0b6 Verified fixed on build 2012-11-19, 17.0esr Verified fixed on build 2012-11-19, 18.0a2 Aurora