391429 - Editor caret is hidden in XULRunner applications, but visible in Firefox

Status: VERIFIED FIXED

(Core :: DOM: Editor, defect)

Description

[Mark Finkle (:mfinkle) (use needinfo?)]

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

Comment 1

[philippe (part-time)]

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

Comment 2

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

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)? 

Comment 3

[Caio Tiago Oliveira (asrail)]

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

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

Comment 5

[Mark Finkle (:mfinkle) (use needinfo?)]

(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.

Comment 7

[jrintels]

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

Comment 9

[Matt Crocker]

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?

Comment 10

[Mark Finkle (:mfinkle) (use needinfo?)]

(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

Comment 11

[Georg Maaß]

I guess it really is what bug 387534 talks about

Comment 13

[Matt Crocker]

Attachment: Patch to change from resource:/res to resource://gre/res.

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

Comment 14

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

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

Comment 15

[Matt Crocker]

Great, thanks Smokey!

Comment 16

[Matt Crocker]

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

Daniel, do you mind reviewing this?

Comment 17

[Martijn Wargers (dead)]

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 18

[Peter Van der Beken [:peterv]]

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

Thanks.

Comment 19

[Martijn Wargers (dead)]

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 20

[Mike Beltzner [:beltzner, not reading bugmail]]

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

a=drivers for after the M9 freeze

Comment 21

[Georg Maaß]

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.

Comment 22

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

(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 :-)

Comment 23

[Martijn Wargers (dead)]

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


Ok, sorry, good to know.

Comment 24

[Matt Crocker]

(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 26

[Mike Beltzner [:beltzner, not reading bugmail]]

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

Comment 27

[Reed Loden [:reed]]

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

Comment 28

[Georg Maaß]

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.

Comment 29

[Marcia Knous [:marcia]]

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.

Comment 31

[Sebastian Deutsch]

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