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

VERIFIED FIXED in mozilla1.9beta1

Status

()

Core
Editor
VERIFIED FIXED
10 years ago
9 years ago

People

(Reporter: mfinkle, Assigned: Matt Crocker)

Tracking

Trunk
mozilla1.9beta1
x86
All
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9 +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [dbaron-1.9:RpCc])

Attachments

(1 attachment)

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

10 years ago
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.
(Reporter)

Updated

10 years ago
Flags: blocking1.9?
Is this an issue in a build you do yourself, or only in a packaged build (i.e., extracted from a zip/tar/installer)?
(Reporter)

Comment 5

10 years ago
(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.
OS: Mac OS X → All
Flags: blocking1.9? → blocking1.9+
(Reporter)

Updated

10 years ago
Duplicate of this bug: 398909
Blocks: 387534

Comment 7

10 years ago
This bug does not exist in version 0.5 on my computer.  Only version 0.7.  So I've downgraded back to 0.5.  
Whiteboard: [dbaron-1.9:RpCc]
(Reporter)

Updated

10 years ago
Duplicate of this bug: 400576
(Assignee)

Comment 9

10 years ago
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
Blocks: 237964

Comment 11

10 years ago
I guess it really is what bug 387534 talks about
(Assignee)

Updated

10 years ago
Duplicate of this bug: 387534
(Assignee)

Comment 13

10 years ago
Created attachment 286180 [details] [diff] [review]
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?
Assignee: nobody → matt
Status: NEW → ASSIGNED
Matt, everything continues to operate as expected in Camino with this patch (where everything = http://www.mozilla.org/editor/midasdemo )
(Assignee)

Comment 15

10 years ago
Great, thanks Smokey!
(Assignee)

Comment 16

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

Daniel, do you mind reviewing this?
Attachment #286180 - Flags: review?(daniel)
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.
Attachment #286180 - Flags: review?(daniel) → review?(peterv)
Comment on attachment 286180 [details] [diff] [review]
Patch to change from resource:/res to resource://gre/res. 

Thanks.
Attachment #286180 - Flags: superreview+
Attachment #286180 - Flags: review?(peterv)
Attachment #286180 - Flags: review+
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.
Attachment #286180 - Flags: approvalM9?
Attachment #286180 - Flags: approval1.9?
Comment on attachment 286180 [details] [diff] [review]
Patch to change from resource:/res to resource://gre/res. 

a=drivers for after the M9 freeze
Attachment #286180 - Flags: approvalM9?
Attachment #286180 - Flags: approvalM9-
Attachment #286180 - Flags: approval1.9?
Attachment #286180 - Flags: approval1.9+

Comment 21

10 years ago
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.

(Assignee)

Comment 24

10 years ago
(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?
(Reporter)

Updated

10 years ago
Duplicate of this bug: 401648
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
Attachment #286180 - Flags: approvalM9- → approvalM9+
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
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9 M9

Comment 28

10 years ago
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.
Status: RESOLVED → VERIFIED
(Reporter)

Updated

9 years ago
Duplicate of this bug: 415380

Comment 31

9 years ago
It's still in download version but i will compile a snapshot version. 
Duplicate of this bug: 439501
You need to log in before you can comment on or make changes to this bug.