Opened 10 years ago

Closed 10 years ago

Last modified 9 years ago

#10016 closed defect (fixed)

InlineEditBox with a Currency editor does not format when Enter is used to accept the value

Reported by: Nick Fenwick Owned by: Douglas Hays
Priority: high Milestone: 1.4
Component: Dijit Version: 1.3.2
Keywords: Cc: Nathan Toone
Blocked By: Blocking:

Description

Pressing Enter to accept the edited value of the edit dijit does not properly format the value. This is my first use of the InlineEditBox? so I don't know the mechanics very well at present.

1/ go to http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/tests/test_InlineEditBox.html

2/ In the first section, "Form Letter With Blanks", left click the "Please remit" editor. Type in e.g. "123" and hit Enter.

3/ Value is turned back into an non-editable span, but is not formatted as currently.

Expected behaviour - the value should be turned into "£123.00". Actual behaviour - the value is left as "123".

Other methods of accepting the value, such as clicking off the editor or pressing Tab to leave it, format the value correctly.

This also seems to happen with other editors, e.g. the Date field "on" later on the same line.. I can type "1/6/09" into the date edit box and hit enter, and it is left as that, but if I type "2/6/09" and click off the edit box, it is reformatted to "2/6/2009".

I'll be looking at this more later. Anyone happen to know about this already?

Attachments (4)

10016.patch (4.8 KB) - added by Douglas Hays 10 years ago.
proposed patch - needs testing and automated test created
10016_inlineEditBoxBlur.diff (1.2 KB) - added by Nathan Toone 10 years ago.
Fix to closing dropdowns when setting value of InlineEditBox?.
10016_2.patch (4.7 KB) - added by Douglas Hays 10 years ago.
possible fix to handle InlineEditBox? inside a popup
10016_3.patch (24.8 KB) - added by Douglas Hays 10 years ago.
changed InlineEditBox? to be able to focus the displayNode in order to cause a blur of the editor widget

Download all attachments as: .zip

Change History (16)

comment:1 Changed 10 years ago by Douglas Hays

Milestone: tbd1.4
Owner: set to Douglas Hays

Changed 10 years ago by Douglas Hays

Attachment: 10016.patch added

proposed patch - needs testing and automated test created

comment:2 Changed 10 years ago by Douglas Hays

Resolution: fixed
Status: newclosed

(In [20491]) Fixes #10016 !strict. Reroute all InlineEditBox? save/cancel operations thru _onBlur for consistent handling. Added several automated tests for InlineEditBox?.

comment:3 Changed 10 years ago by Nathan Toone

Resolution: fixed
Status: closedreopened

The fix in [20491] causes problems when the inline edit box is within a tooltip or a dropdown, because it causes ALL nodes to lose their focus, thus closing the dropdowns.

Suggest calling this._onBlur() directly - rather than blurring the actual focus node. (Patch follows).

Changed 10 years ago by Nathan Toone

Fix to closing dropdowns when setting value of InlineEditBox?.

comment:4 Changed 10 years ago by Douglas Hays

Cc: Nathan Toone added

toonetown, can you provide a small example that shows the blur() causing problems? I tried to add an InlineEditBox? to a test_TooltipDialog.html and it closes with either a blur or _onBlur call.

comment:5 Changed 10 years ago by Douglas Hays

in IE, the TooltipDialog? always goes away after the InlineEditBox? closes.

comment:6 Changed 10 years ago by Nathan Toone

hrm.....not seeing it anymore now. :/

Let me see if I can whip up a test case.

Changed 10 years ago by Douglas Hays

Attachment: 10016_2.patch added

possible fix to handle InlineEditBox? inside a popup

comment:7 Changed 10 years ago by Douglas Hays

toonetown, please test with the 10016_2.patch file to see if everything works OK for you. I changed test_TooltipDialog.html to have an InlineEditBox? in the first popup Dialog to aid in testing. I think I also fixed the IE problems where the popup dialogs where going away all the time after ESC.

comment:8 Changed 10 years ago by Nathan Toone

Close...

ew.domNode.removeNode is only valid in IE...

Changing it to read:

if(ew.domNode && ew.domNode.removeNode){
    ew.domNode = ew.domNode.removeNode(true); // prevents IE focus problems
}

Seems to work.

comment:9 Changed 10 years ago by Douglas Hays

Resolution: fixed
Status: reopenedclosed

(In [20629]) Fixes #10016. Removed blur() calls and called _onBlur instead. Added InlineEditBox/TooltipDialog? automated test. Fixed IE focus problems related to destroying the InlineEditBox? edit widget.

comment:10 Changed 10 years ago by bill

Resolution: fixed
Status: closedreopened

Unfortunately [20629] brings back the problem of #10052. It's causing the InlineEditBox regression to fail on IE8, but the problem can be seen by simply clicking the first InlineEditBox in test_InlineEditBox.html and then tabbing away, and watch how focus on the second field disappears after a moment. The second field just flashes.

Changed 10 years ago by Douglas Hays

Attachment: 10016_3.patch added

changed InlineEditBox? to be able to focus the displayNode in order to cause a blur of the editor widget

comment:11 Changed 10 years ago by Douglas Hays

Resolution: fixed
Status: reopenedclosed

(In [20659]) Fixes #10016 !strict. Changed ENTER key processing to focus the original display node and then wait for _onBlur events which will have formatted the values correctly. Changed textarea processing to preserve new lines and added a testcase for this in robot/InlineEditBox.html. Changed the editor to be cached until the display node is fully blurred to avoid an IE 8 focus problem that closes a container popup containing an inlineeditbox widget. Change attr('value', "blah") to process based on the renderAsHtml flag. Changed this.value to maintain its original value and not return filtered output based on renderAsHtml since that's only for rendering and not related to the actual widget value.

comment:12 Changed 9 years ago by bill

(In [22236]) Fix IE focus problems in the robot tests Toolbar.html and TooltipDialog.html.

Show/hide of popups was implemented via dynamic addition/deletion of DOM nodes to the document. Those dynamic additions/deletions caused the current node to lose focus, or when the user tabs to a new field it gets focus momentarily but then focus jumps to <body>.

Best solution I could come up with was to pre-create the popup wrapper <div> and then not recycle wrapper <div> or <iframe> (although a possible optimization would be to recycle the iframe).

Fixes #10404, #11193, refs #11132, #10016, #10167 !strict.

Note: See TracTickets for help on using tickets.