Closed Bug 74145 Opened 24 years ago Closed 24 years ago

Caret appears in previously disabled input field when you enable it

Categories

(Core :: DOM: Editor, defect)

defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla0.9

People

(Reporter: Brade, Assigned: anthonyd)

References

(Blocks 1 open bug)

Details

(Whiteboard: FIX IN HAND)

Attachments

(2 files)

In a Composer window, choose Insert Image Click on the custom size radio button Notice the caret blinking in the Height editbox. Type "111" Nothing appears in height editfield but the caret is blinking there. The editfield needs to really take focus so typing works or the caret shouldn't blink. (Oh, and if it were up to me, I'd put the focus in the width editfield instead of the height editfield).
This used to work fine until brade commented it out in "doDimensionEnabling()" in version 1.65! Here's what caused the regression: // not sure why we want to give the width field focus; // it certainly doesn't make sense to do this in a generic // enable/disable function which could be called at any time //if (enable) // dialog.widthInput.focus(); But brade's point is correct, so the fix is to have a separate method that does both "doDimensionEnabling()" and then sets focus to "width" edit field. The reason that the caret jumps into the height editfield is not clear to me at all, but it's why I included the "focus()" call in the first place.
Status: NEW → ASSIGNED
Keywords: regression
Target Milestone: --- → mozilla0.9
Kathy: ready for review.
Keywords: patch, review
Whiteboard: FIX IN HAND needs r=, sr=
Small change: I will use "SelectCustomSizeRadio()" as the new method name.
So the real problem here is that setting a previously disabled input widget to enabled causes a caret to appear. This is a general problem and should be solved in editor-owned caret-setting code. Ignore 4/1/1 patch -- it's not the right thing to do.
Status: ASSIGNED → NEW
Keywords: patch, regression, review
Summary: image dialog can't type in height editfield → Caret appears in previously disabled input field when you enable it
Whiteboard: FIX IN HAND needs r=, sr=
Tony and I worked on this -- fix is in his tree. r=cmanske
Assignee: cmanske → anthonyd
accepting
Status: NEW → ASSIGNED
Whiteboard: FIX IN HAND, NEED SR
Erm, OK, but why are we still setting the selection to SELECTION_ON, when the field might not be focussed?
talked with sfraser, and checked in.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Whiteboard: FIX IN HAND, NEED SR → FIX IN HAND
*** Bug 39999 has been marked as a duplicate of this bug. ***
*** Bug 66698 has been marked as a duplicate of this bug. ***
*** Bug 42003 has been marked as a duplicate of this bug. ***
verified on Mac mozilla optimized build from 4am today (including verification of duplicate bugs).
Status: RESOLVED → VERIFIED
Blocks: 77421
Acting on Duplicate resolution from bug 39999 comment 18: *Moving 'Blocks: bug 39985, bug 64451' from bug 39999 to bug 74145. (Take further action as needed.)
Blocks: 39985, focusblink
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: