Bug 749590

Summary:	[webadmin] ENTER/ESC key events are not caught in dialogs that have no focus widgets.
Product:	[Retired] oVirt	Reporter:	Danny Rankevich <drankevi>
Component:	ovirt-engine-webadmin	Assignee:	Vojtech Szocs <vszocs>
Status:	CLOSED CURRENTRELEASE	QA Contact:
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	unspecified	CC:	asaf, ecohen, iheim, vszocs
Target Milestone:	---
Target Release:	3.1
Hardware:	All
OS:	All
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-08-09 07:59:01 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Danny Rankevich 2011-10-27 15:46:40 UTC

Description of problem:
When you have a popup that has no widgets (just text), it does not handles any ESC or ENTER key events.

Version-Release number of selected component (if applicable):
3.0

How reproducible:
Always

Steps to Reproduce:
(this is a specific example, but it happens on any dialog)
1. Open the New Host dialog, fill name
2. Click ok, without configuring power options
3. You get the "no power options" popup
  
Actual results:
You cannot confirm the popup with ENTER, nor dismiss it with ESC.

Expected results:
You should be able to confirm the popup with ENTER, and dismiss it with ESC.

Additional info:
This is because the key handlers are registered by the Editor Visitor on the Editor Widgtes.
Popups that have no widgets, should make sure to register these keys.

Comment 1 Vojtech Szocs 2011-11-15 16:09:14 UTC

Taking this one, I'm gonna try fixing this issue for all WebAdmin dialogs using GWT FocusPanel, which will wrap the actual dialog content panel.

GWT FocusPanel implements Focusable interface and allows registering click and key events.

Proposed solution:

1. When revealing AbstractModelBoundPopupPresenterWidget, onReveal() calls getView().focus(), which will in turn delegate to FocusPanel.setFocus(true). This also means that AbstractModelBoundPopupView subclasses will no longer need to implement focus() on their own -- the FocusPanel dialog content wrapper itself will be focused and ready for receiving key events.

2. Besides UiCommonEditorVisitor that registers KeyPressHandler on each input widget (editor), FocusPanel will also have a KeyPressHandler registered that will do the exact same thing as KeyPressHandler in UiCommonEditorVisitor. This means: ENTER = find a default command and execute it, ESC = find a cancel command and execute it, for the given Dialog model.

The possible downside here is that when the dialog FocusPanel looses its focus (e.g. user clicks away or presses TAB etc.), it will no longer receive key events.

Fallback solution might be adding DOM key event handler on root <body> element, like this:
// before dialog view is shown
reg = RootLayoutPanel.get().addDomHandler(myHandler, KeyDownEvent.getType());
// before dialog view is hidden
reg.removeHandler();

Comment 2 Vojtech Szocs 2011-11-15 16:16:45 UTC

For "popup-over-popup" scenarios (e.g. Adding new host with dialog, and extra confirm dialog pops up asking about power management stuff), the <body> key handler solution might be problematic. Going to try the FocusPanel approach first.

Comment 3 Vojtech Szocs 2011-11-18 19:14:54 UTC

Found a solution that works even when there is nothing focused within the dialog, will send a patch soon.

Comment 4 Vojtech Szocs 2011-11-21 17:05:11 UTC

*** Bug 749171 has been marked as a duplicate of this bug. ***

Comment 7 Itamar Heim 2012-08-09 07:59:01 UTC

closing ON_QA bugs as oVirt 3.1 was released:
http://www.ovirt.org/get-ovirt/