#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)
Change History (16)
comment:1 Changed 13 years ago by
Milestone: | tbd → 1.4 |
---|---|
Owner: | set to Douglas Hays |
Changed 13 years ago by
Attachment: | 10016.patch added |
---|
comment:2 Changed 13 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
(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 13 years ago by
Resolution: | fixed |
---|---|
Status: | closed → reopened |
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 13 years ago by
Attachment: | 10016_inlineEditBoxBlur.diff added |
---|
Fix to closing dropdowns when setting value of InlineEditBox?.
comment:4 Changed 13 years ago by
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 13 years ago by
in IE, the TooltipDialog? always goes away after the InlineEditBox? closes.
comment:6 Changed 13 years ago by
hrm.....not seeing it anymore now. :/
Let me see if I can whip up a test case.
Changed 13 years ago by
Attachment: | 10016_2.patch added |
---|
possible fix to handle InlineEditBox? inside a popup
comment:7 Changed 13 years ago by
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 13 years ago by
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 13 years ago by
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
(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 13 years ago by
Resolution: | fixed |
---|---|
Status: | closed → reopened |
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 13 years ago by
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 13 years ago by
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
(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 12 years ago by
(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).
proposed patch - needs testing and automated test created