Closed Bug 25930 Opened 25 years ago Closed 24 years ago

right arrow when at the end of last text text widget or document causes lost caret/focus

Categories

(Core :: DOM: Editor, defect, P2)

Product:
Core
Component:
DOM: Editor
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: Brade, Assigned: mjudge)

References

Details

(Keywords: relnote, Whiteboard: [PDT-]) 

* click into the url bar in the browser
* select all of the text and delete it
* type "www.mozilla.org"
* press the right arrow key
notice that the caret disappears

this also happens in Composer
setting to m15
Target Milestone: M15
this might be a mike bug (arrow keys are handled by selection).  i'll look into 
it and reassignif needed.
Status: NEW → ASSIGNED
I see on Windows too. Build: 2000020108 WinNT 4 SP6
reassigning to mjudge; mike, i looked at this and dont see any weirdness with the 
content.  If you have <html>foo</html> and right array past the end of "foo", the 
caret goes away.  I think something bad is happening to selection when arrowing.
Assignee: jfrancis → mjudge
Status: ASSIGNED → NEW
This happens on any text field. In form textareas or input texts. on winNT build  
2000021408. Marking OS as ALL.
OS: Mac System 8.5 → All
*** Bug 27877 has been marked as a duplicate of this bug. ***
*** Bug 27877 has been marked as a duplicate of this bug. ***
*** Bug 27958 has been marked as a duplicate of this bug. ***
*** Bug 28574 has been marked as a duplicate of this bug. ***
*** Bug 28574 has been marked as a duplicate of this bug. ***
*** Bug 29642 has been marked as a duplicate of this bug. ***
Hardware: Macintosh → All
*** Bug 30800 has been marked as a duplicate of this bug. ***
*** Bug 30815 has been marked as a duplicate of this bug. ***
This happens also during mail/news message composition which makes writing mail 
dangerous as I navigate a lot there with cursors.
upping to P2; Mike thinks this should be an easy one to fix
Priority: P3 → P2
Keywords: relnote
*** Bug 29088 has been marked as a duplicate of this bug. ***
*** Bug 21935 has been marked as a duplicate of this bug. ***
nominating for beta1 --adding self to cc list as this also affects my area
(Prefs).
Keywords: beta1
Putting on PDT- radar for beta1.
Whiteboard: [PDT-]
*** Bug 32026 has been marked as a duplicate of this bug. ***
*** Bug 32429 has been marked as a duplicate of this bug. ***
I changed the summary to include case of editing a page in mail or web 
composer. Simply using right arrow when at the end messes up the selection.
This currently causes an assert in nsInterfaceState code because 
UpdateParagraphState() is failing. I examined that code and it turns out the
anchor node of the selection is a XULElement whose tagname is "scrollbarbutton"!
Pretty weird!
Summary: right arrow when in text widget causes lost caret/focus → right arrow when at the end of last text text widget or document causes lost caret/focus
*** Bug 34049 has been marked as a duplicate of this bug. ***
*** Bug 34372 has been marked as a duplicate of this bug. ***
*** Bug 34777 has been marked as a duplicate of this bug. ***
moving to M16
Target Milestone: M15 → M16
*** Bug 30038 has been marked as a duplicate of this bug. ***
*** Bug 33770 has been marked as a duplicate of this bug. ***
fixed
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
verified in 10/25 build.
Status: RESOLVED → VERIFIED
This bug still happens in xul textboxes other than the location bar (search 
sidebar, cookie manager).  Reopening.
Status: VERIFIED → REOPENED
Keywords: beta1 → nsbeta1
Resolution: FIXED → ---
Also still happens in composer at the url 
http://bugzilla.mozilla.org/show_bug.cgi?noid, so this might be a regression.

Fwiw, if you hold shift while testing this bug in the search sidebar or in the 
cookie manager, you'll notice that text is selected from where you started 
holding text to the *beginning* of the text field.
Blocks: 62506
*** Bug 62506 has been marked as a duplicate of this bug. ***
I can't repro this on a current windows build, using textfields, textareas and 
the URL bar

remarking fixed
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
I still see this problem for the cases I mentioned in my last comment.  Should 
I file a new bug or reopen this one again?
yes, can you open a new bug about the shift problem
Posted bug 68367 for the search sidebar's textbox and bug 68368 for 
show_bug.cgi in composer.
I still see this at least for the cache size text box, the homepage URL in
prefs, the wrap plain text messages at xx characters still in prefs, and in
dialogs involing bookmark properties. Using B2001020904 on WinME.
matxdr@yahoo.com, that should be covered by bug 68367.
Aha, I can reproduce it too (on linux), in the homepage url in prefs.  Reopening.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Oops, I missed Jesse's comment about the other bug covering this issue.  Closing
again, sorry ...
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
verified in 3/6 build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.