[Project_owners] Textbox caret reset

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


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


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
>


More information about the Project_owners mailing list