I'm not sure if this is an editor or CSS problem. In trunk build 20040113xx the HTMLArea example worked quite ok, but with 20040114xx I started getting the following JavaScript error every time I click the text in the editor: Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMNSHTMLDocument.queryCommandValue]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: http://dynarch.com/htmlarea/htmlarea.js :: anonymous :: line 868" data: no] With a recent debug build I also get the following assertion: --------------------------- nsDebug::Assertion --------------------------- ASSERTION: null CSSDeclaration: 'decl', file c:/mozilla_source/mozilla/content/html/style/src/nsDOMCSSDeclaration.cpp, line 77 From looking at bonsai I suspect bug 15608 or bug 211376.

> With a recent debug build I also get the following assertion: That assertion is bogus and should be removed. Can you set a breakpoint in nsHTMLDocument::QueryCommandValue and see where the return from that function actually happens?

Also, what are the actual times corresponding to those "xx"?

I'll try. The working build is 2004011308 and the broken one is 2004011409.

There was a special case if the font face was being queried. It was previously an UTF-16 string and I assume it's now an UTF-8 string like all the others. Correct?

None of that should have changed, certainly not due to any style system changes.

Comment on attachment 139147 [details] [diff] [review] Patch to remove the font face special case Oh, this looks like breakage from bug 230683. sr=bzbarsky, if glazou reviews.

Comment on attachment 139147 [details] [diff] [review] Patch to remove the font face special case r=brade if someone confirms that this works with a Japanese (or other double-byte language) font name. p.s. In the future, more context would be nice. :-)

I tested my self-made font with a double-byte name in the composer and it seemed to work fine although it showed ? instead of the special character in the font combo box (the UI font missing that character?). I don't know how to test it with HTMLArea or alike.

Brade, do I need some more testing and if I do, how would I do that?

The special casing was done by Brade in bug 208467 (as an optimization?). It doesn't mention anything about double-byte languages. I don't think this will break double-byte languages. Besides, there's no way the situation could be any worse than now when nothing works. r?

Given that, r=brade is just fine with me. ;)

Fix checked in to trunk.

fixed on the m4 thunderbird branch.