[Project_owners] Textbox caret reset

xeen aka.xeen at gmail.com
Tue Mar 6 22:22:51 PST 2007

Oh then this was a misunderstanding. I thought you were talking about
HTML Like input type="text" things (you meant textarea-like things
If that's the case how you described it, I would regard this a bug
since HTML textarea keeps caret position as well if switching to other

On 3/7/07, Zachary Carter <zack.carter at gmail.com> wrote:
> Let me explain more. I have a tabbed editor; the textboxes are each in
> their own tabpanel. The status bar keeps track of line, column, etc,
> of the current textbox and switches value when a new tab is selected.
> This used to function well, but I have noticed recently that when ever
> I focus a tab (so the ring appears on the text) or click on a tree
> cell then return focus to the textbox, the caret resets.
> On 3/6/07, xeen <aka.xeen at gmail.com> wrote:
> > Well, I've never seen any textboxes retain their carent position and I
> > would find it pretty odd, as well. Because to focus a textbox again,
> > you need to click it (apart from less frequently used tab or key
> > combination), and by doing so you actually set the new caret position,
> > so there's no benefit in saving this... or do I misunderstand
> > something?
> There are occurrences when the textbox is focused rather then when
> clicking inside of it. Some examples are when the textbox scrollbar is
> pressed or when a tab is switched in my editor situation, or any other
> scripted situation where focus is moved to the texbox. The textbox is
> focused but the user loses their current position, even though they
> never set a new one by clicking inside the editable area. Also, if
> they were to hold shift when clicking in the textbox, it would select
> everything from the beginning of the text and not from where they last
> left the caret. You see where issues can arrise with this.
> I would consider it standard behavior for the caret to be left alone
> unless the user or application explicitly directs it elswhere, which
> is pretty much my experience with any other textbox-ish area. I can
> probably switch to using the editor element instead, it's just that
> finding the line number and column in a textbox was so much easier. :(
> > Anyway, if you want to fix this, just save the position on e.g.
> > onInput and restore it later:
> >
> > selStart=aTextbox.selectionStart;
> > selEnd=aTextbox.selectionEnd;
> >
> > aTextbox.setSelectionRange(selStart,selEnd);
> >
> > Saves selection as well, if you want to retain selection, you probably
> > want to fire the restore method upon onblur so it doesn't get
> > deselected. If nothing is selected then selStart==selEnd will only
> > restore the caret position.
> > Greets
> > xeen
> >
> I could cook up something like this, but it might be more trouble than
> it's worth. There are also some related issues occurring with
> textboxes, so I'll probably still have to give them up. Thanks though.
> Zach
> >
> > On 3/5/07, Zachary Carter <zack.carter at gmail.com> wrote:
> > > My extension requires the textbox caret position stay put unless the
> > > user changes it by interacting with the field. I find it odd that XUL
> > > textboxes reset the caret position (back to the first char) when
> > > another element in the same window is focused (focusing other windows
> > > and their elements dont' have this effect). I know for a fact that
> > > this wasn't always the case but I seemed to have overlooked what
> > > version of Firefox this behavior changed (I could have sworn at least
> > > Firefox 2.0 initial release did not reset the position). This seems to
> > > only happen with the XUL wrapped textareas and not your normal HTML
> > > textarea.
> > >
> > > This might be the final incentive for me to just switch to the editor
> > > tag, but I was wondering if anyone else has noticed this behavior. I
> > > would categorize it as a bug, but maybe it is intended for some
> > > reason...
> > > _______________________________________________
> > > Project_owners mailing list
> > > Project_owners at mozdev.org
> > > http://mozdev.org/mailman/listinfo/project_owners
> > >
> > _______________________________________________
> > Project_owners mailing list
> > Project_owners at mozdev.org
> > http://mozdev.org/mailman/listinfo/project_owners
> >
> _______________________________________________
> Project_owners mailing list
> Project_owners at mozdev.org
> http://mozdev.org/mailman/listinfo/project_owners

More information about the Project_owners mailing list