Cursor keys behave weirdly in "view source" window

RESOLVED FIXED in mozilla1.9.1b2

Status

()

defect
RESOLVED FIXED
11 years ago
11 years ago

People

(Reporter: timwi, Assigned: uriber)

Tracking

Trunk
mozilla1.9.1b2
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

Reporter

Description

11 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-GB; rv:1.9b5) Gecko/2008032620 Firefox/3.0b5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-GB; rv:1.9b5) Gecko/2008032620 Firefox/3.0b5

See STR.

Reproducible: Always

Steps to Reproduce:
1. Open "View Source" for any webpage. You get the "View Source" window with the blinking cursor at the beginning of the HTML text.

ALTERNATIVE #1:
2. While the cursor is visible, press "End".

ALTERNATIVE #2:
2. Press "Home" and "End" alternatingly very quickly.
Actual Results:  
IN ALTERNATIVE #1: Cursor moves down one line, stays there for the duration of one blinking interval, then moves to the expected position.

IN ALTERNATIVE #2: Cursor moves back and forth between beginning of first line and beginning of second line.

Expected Results:  
IN ALTERNATIVE #1: Cursor moves to end of line.

IN ALTERNATIVE #2: Cursor moves back and forth between beginning and end of first line.

The same happens anywhere else in the source, not just at the beginning.
Product: Firefox → Toolkit
Assignee

Updated

11 years ago
Status: UNCONFIRMED → NEW
Component: View Source → Selection
Ever confirmed: true
OS: Windows 2000 → All
Product: Toolkit → Core
QA Contact: view.source → selection
Hardware: PC → All
Version: unspecified → Trunk
Assignee

Comment 1

11 years ago
Posted patch patchSplinter Review
The problem here is that MoveCaret() calls TakeFocus() (who notifies listeners, who draw the caret) before updating mHint. So when the caret is drawn for the first time, it's using the wrong hint.

This fix tries to ensure that mHint is set whenever the selection range is replaced or extended (using TakeFocus()), but not otherwise.

I should mention here that TakeFocus() is a horrible piece of crap, and should probably be completely rewritten, or at least extensively refactored (starting from its name - as it has nothing to do with focus).
Assignee: nobody → uriber
Status: NEW → ASSIGNED
Attachment #341342 - Flags: review?(roc)
Assignee

Updated

11 years ago
Blocks: 458399
Uri, I hope its ok when I set the checkin-needed keyword here. So we didn't miss it when the tree is re-opened again.
Keywords: checkin-needed
Assignee

Comment 3

11 years ago
Sure, no problem.
Assignee

Comment 4

11 years ago
Fixed in http://hg.mozilla.org/mozilla-central/rev/abd911498db3.
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
I'm not able to verify the fix on OS X. Aleksej, are you able to on Linux?
Target Milestone: --- → mozilla1.9.1b2
You need to log in before you can comment on or make changes to this bug.