Opened 15 years ago

Closed 15 years ago

Last modified 13 years ago

#3648 closed defect (fixed)

InlineEditBox: need to cancel or save onblur (if autoSave=true)

Reported by: haysmark Owned by: bill
Priority: high Milestone: 0.9
Component: Accessibility Version: 0.9
Keywords: Cc:
Blocked By: Blocking:

Description (last modified by bill)

In the topmost inline textbox in test_InlineEditBox, if you click the text to edit there is no way to cancel the edit; the textbox "sticks" on blur unless/until you change the value to something else, after which it behaves as expected.

Clicking outside the edit widget or it's dropdown (an effective onBlur *on the widget*) should cause the current changes to save, or if no changes were made, should cause a cancel.

(But see related bug #3655 about canceling via the keyboard)

Change History (10)

comment:1 Changed 15 years ago by bill

Owner: changed from bill to ptbrunet
Priority: highnormal
severity: majornormal

In any case should be able to cancel by hitting the ESC key (and of course if autoSave=false there's a cancel button). It's the same as changing a filename in Windows Explorer.

Hmm, but apparently the ESC key isn't working right now. I think that's in Peter's patch?

comment:2 Changed 15 years ago by ptbrunet

Component: DijitAccessibility

comment:3 Changed 15 years ago by bill

Description: modified (diff)
Owner: changed from ptbrunet to bill
Status: newassigned
Summary: Regression in [9508]: no cancelling if autoSave=trueInlineEditBox: need to cancel or save onblur (if autoSave=true)

I split this bug up into keyboard support (#3655) and general clicking support (this bug).

Basically what we need is onBlur and onFocus events on widgets, rather than on dom nodes. Shifting focus from one dom node to another node inside the same widget, or even switching from the widget to the dropdown (and back again), shouldn't cause such an onBlur event, because conceptually you are still inside the widget.

comment:4 Changed 15 years ago by bill

Resolution: fixed
Status: assignedclosed

(In [9561]) Implement onFocus and onBlur at a widget level. Clicking different dom nodes within a widget, or even switching between a ComboButton? and it's drop down menu, will not cause an onBlur event on the Combobutton. The onBlur only happens when focus moves completely away from the widget.

Focus is not quite the right word because it keeps track of a stack of widgets that are all active. Example: Combobutton --> Menu --> MenuItem?.

Needs more testing but seems to be working.

Fixes #3648.

comment:5 Changed 15 years ago by bill

(In [9576]) add gratuitous animations to test (refs #3648)

comment:6 Changed 15 years ago by bill

(In [9599]) For IE, don't publish "focus" events for when user clicks on a blank area of the screen or a non-focusable elements, causing focus to disappear completely.

Refs #3648.

comment:7 Changed 15 years ago by bill

(In [9600]) Better inline doc. Refs #3648.

comment:8 Changed 15 years ago by bill

(In [9631]) improve testcase (refs #3648)

comment:9 Changed 15 years ago by bill

Resolution: fixed

(In [9636]) Bunch of fixes for keyboard support in InlineEditBox?.

Fixes #3482: missing focus events when using InlineEditBox? Accessibility Fixes #3648: Regression in [9508]: no cancelling if autoSave=true (added support for the Esc key.) Fixes #3655: Open inline edit box, don't make change, tab out, edit box stays open Fixes #3674: pressing tab on an open autosave widget should move focus to next widget

Patch from Pete Brunet (IBM, CCLA on file)

comment:10 Changed 15 years ago by bill

(In [9637]) Prevent strange error about "]". Removed the onClick(/*Event*/ evt) callback. (If we need a callback when editing is started should probably be called something different, and doesn't need to be passed the event object.) Refs #3482, #3648, #3655, and #3674.

Note: See TracTickets for help on using tickets.