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)

36 Branch
x86_64
Windows 7
defect
Not set
normal

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).
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
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.
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.