394473 - caret/cursor in View Source is invisible since 20070628 {not rendered, seen, can't, cannot, shown, displayed}

Status: VERIFIED FIXED

(Core :: DOM: Selection, defect)

Description

[[:Aleksej]]

On trunk Firefox and SeaMonkey builds (see below), the caret in View Source does exist, but is invisible.

Regression ranges:
Firefox: 20070627…20070628.
SeaMonkey: 2007062706…2007062801

Probably caused by bug 237964 fix.

Comment 1

[Martijn Wargers (dead)]

Attachment: patch

This fixes it for me. Not sure if this is the right patch, though.
I had to use SetIgnoreUserModify after StopBlinking, because otherwise, for some reason, I would get caret **** at the end of line and press the right arrow key.
However, moving from the end of a line to the new lne with right arrow key suffers from bug 394752, so that might be part of that bug.

Comment 2

[Frank Wein [:mcsmurf]]

Confirming for now.

Comment 3

[Martijn Wargers (dead)]

Not sure how test this, currently. I think if canvas drawWindow would draw the
caret too, then a reftest could be made out of this.
I filed bug 394763 for that.

Comment 4

[Peter Van der Beken [:peterv]]

Comment on attachment 279457 [details] [diff] [review]
patch

No, that won't work. The editor calls SetCaretEnabled which will end up calling SetCaretVisible, so that must not change whether we ignore user-modify. Maybe we should change the default for mIgnoreUserModify to PR_TRUE and call SetIgnoreUserModify(PR_FALSE/PR_TRUE) from nsTextEditorFocusListener::Focus/Blur.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Peter, we should really fix this regression....

Comment 6

[Chris Pearce [:cpearce (Not reading bugmail)]]

Attachment: Patch v1 - mIgnoreUserModify changes

(In reply to comment #4)
> (From update of attachment 279457 [details] [diff] [review])
> No, that won't work. The editor calls SetCaretEnabled which will end up calling
> SetCaretVisible, so that must not change whether we ignore user-modify. Maybe
> we should change the default for mIgnoreUserModify to PR_TRUE and call
> SetIgnoreUserModify(PR_FALSE/PR_TRUE) from
> nsTextEditorFocusListener::Focus/Blur.
> 

This patch follows Peter's suggestion, and it works. Please review.

Is it correct to require a selection when calling SetIgnoreUserModify()? I assume that it is as the caret is a 0-width selection?

(Taking bug)

Comment 7

[Peter Van der Beken [:peterv]]

Comment on attachment 287344 [details] [diff] [review]
Patch v1 - mIgnoreUserModify changes

>Index: layout/base/nsCaret.cpp
>===================================================================

>@@ -156,16 +156,18 @@ NS_IMETHODIMP nsCaret::Init(nsIPresShell

>+  mIgnoreUserModify = PR_TRUE;

Just change the constructor.

>Index: editor/libeditor/text/nsEditorEventListeners.cpp
>===================================================================

>         if (presShell && selection) {
>           nsCOMPtr<nsICaret> caret;
>           presShell->GetCaret(getter_AddRefs(caret));
>           if (caret) {
>+            caret->SetIgnoreUserModify(PR_FALSE);
>             caret->SetCaretDOMSelection(selection);
>           }

Don't think it makes much of a difference but I'd do:

        if (presShell) {
          nsCOMPtr<nsICaret> caret;
          presShell->GetCaret(getter_AddRefs(caret));
          if (caret) {
            caret->SetIgnoreUserModify(PR_FALSE);
            if (selection) {
              caret->SetCaretDOMSelection(selection);
            }
          }

>@@ -1194,16 +1195,25 @@ nsTextEditorFocusListener::Blur(nsIDOMEv

>+        if (presShell && selection) {

And just check presShell here.

Comment 8

[Peter Van der Beken [:peterv]]

Please make sure that this doesn't regress bug 387380 and that the cursor isn't enabled when clicking in a non-editable area in a document with contentEditable nodes.

Comment 9

[Chris Pearce [:cpearce (Not reading bugmail)]]

Attachment: Patch v2 - v1 with Peterv's suggestions

This is patch v1 with Peter's changes, carrying forward r=peterv.

(In reply to comment #8)
> Please make sure that this doesn't regress bug 387380 and that the cursor isn't
> enabled when clicking in a non-editable area in a document with contentEditable
> nodes.
> 

I've checked, and this patch does not break either of these.

Comment 10

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 287575 [details] [diff] [review]
Patch v2 - v1 with Peterv's suggestions

Boy, we really should deCOMtaminate nsIPresShell::GetCaret and other stuff here.

Comment 11

[Aaron Leventhal]

Are we going to seek approval for this to get into 1.9?

Comment 12

[Aaron Leventhal]

See also bug 389321 and bug 403501.

Comment 13

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 287575 [details] [diff] [review]
Patch v2 - v1 with Peterv's suggestions

Yes, we should.

Comment 14

[Chris Pearce [:cpearce (Not reading bugmail)]]

(In reply to comment #12)
> See also bug 389321 and bug 403501.
> 

The patch for this bug does not fix 389321 or 403501 unfortunately.

Comment 15

[Reed Loden [:reed]]

Checking in layout/base/nsCaret.cpp;
/cvsroot/mozilla/layout/base/nsCaret.cpp,v  <--  nsCaret.cpp
new revision: 1.184; previous revision: 1.183
done
Checking in editor/libeditor/text/nsEditorEventListeners.cpp;
/cvsroot/mozilla/editor/libeditor/text/nsEditorEventListeners.cpp,v  <--  nsEditorEventListeners.cpp
new revision: 1.256; previous revision: 1.255
done

Comment 16

[[:Aleksej]]

Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9b2pre) Gecko/2007111504 Minefield/3.0b2pre

Only visible if caret browsing is enabled. IOW, not fixed.

Comment 17

[Chris Pearce [:cpearce (Not reading bugmail)]]

Confirm with [Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b2pre) Gecko/2007111213 Minefield/3.0b2pre] as well, so not fixed.

Comment 18

[Chris Pearce [:cpearce (Not reading bugmail)]]

D'oh! My original patch changes nsEditorEventListeners::Focus(), but that isn't even called when we focus on a view source document viewer; nsDocViewerFocusListener::Focus() is. I think I had caret browsing on by mistake, and then I must have got excited when I saw the caret in the view source window. So since that patch doesn't actually change anything that needs changed, I suggest we back it out. I'll remove the old unnecessary patch in my next patch.

Comment 19

[Chris Pearce [:cpearce (Not reading bugmail)]]

Ok, the problem here is that when we focus a document/window we're calling nsEventStateManager::ResetBrowseWithCaret(), which calls SetContentCaretVisible(presShell, mCurrentFocus, mBrowseWithCaret). This means that the only way we can get a visible caret is if we have caret browsing on. So the solution is to change ResetBrowseWithCaret() so that it also checks to see if we're in a view-source document, and making the caret visible if we are.

Comment 20

[Chris Pearce [:cpearce (Not reading bugmail)]]

Attachment: Patch v3 - remove patch v2, make caret visible in view-source

This patch:
* Removes the changes made in patch v2, seeing as they don't do anything useful.
* Adds helper IsViewSourceDocument() to nsEventStateManager.cpp.
* Changes nsEventStateManager::ResetBrowseWithCaret() to make caret visible when we're in a view source document.

Comment 21

[Martijn Wargers (dead)]

I'm seeing a caret **** remaining, when I have caret browsering enabled and I click on a text input, while the caret was somewhere else in the document.
The regression range was between 2007-11-09 and 2007-11-13, I think it was caused by this patch.
Does patch v3 address that issue? Or should I file a new bug? (I guess so).

Comment 22

[Peter Van der Beken [:peterv]]

I'm not too fond of hardcoding viewsource there.

I missed this in my review, but my proposal was based on attachment 279457 [details] [diff] [review], which removed the SetIgnoreUserModify call from nsEventStateManager::SetContentCaretVisible. Does doing that (and leaving attachment 287575 [details] [diff] [review] in) fix the bug too?
The only problem is that we're disabling the caret in non-editable regions in a contenteditable document when something else has turned it on with SetCaretEnabled (browse with caret, typeahead find, ...) I wonder if we should only call SetIgnoreUserModify from nsTextEditorFocusListener::Focus if the caret was not enabled yet?

Comment 23

[Peter Van der Beken [:peterv]]

Hmm, we'd also have to reset mIgnoreUserModify when someone calls SetCaretEnabled.

Comment 24

[Chris Pearce [:cpearce (Not reading bugmail)]]

(In reply to comment #21)
> I'm seeing a caret turd remaining, when I have caret browsering enabled and I
> click on a text input, while the caret was somewhere else in the document.
> The regression range was between 2007-11-09 and 2007-11-13, I think it was
> caused by this patch.
> Does patch v3 address that issue? Or should I file a new bug? (I guess so).
> 

I'm not quite sure what you mean, I can't see any caret turds on either Mac or Windows with or without patch v3. It might be best for you to file a new bug, and checkup on it once we resolve this one.

Comment 25

[Chris Pearce [:cpearce (Not reading bugmail)]]

(In reply to comment #22)
> I'm not too fond of hardcoding viewsource there.
> 
> I missed this in my review, but my proposal was based on attachment 279457 [details] [diff] [review],
> which removed the SetIgnoreUserModify call from
> nsEventStateManager::SetContentCaretVisible. Does doing that (and leaving
> attachment 287575 [details] [diff] [review] in) fix the bug too?

Yup I've just tested this, and it does.

> The only problem is that we're disabling the caret in non-editable regions in a
> contenteditable document when something else has turned it on with
> SetCaretEnabled (browse with caret, typeahead find, ...)

You're right, if I create a page with contentedtiable body, but a non-contenteditable paragraph and turn browse-with-caret on, the caret behaves funny around non-contenteditable paragraph, and once I start editing, it can't browse into the non-contenteditable paragraph.

> I wonder if we should
> only call SetIgnoreUserModify from nsTextEditorFocusListener::Focus if the
> caret was not enabled yet?

Is this needed? nsTextEditorFocusListener::Focus() calls SetCaretEnabled(PR_TRUE) which in turn calls SetCaretVisible(aEnabled=PR_TRUE), so the IgnoreUserModify status is being set anyway.

Comment 26

[Chris Pearce [:cpearce (Not reading bugmail)]]

(In reply to comment #21)
> I'm seeing a caret turd remaining, when I have caret browsering enabled and I
> click on a text input, while the caret was somewhere else in the document.
> The regression range was between 2007-11-09 and 2007-11-13, I think it was
> caused by this patch.
> Does patch v3 address that issue? Or should I file a new bug? (I guess so).
> 

I've reproduced this with my patch v3 and with your old patch added back in.

STR: 
1. Open view source
2. Click into the source, so the caret appears.
3. Turn On caret browsing (press F7).
4. Turn Off caret browsing (pres F7).
5. Observe caret disappears from view source.
6. Click in the view-source window, observe caret appears again.
6. Click back to the search box in the main FF window.
7. Observe that a caret appears in the search box, but the view-source window's caret remains as well, i.e. there are two carets visible.

Comment 27

[Chris Pearce [:cpearce (Not reading bugmail)]]

Attachment: Patch v4 - Martijn's patch with caret turd fix

(In reply to comment #23)
> Hmm, we'd also have to reset mIgnoreUserModify when someone calls
> SetCaretEnabled.
> 

This patch is Martijn's patch, with comment #23 addressed, and also with the nsEventStateManager handling code for NS_LOSTFOCUS changed to hide the caret if its visible. Previously we were only hiding it if caret browsing was on, which I think was what was causing the "turds".

Comment 28

[Peter Van der Beken [:peterv]]

Comment on attachment 289751 [details] [diff] [review]
Patch v4 - Martijn's patch with caret turd fix

We're getting closer :-).

>Index: layout/base/nsCaret.cpp
>===================================================================

> NS_IMETHODIMP nsCaret::SetCaretVisible(PRBool inMakeVisible)
> {
>   mVisible = inMakeVisible;
>   nsresult  err = NS_OK;
>-  if (mVisible)
>+  if (mVisible) {
>     err = StartBlinking();
>-  else
>+    SetIgnoreUserModify(PR_TRUE);
>+  } else {
>     err = StopBlinking();
>-    
>+    SetIgnoreUserModify(PR_FALSE);
>+  }

Does this work if you turn on caret browsing, focus a contenteditable region and then turn off caret browsing again? Or does the cursor disappear in that case.

>Index: content/events/src/nsEventStateManager.cpp
>===================================================================

>   case NS_LOSTFOCUS:
>     {
>-      // Hide the caret used in "browse with caret mode"
>-      if (mBrowseWithCaret && mPresContext) {
>+      // Hide the caret if it's visible.
>+      if (mPresContext) {
>         nsIPresShell *presShell = mPresContext->GetPresShell();
>-        if (presShell)
>-           SetContentCaretVisible(presShell, mCurrentFocus, PR_FALSE);
>+        if (presShell) {
>+           nsICaret *caret=0;

nsnull
Spaces around =

>+           presShell->GetCaret(&caret);
>+           PRBool caretVisible=PR_FALSE;
>+           if (caret) {
>+             caret->GetCaretVisible(&caretVisible);
>+           }
>+           if (caretVisible) {
>+             SetContentCaretVisible(presShell, mCurrentFocus, PR_FALSE);
>+           }

You can move the |if (caretVisible)| block inside the |if (caret)|

Comment 29

[Chris Pearce [:cpearce (Not reading bugmail)]]

Comment on attachment 289751 [details] [diff] [review]
Patch v4 - Martijn's patch with caret turd fix

(In reply to comment #28)
> Does this work if you turn on caret browsing, focus a contenteditable region
> and then turn off caret browsing again? Or does the cursor disappear in that
> case.

Caret disappears, though it comes back if you refocus. Back to the drawing board...

Comment 30

[Martijn Wargers (dead)]

I filed bug 418055 for the issue I mentioned in comment 21.
I just rediscovered that issue and I completely forgot about this bug, that's why I've now filed it as a new bug.

Comment 31

[Chris Pearce [:cpearce (Not reading bugmail)]]

Attachment: Testcase - contenteditable and non editable paragraphs

(In reply to comment #8)
> Please make sure that this doesn't regress bug 387380 and that the cursor isn't
> enabled when clicking in a non-editable area in a document with contentEditable
> nodes.
> 

This tests this case.

Comment 32

[Chris Pearce [:cpearce (Not reading bugmail)]]

Peterv, can you comment on this please?

I've been looking into this, I can update my patch so that the problem in comment #8 is fixed.

However, I still have the problem that turning off caret browsing in view source mode hides the caret. Clicking in the window brings it back.

The problem is that the view-source window gets the caret to be visible by manually turning it on when it loads, so there's nothing keeping it on when caret-browsing is disabled, which turns off the caret.

There are a few ways I can fix this:

1. Add an accessibility.browsewithcaret listener to the view-source window to turn the caret back on after caret browsing has turned off the caret off.
2. Add code to nsEventStateManager::ResetBrowseWithCaret() which checks to see if it's working on a view-source window, and if so not hide the caret when we disable it.
3. Add a new css style which forces the caret to always be visible, and set that in the content area of the view-source window. Maybe -moz-show-caret?

I think (3) is the least hacky. Peterv, what do you think? 

Comment 33

[Robert O'Callahan (:roc) (email my personal email if necessary)]

A simpler alternative to 3 would be to define a new XUL attribute for the document root element which forces the caret to always be visible, and set that attribute in the view-source window.

Comment 34

[Peter Van der Beken [:peterv]]

I'm fine with a XUL attribute.

Comment 35

[Chris Pearce [:cpearce (Not reading bugmail)]]

Attachment: Patch v5 - v4 with showcursor attribute

This is pretty much patch v4 with the attribute showcursor added. When it's "true" on a window the caret is always drawn. I've modified the view-source xul window to use this, and taken out its old calls to caret->SetEnabled().

Should I document this new attribute somewhere once this patch lands?

Comment 36

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Yes, Mark Finkle can help you with that.

Comment 37

[Chris Pearce [:cpearce (Not reading bugmail)]]

Attachment: Patch v6 - As v5, but with fix for caret turds.

This is the same as v5, but with the fix for caret turds, as identified in bug 418055. I'm including it in this patch, since the original patch for this caused the regression.

Comment 38

[Peter Van der Beken [:peterv]]

Comment on attachment 304396 [details] [diff] [review]
Patch v6 - As v5, but with fix for caret turds.

>Index: content/events/src/nsEventStateManager.cpp
>===================================================================

>+             PRBool caretVisible=PR_FALSE;

Spaces around =

>@@ -5414,22 +5443,30 @@ nsEventStateManager::ResetBrowseWithCare

>+    PRBool isFocusEditable =
>+      (mCurrentFocus) ? mCurrentFocus->HasFlag(NODE_IS_EDITABLE) : PR_FALSE;

Should this also be true for designMode? You could use mCurrentFocus->IsEditable() if so.

>Index: editor/libeditor/text/nsEditorEventListeners.cpp
>===================================================================

>-            caret->SetIgnoreUserModify(PR_FALSE);
>             if (selection) {
>               caret->SetCaretDOMSelection(selection);
>             }
>+            caret->SetIgnoreUserModify(PR_FALSE);

This worries me a bit. I don't know what effect it could have, but wouldn't the DrawCaret to draw the caret from SetCaretDOMSelection potentially use the wrong value for mIgnoreUserModify? In other words, we're currently not erasing the old caret whereas with your patch we'd draw a new caret when we shouldn't? Should the SetIgnoreUserModify happen between erasing and drawing?

>Index: toolkit/components/viewsource/content/viewSource.js
>===================================================================

>Index: toolkit/components/viewsource/content/viewSource.xul
>===================================================================

Probably should do the same changes to suite/browser files.

Comment 39

[Chris Pearce [:cpearce (Not reading bugmail)]]

(In reply to comment #38)
> (From update of attachment 304396 [details] [diff] [review])
> >+             PRBool caretVisible=PR_FALSE;
>
> Spaces around =

Sorry, fixed it now.

> >@@ -5414,22 +5443,30 @@ nsEventStateManager::ResetBrowseWithCare
> >+    PRBool isFocusEditable =
> >+      (mCurrentFocus) ? mCurrentFocus->HasFlag(NODE_IS_EDITABLE) : PR_FALSE;
> 
> Should this also be true for designMode? You could use 
> mCurrentFocus->IsEditable() if so.

I think the "if (editorDocShell)..." above that prevents us getting to that code with a designMode doc. I tried taking the "if (editorDocShell)..." out, and replacing "HasFlag(NODE_IS_EDITABLE)" with "IsEditable()", but it didn't work.

> >Index: editor/libeditor/text/nsEditorEventListeners.cpp
> >===================================================================
> 
> >-            caret->SetIgnoreUserModify(PR_FALSE);
> >             if (selection) {
> >               caret->SetCaretDOMSelection(selection);
> >             }
> >+            caret->SetIgnoreUserModify(PR_FALSE);
> 
> This worries me a bit. I don't know what effect it could have, but wouldn't the
> DrawCaret to draw the caret from SetCaretDOMSelection potentially use the wrong
> value for mIgnoreUserModify? In other words, we're currently not erasing the
> old caret whereas with your patch we'd draw a new caret when we shouldn't?
> Should the SetIgnoreUserModify happen between erasing and drawing?

I considered this, but I couldn't get any problems to occur when I was testing my patch.

Perhaps instead in StopBlinking() we could temporarily set mIgnoreUserModify to true before the DrawCaret() call and restore it after? That way the caret will always be blanked out even if it was drawn in a user-input/modify field.

> >Index: toolkit/components/viewsource/content/viewSource.js
> >Index: toolkit/components/viewsource/content/viewSource.xul
>
> Probably should do the same changes to suite/browser files.

Ok, thanks.

Comment 40

[Chris Pearce [:cpearce (Not reading bugmail)]]

Attachment: Patch v7 - v6 but with Caret::StopBlinking() change to fix caret turds

This is similar to patch v6, but contains my suggestion as per comment 39, Caret::StopBlinking() now temporarily sets mIgnoreUserModify to true before erasing the caret.

Comment 41

[Peter Van der Beken [:peterv]]

Comment on attachment 304857 [details] [diff] [review]
Patch v7 - v6 but with Caret::StopBlinking() change to fix caret turds

>Index: layout/base/nsCaret.h
>===================================================================

>+    

Don't add the trailing spaces.

>+    PRPackedBool          mDrawn;             // Denotes when the caret is physically drawn on the screen,

Comment 42

[Chris Pearce [:cpearce (Not reading bugmail)]]

Attachment: Patch v8 - v7 with peterv's requested changes

Patch v7 with Peterv's requested changes in his review. r+ peterv.

Comment 43

[Robert O'Callahan (:roc) (email my personal email if necessary)]

+GK_ATOM(showcursor, "showcursor")

showcaret please. Cursor is the mouse cursor.

+static PRBool GetWindowShowCursor(nsIDocument *aDocument);

Caret

nsICaret and nsIPresShell need some serious deCOMtamination!

+  caret->SetIgnoreUserModify(PR_TRUE);

Shouldn't this be aEnabled? Or are you intentionally changing behaviour here?

+                                 eIgnoreCase);

Should make it case-sensitive like most other XML attribute values

+    // Temporarily make mIgnoreUserModify true, so that the caret
+    // gets erased if it was drawn in a user-modify or user-input frame.
+    PRBool originalIgnoreUserModify = mIgnoreUserModify;

This is kind of gross. Usually this means we need to factor the internal state or add extra parameters so that DrawCaret will do the right thing on its own.

Comment 44

[Chris Pearce [:cpearce (Not reading bugmail)]]

Attachment: Patch v9 - roc's changes and SetIgnoreUserModify() change

(In reply to comment #43)
> +GK_ATOM(showcursor, "showcursor")
> 
> showcaret please. Cursor is the mouse cursor.
> 
> +static PRBool GetWindowShowCursor(nsIDocument *aDocument);
> 
> Caret

Done and done.

> nsICaret and nsIPresShell need some serious deCOMtamination!
> 
> +  caret->SetIgnoreUserModify(PR_TRUE);
> 
> Shouldn't this be aEnabled? Or are you intentionally changing behaviour here?
 
It doesn't actually matter, so long as it's true when aEnabled is. When aEnabled==false the caret is disabled anyway, so ignoreUserModify has no effect.

I'll change it to aEnabled to match the other cases.

 
> +                                 eIgnoreCase);
> 
> Should make it case-sensitive like most other XML attribute values

Done.

> +    // Temporarily make mIgnoreUserModify true, so that the caret
> +    // gets erased if it was drawn in a user-modify or user-input frame.
> +    PRBool originalIgnoreUserModify = mIgnoreUserModify;
> 
> This is kind of gross. Usually this means we need to factor the internal state
> or add extra parameters so that DrawCaret will do the right thing on its own.
> 

Hmm, add an aIgnoreIgnoreUserModify parameter to DrawCaret()? ;)

The root of the problem is that the caret draw/erase code bails out when mIgnoreUserModify==false, and we're setting IgnoreUserModify=false while the caret is drawn, so the next call to DrawCaret() (e.g. from StopBlinking()) won't erase the old caret.

So I've modified SetIgnoreUserModify() to detect if changing ignoreUserModify would cause the caret to stop being drawn. If so, the next call to DrawAtPositionWithHint() won't erase the caret, so SetIgnoreUserModify() erases it then and there to prevent any caret turds.

Comment 45

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 305667 [details] [diff] [review]
Patch v9 - roc's changes and SetIgnoreUserModify() change

Yeah, I like that better.

Comment 46

[Aaron Leventhal]

Does this by any chance fix bug 412949?

Comment 47

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I think not.

Comment 48

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

Comment on attachment 305667 [details] [diff] [review]
Patch v9 - roc's changes and SetIgnoreUserModify() change

a=beltzner for 1.9

Comment 49

[Reed Loden [:reed]]

Checking in content/base/src/nsGkAtomList.h;
/cvsroot/mozilla/content/base/src/nsGkAtomList.h,v  <--  nsGkAtomList.h
new revision: 3.92; previous revision: 3.91
done
Checking in content/events/src/nsEventStateManager.cpp;
/cvsroot/mozilla/content/events/src/nsEventStateManager.cpp,v  <--  nsEventStateManager.cpp
new revision: 1.731; previous revision: 1.730
done
Checking in layout/base/nsCaret.cpp;
/cvsroot/mozilla/layout/base/nsCaret.cpp,v  <--  nsCaret.cpp
new revision: 1.186; previous revision: 1.185
done
Checking in layout/base/nsCaret.h;
/cvsroot/mozilla/layout/base/nsCaret.h,v  <--  nsCaret.h
new revision: 1.56; previous revision: 1.55
done
Checking in suite/browser/viewSource.xul;
/cvsroot/mozilla/suite/browser/viewSource.xul,v  <--  viewSource.xul
new revision: 1.60; previous revision: 1.59
done
Checking in suite/browser/viewsource.js;
/cvsroot/mozilla/suite/browser/viewsource.js,v  <--  viewsource.js
new revision: 1.50; previous revision: 1.49
done
Checking in toolkit/components/viewsource/content/viewSource.js;
/cvsroot/mozilla/toolkit/components/viewsource/content/viewSource.js,v  <--  viewSource.js
new revision: 1.23; previous revision: 1.22
done
Checking in toolkit/components/viewsource/content/viewSource.xul;
/cvsroot/mozilla/toolkit/components/viewsource/content/viewSource.xul,v  <--  viewSource.xul
new revision: 1.36; previous revision: 1.35
done

Comment 50

[[:Aleksej]]

Verified fixed with Mozilla/5.0 (X11; U; Linux i686 (x86_64); eo; rv:1.9b4pre) Gecko/2008022704 Minefield/3.0b4pre.

Comment 51

[Chris Pearce [:cpearce (Not reading bugmail)]]

Adding user-doc-needed keyword. We need to add to documentation that the showcaret attribute when applied to windows forces the caret to always be visible in that window. See toolkit/components/viewsource/content/viewSource.xul for an example.

Comment 52

[Chris Pearce [:cpearce (Not reading bugmail)]]

user-doc-needed -> dev-doc-needed

Comment 53

[Eric Shepherd [:sheppy]]

What XUL elements can showcaret be used on?  I see it being used on browser in the example, but it looks like it can be used on window as well.  I want to be sure I get this fully covered.

Comment 54

[Robert O'Callahan (:roc) (email my personal email if necessary)]

<browser>, <editor> and <iframe>. Although it's no use on <editor> really.

Comment 55

[Eric Shepherd [:sheppy]]

Docs updated.