Closed
Bug 1137973
Opened 9 years ago
Closed 8 years ago
In several (esp. Twitter & Youtube) textboxes (contenteditable divs), cannot use ctrl+right to move the caret to the end of the line (stops at last word). Issue popped up with latest update (36).
Categories
(Core :: DOM: Editor, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 1153237
People
(Reporter: Kainyusanagi, Unassigned)
References
Details
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0 Build ID: 20150222232811 Steps to reproduce: In textbox (Twitter or Youtube esp.) hold ctrl+right arrow to attempt to move caret to end of line. Actual results: Instead of moving to the end of the text line, it moves to the point right before the last word in the text line, and refuses to move further right. ctrl+left arrow or right arrow at any other point works normally; Only when trying to move to the end of the line does it balk. Expected results: It should move to the end of the text line.
I've managed to reproduce this issue on the latest release(42.0) and latest Nightly(46.0a1). User Agent: Mozilla/5.0 (Windows NT 6.1; rv:42.0) Gecko/20100101 Firefox/42.0 Build ID: 20151029151421 User Agent: Mozilla/5.0 (Windows NT 6.1; rv:46.0) Gecko/20100101 Firefox/46.0 Build ID: 20151215030221 Considering this, I will mark this issue as New and assign the appropriate component. If anyone considers that the component is not the right one, please change it to a more appropriate one.
Status: UNCONFIRMED → NEW
Component: Untriaged → Keyboard: Navigation
Ever confirmed: true
Product: Firefox → Core
Component: Keyboard: Navigation → Editor
See Also: → 1153237
Summary: In several (esp. Twitter & Youtube) textboxes, cannot use ctrl+right to move the caret to the end of the line (stops at last word). Issue popped up with latest update (36). → In several (esp. Twitter & Youtube) textboxes (contenteditable divs), cannot use ctrl+right to move the caret to the end of the line (stops at last word). Issue popped up with latest update (36).
Reporter | ||
Comment 3•8 years ago
|
||
1) No, it's not fixed yet. Why is it set to resolved? Because of it being potentially resolved in a far-off build? 2) How is my report two months prior the duplicate?!
@ Kainyusanagi: 1) That's what status "Fixed" means - "this bug is fixed on the Nightly channel (pre-alpha-version)" So you're totally right, it'll take some time for the fix to reach the release version. Given that it was approved for Aurora45 (alpha-version) in bug 1153237 comment 21, I think it'll be fixed in Release ~2016-03-08 (see https://wiki.mozilla.org/RapidRelease/Calendar) 2) It's true that 1153237 should've been marked as duplicate of an earlier bug, but for some reason nobody (including me) did that immediately. That didn't affect the actual work anyway. Sometimes it's rather hard and time-consuming to copy all info to the earlier bug, so - it happens If you don't like any part of my answer, I recommend you to comment on bug 1153237, because this one is already "Resolved" and, most importantly, only 2 people see your comments in this bug report.
Reporter | ||
Comment 5•8 years ago
|
||
Nope, that actually answers my questions- I thought it'd be a better system that would merge newer reports into the older ones when set to duplicate, but apparently not.
You need to log in
before you can comment on or make changes to this bug.
Description
•