[Project_owners] Textbox caret reset
zack.carter at gmail.com
Tue Mar 6 15:20:50 PST 2007
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
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:
> 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.
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.
> 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
More information about the Project_owners