Oh then this was a misunderstanding. I thought you were talking about HTML Like input type="text" things (you meant textarea-like things so). 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 tabs. Greets xeen
On 3/7/07, Zachary Carter <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 > > > [email protected] > > > http://mozdev.org/mailman/listinfo/project_owners > > > > > _______________________________________________ > > Project_owners mailing list > > [email protected] > > http://mozdev.org/mailman/listinfo/project_owners > > > _______________________________________________ > Project_owners mailing list > [email protected] > http://mozdev.org/mailman/listinfo/project_owners > _______________________________________________ Project_owners mailing list [email protected] http://mozdev.org/mailman/listinfo/project_owners
