Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#10678 closed defect (fixed)

Editor: programmatic widget creation doesn't like focusOnLoad

Reported by: Douglas Hays Owned by: Douglas Hays
Priority: high Milestone: 1.5
Component: Editor Version: 1.4.0
Keywords: Cc: Jared Jurkiewicz
Blocked By: Blocking:

Description

The focusOnLoad:true boolean doesn't work well with programmatic Editor creation. It works on Firefox, but fails with IE and WebKit?.

Attachments (2)

focusOnLoadBug.html (990 bytes) - added by Douglas Hays 10 years ago.
simple testcase
10678.patch (1.6 KB) - added by Douglas Hays 10 years ago.
fix Editor focus issues during load

Download all attachments as: .zip

Change History (11)

Changed 10 years ago by Douglas Hays

Attachment: focusOnLoadBug.html added

simple testcase

comment:1 Changed 10 years ago by Douglas Hays

Cc: Jared Jurkiewicz added
Milestone: tbd1.5

Needs review by jaredj

comment:2 Changed 10 years ago by Douglas Hays

Related problem: It's common for Editor widgets to be created programmatically and then followed by a call to focus() (InlineEditBox/Dialog?). Even if the focus() call is in a setTimeout, the Editor may not have finished loading yet. Editor's focus() method needs to check for isLoaded and possibly queue the focus.

comment:3 Changed 10 years ago by Douglas Hays

Another related issue: Editor's focus method sometimes does a placeCursorAtStart (non-IE). But related to the original problem in this ticket, the call to placeCursorAtStart needs to happen for IE also, and in addition, it should happen anytime setValue is called since this effectively resets the caret position.

comment:4 Changed 10 years ago by Douglas Hays

The 2nd problem above can be seen by running test_InlineEditBox.html, locate the Editor test near the bottom and click the text. The input caret is not seen (tested Chrome 4, FF 3, and IE 7.
the last problem can be seen by running test_InlineEditBox.html with Chrome. Click the text and an Editor widget is created. Click cancel, and then click the text again. This time, an Editor widget is NOT created but just setValue is called on an existing Editor widget and then focus() but placeCursorAtStart should have been called but wasn't.

Changed 10 years ago by Douglas Hays

Attachment: 10678.patch added

fix Editor focus issues during load

comment:5 Changed 10 years ago by Douglas Hays

Resolution: fixed
Status: newclosed

(In [21291]) Fixes #10678 !strict. Changed focus() to be deferrable during Editor initialization. After the Editor value is changed, focusing will cause the cursor to go to the start. Added automated test.

comment:6 Changed 10 years ago by Jared Jurkiewicz

(In [21293]) Fixing selection restore issue caused by 10678, broke selection restore on IE. refs #10678

comment:7 Changed 10 years ago by Jared Jurkiewicz

(In [21294]) Didn't mean to leave prettyprint enabled. refs #10678

comment:8 Changed 10 years ago by Jared Jurkiewicz

(In [21295]) Fixing selection restore issue caused by 10678 futher, need to cleat on mousedown too. refs #10678

comment:9 Changed 10 years ago by Jared Jurkiewicz

(In [21316]) Fixing regression triggered by the moveCursorToStart added by Doug. The error occurs in the case of the first mouse click to set position being ignored if a plugin that requires position is then immediately used. Need to clear that flag on position clicks. \!strict refs #10678

Note: See TracTickets for help on using tickets.