In any rich editing element (<editor> or <iframe> w/ designmode="on") the blinking caret is not visible. This only seems to happen in XULRunner applications, because when viewing the same content in Firefox trunk, the caret is visible. The easiet example may be to use the WebRunner XUL application (http://wiki.mozilla.org/WebRunner - Mac version uses XR1.9a7pre) and launch GMail webapp. You can see the problem in the "Compose New Mail" screen with "Rich Editing" selected. The same screen in Firefox does not show the problem - the caret is visible. XUL Explorer, which uses an <editor> element, also has the problem when running with XR 1.9a7pre

I could be wrong, or way of base, but is this related to a very similar Camino bug: bug 387013 ?

Mark, I noticed over in bug 387013 that Camino's not packaging some new css files peterv added with the contentEditable checkin, and philippe reported that adding them seems to fix the caret bug. Any chance XULRunner (WebRunner?) is missing res/contenteditable.css res/designmode.css too (wherever res/ lives in XULRunner; it's $APPNAME.app/Contents/MacOS/res/ in Camino and Mac Firefox)?

I believe it is due some missing point on the fix for bug 387534.

Is this an issue in a build you do yourself, or only in a packaged build (i.e., extracted from a zip/tar/installer)?

(In reply to comment #4) > Is this an issue in a build you do yourself, or only in a packaged build (i.e., > extracted from a zip/tar/installer)? > No, it occurs in the nightly Mozilla xulrunner builds (extracted from zip). Also, it occurs on all platforms.

This bug does not exist in version 0.5 on my computer. Only version 0.7. So I've downgraded back to 0.5.

Smokey was on the right track. In XULRunner, resource:/ is the app root, and resource:/gre/ is app/xulrunner/. In Firefox they both point to the same place. The problem is that contenteditable.css and designmode.css are packaged in xulrunner/res/, but are referenced via resource:/res/. I've confirmed this with XUL Explorer and the test-case from Bug 387534 by copying xulrunner/res/ into the app root. It seems to me the fix is to modify the editor to use resource:/gre/res/. If I make a patch that does this is it likely to be accepted? Also, may I dupe Bug 387534 with this bug?

(In reply to comment #9) > Smokey was on the right track. > > In XULRunner, resource:/ is the app root, and resource:/gre/ is app/xulrunner/. > In Firefox they both point to the same place. The problem is that > contenteditable.css and designmode.css are packaged in xulrunner/res/, but are > referenced via resource:/res/. > Huh, I fixed a similar problem with the spellcheck dictionaries not working in XR apps. > I've confirmed this with XUL Explorer and the test-case from Bug 387534 by > copying xulrunner/res/ into the app root. > Great > It seems to me the fix is to modify the editor to use resource:/gre/res/. If I > make a patch that does this is it likely to be accepted? > > Also, may I dupe Bug 387534 with this bug? > I suggest making the patch and marking bug 387534 a dupe. This bug is fairly critical for any XR apps using the editor and is marked blocking1.9 (whatever that means these days) Thanks Matt

I guess it really is what bug 387534 talks about

Tested with XUL Explorer and the test case from Bug 387534. Any volunteers to test Firefox/Composer/Camino?

Matt, everything continues to operate as expected in Camino with this patch (where everything = http://www.mozilla.org/editor/midasdemo )

Great, thanks Smokey!

Comment on attachment 286180 [details] [diff] [review] Patch to change from resource:/res to resource://gre/res. Daniel, do you mind reviewing this?

Comment on attachment 286180 [details] [diff] [review] Patch to change from resource:/res to resource://gre/res. Probably better to ask Peter for review, I don't think Daniel is doing a lot of reviewing.

Comment on attachment 286180 [details] [diff] [review] Patch to change from resource:/res to resource://gre/res. Thanks.

Comment on attachment 286180 [details] [diff] [review] Patch to change from resource:/res to resource://gre/res. It would be nice if this could be approved for M9, this should be very safe, because it just fixes broken paths.

Comment on attachment 286180 [details] [diff] [review] Patch to change from resource:/res to resource://gre/res. a=drivers for after the M9 freeze

In Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; de-DE; rv:1.9a9pre) Gecko/2007102804 Minefield/3.0a9pre the caret is not visible, when using MineField instead of XulRunner to launch a XulRunner application. So the problem is caused or at least influenced by something, which is shared by both.

(In reply to comment #17) > (From update of attachment 286180 [details] [diff] [review]) > Probably better to ask Peter for review, I don't think Daniel is doing a lot of > reviewing. I am doing reviews. But apparently 3 days is too much :-)

(In reply to comment #22) > I am doing reviews. But apparently 3 days is too much :-) Ok, sorry, good to know.

(In reply to comment #21) > In Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; de-DE; rv:1.9a9pre) > Gecko/2007102804 Minefield/3.0a9pre the caret is not visible, when using > MineField instead of XulRunner to launch a XulRunner application. So the > problem is caused or at least influenced by something, which is shared by both. Georg, did that build include the patch from this bug?

Comment on attachment 286180 [details] [diff] [review] Patch to change from resource:/res to resource://gre/res. a=endgame drivers for M9, should be safe

Checking in content/html/document/src/nsHTMLDocument.cpp; /cvsroot/mozilla/content/html/document/src/nsHTMLDocument.cpp,v <-- nsHTMLDocument.cpp new revision: 3.749; previous revision: 3.748 done Checking in editor/composer/src/res/EditorOverride.css; /cvsroot/mozilla/editor/composer/src/res/EditorOverride.css,v <-- EditorOverride.css new revision: 1.40; previous revision: 1.39 done Checking in editor/libeditor/html/nsHTMLEditor.cpp; /cvsroot/mozilla/editor/libeditor/html/nsHTMLEditor.cpp,v <-- nsHTMLEditor.cpp new revision: 1.562; previous revision: 1.561 done Checking in editor/ui/composer/content/editor.js; /cvsroot/mozilla/editor/ui/composer/content/editor.js,v <-- editor.js new revision: 1.249; previous revision: 1.248 done Checking in layout/style/contenteditable.css; /cvsroot/mozilla/layout/style/contenteditable.css,v <-- contenteditable.css new revision: 3.4; previous revision: 3.3 done

In XULRUnner Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O 10.4; en-US; rv:1.9a9pre) Gecko/2007110108 this really seems to be fixed. The caret is visible now.

Verified fixed using Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a9pre) Gecko/2007110108 prism/0.8. I followed Mark's steps in the initial report to verify.

It's still in download version but i will compile a snapshot version.