Warning that Modal Windows are not truly modal, and Panels have this issue too.

[Ben S.]

I want to make you aware that the way Alpha Anywhere generates a modal form is not truly modal. A user with a keyboard can easily Tab out of the form and activate controls on the underlying page. This problem is not unique to the way Alpha creates modal windows, as you can see with this CSS/JS example from w3schools.com.

There is a similar issue when using panels. A user can tab through the controls on the active panel and continue into panels that are not currently visible to the user. A user who has lost sight of the cursor, or who thinks they are active in another application could overwrite data or activate buttons without visibility to the changes. They may be able to access parts of your application they are not supposed to. Imagine the possibilities: Delete, Clear, Disable, Change Status, Print, Send Ballistic Missile Alert, etc.

I created a video so you can see what I'm talking about.

Is this important? Do you want your application to be "Accessible"? Do your users use the tab key? As a developer are you responsible to prevent user pitfalls that may impact data integrity?

The W3C recommendation for Access Rich Internet Application (WAI-ARIA) 1.1 provides some guidelines for an accessible modal dialog:

1. On Dialog Open, Set Focus to the first focusable element
2. On Dialog Close, Return Focus to the Last Focused Element
3. While Open, Prevent Mouse Clicks Outside the Dialog
4. While Open, Prevent Tabbing to Outside the Dialog
5. While Open, Allow the ESC Key to Close the Dialog

Sources:
Creating An Accessible Modal Dialog
https://bitsofco.de/accessible-modal-dialog/
https://www.w3.org/TR/wai-aria/#aria-modal

There are ways via code to capture the tab key to keep the focus in the window. Do you want to write that code for every window? Do you have the skills to write the code and avoid creating side effects? I think it would be great if the RAD tool would handle that for me. The best solution can come from Alpha. This way everyone can use it and it will be a breeze to implement. It will be tested in multiple browsers and we will receive updates to correct issues that arise.

My suggestions are:

• For a modal pop-up dialog, provide a property to enable tab protection. When enabled, this generates additional code for you that will allow normal tab/shift+tab in the dialog but keep focus from leaving it. I suggest this as an optional property so it does not add overhead to your application if you don't want it, like for a mobile application.
• For panels, provide a similar property, or create a special container that you can wrap around areas where you want to "fence in" the tab focus.

In the meantime we can put our heads together in this forum and develop some standardized code and instructions on how to implement it. I'm sure we can come up with many different ways to solve the problem. I'm looking for something that is reusable and easy to implement, like a standardized function that I can make a single call to from each form.

(continued in next message...)

[Ben S.]

Re: Warning that Modal Windows are not truly modal, and Panels have this issue too.

(continued from previous message due to length)

In the meantime we can put our heads together in this forum and develop some standardized code and instructions on how to implement it. I'm sure we can come up with many different ways to solve the problem. I'm looking for something that is reusable and easy to implement, like a standardized function that I can make a single call to from each form.

Here are some suggestions I've already considered which I don’t feel are acceptable:

• Pretend that your users would never hit the tab key.
• Tell users not to hit the tab key.
• Write code around the first and last control on every modal pop-up and panel to trap tab and shift-tab. Make sure the code is updated if the first or last control changes.
• Don’t use panels or modal dialogs in any app that allows a keyboard.

This video shows a solution someone else developed. It works for this one form, but I'm looking for something more reusable that doesn't have hard-coded control names in it.

https://goo.gl/nEg6wF

I found some Stack Overflow discussion of using jQuery to handle this. I don't have a lot of experience with web development. Can someone explain how I could implement code like this into an Alpha application? Review the other solutions on the page that list potential pitfalls.

Keep tabbing within modal pane only
Disable tab key focusing while Bootstrap modal is active

Thanks for reading this far. I think you can tell that I have been thinking about this for a while. Were you aware of the Tab loophole? Does it impact your web application?

Ben

[Peter.Greulich]

Re: Warning that Modal Windows are not truly modal, and Panels have this issue too.

Very interesting!

I haven't tested your findings yet, but I do know the a5.msgbox is definitely not modal. It's just a window. If you include it in the middle of a script, script execution will continue to the end unlike alert().

I know I have had apps where I do trap the user's key strokes in certain situations to control navigation. But I would like to test it when I have a few minutes - the panels and modal UX.

Thanks for letting us know.

[iRadiate]

Re: Warning that Modal Windows are not truly modal, and Panels have this issue too.

This is interesting and concerning. I can certainly duplicate this behavior and I'm not sure how it has eluded detection for so long.

Just wondering if you have approached Alpha about it?

[Davidk]

Re: Warning that Modal Windows are not truly modal, and Panels have this issue too.

Simple fix, depending on what you want to do. In the Popup UX, add this to the Javascript functions...

if (document.addEventListener){ 
	document.addEventListener("keydown",keyCapt,false); //code for Moz
}
else {
	document.attachEvent("onkeydown",keyCapt); //code for IE
}

function keyCapt(e){
	debugger;
	if(e.keyCode === 9){
		if(e.target.name == 'V.R1.LAST_TEXTBOX'){
			{dialog.Object}.setFocus('FIRST_TEXTBOX');
	 		e.preventDefault();
	 	}
	}
}

Capture the TAB key. If you're on the last field, cancel the tab... and go to the first field. Otherwise... let the tab go. Tested in Chrome.

[mikeallenbrown]

Re: Warning that Modal Windows are not truly modal, and Panels have this issue too.

There was another thread on here about this a little while back. I seem to recall saying you could, in the onRenderComplete, set focus to one of the modal window controls and that solved the problem. Tab would then only cycle through controls in the window and not the parent. Could be wrong. Haven't tried this again since the last thread.

EDIT: Found it: https://www.alphasoftware.com/alphaf...404#post732404

[Ben S.]

Re: Warning that Modal Windows are not truly modal, and Panels have this issue too.

Simple fix, depending on what you want to do. In the Popup UX, add this to the Javascript functions...

That's a good start. How do you get it to find the first and last control that can receive focus so it doesn't have to be hard-coded and maintained? The Stack Overflow article I referenced had some suggestions. Also, it needs to to trap the shift-tab.

[Ben S.]

Re: Warning that Modal Windows are not truly modal, and Panels have this issue too.

This is interesting and concerning. I can certainly duplicate this behavior and I'm not sure how it has eluded detection for so long.

Just wondering if you have approached Alpha about it?

This issue was brought up to Alpha in regards to tabbing to hidden panels. The response was along the lines of "this is not something we anticipated being a problem and so there is no built in protection."

[Ben S.]

Re: Warning that Modal Windows are not truly modal, and Panels have this issue too.

There was another thread on here about this a little while back. I seem to recall saying you could, in the onRenderComplete, set focus to one of the modal window controls and that solved the problem. Tab would then only cycle through controls in the window and not the parent. Could be wrong. Haven't tried this again since the last thread.

EDIT: Found it: https://www.alphasoftware.com/alphaf...404#post732404

Can you demonstrate how onRenderComplete works when implemented?

[mikeallenbrown]

Re: Warning that Modal Windows are not truly modal, and Panels have this issue too.

My explanation is in your other thread. I don't have a sample at the moment.

[Davidk]

Re: Warning that Modal Windows are not truly modal, and Panels have this issue too.

Put this into onRenderComplete... it sets up an array of controls... and get the first and last control.

var thisUX = {dialog.object};
var controls = thisUX.columnInfo;
var ctrlArray = [];
	
for (var key in controls) {
	if (!controls.hasOwnProperty(key)) continue;
	ctrlArray.push(key);
}
var firstCtrl = ctrlArray[0];
var lastCtrl = ctrlArray[ctrlArray.length-1];
{dialog.Object}.__tabOrderInfo = {};
{dialog.Object}.__tabOrderInfo.ctrlArray = ctrlArray;
{dialog.Object}.__tabOrderInfo.firstCtrl = firstCtrl;
{dialog.Object}.__tabOrderInfo.lastCtrl = lastCtrl;

Then the Javascript functions would be...

if (document.addEventListener){ 
	document.addEventListener("keydown",keyCapt,false); //code for Moz
}
else {
	document.attachEvent("onkeydown",keyCapt); //code for IE
}

function keyCapt(e){
	var currCtrl = e.target.name.substr(e.target.name.lastIndexOf(".") + 1);
	if(e.keyCode === 9){
		if(currCtrl == {dialog.Object}.__tabOrderInfo.lastCtrl || currCtrl == ''){
			{dialog.Object}.setFocus({dialog.Object}.__tabOrderInfo.firstCtrl);
	 		e.preventDefault();
	 	}
	}
}

Now... there are lots of exceptions to deal with... so you'll need to work those out per popup. E.g. Buttons do not have a target name... it is empty. The above code takes care of this.
Buttons are not part of the dialog.Object controls list.

Some controls cannot get focus... e.g. a Checkbox control... so you'd possible need to work in a check for the control type... and not add that to the array built in onRenderComplete.

In your posted example, using this code, the cursor will happily cycle through the controls... and will not escape the popup window.

[peteconway]

Re: Warning that Modal Windows are not truly modal, and Panels have this issue too.

Just report the bug.

[Davidk]

Re: Warning that Modal Windows are not truly modal, and Panels have this issue too.

Ben did report it... the information is in this thread.

Overall... the developer must look after their application... the flow... and behaviour. Many environments have run into this issue... some try to figure it out. Access had some solutions and Alpha desktop as well... but they were both messy and not always sufficient... and sometimes just bad.

If you're at the end of a page of input... and you want something specific to happen... then make it happen. If the environment can help then great... if not... look after it yourself.

I do agree that if you're in a UX and pop up a modal window... you should absolutely not be able to tab out out that window into a disabled background - that's just simply a bug. If I can fix it with a bit of Javascript then Alpha certainly should be able to. However, that's what we've got.

Panels are a bit different and I always treat them as a possible flow from panel to panel. If I don't want to, or shouldn't leave a panel, then I make sure that happens. I'm not sure I'd want Alpha interfering in this case.

[peteconway]

Re: Warning that Modal Windows are not truly modal, and Panels have this issue too.

OK - agree on the both - the popup is a bug that won't be addressed and the panel is a feature. Good thing you are able to assist people David else who knows how people would move forward on issues like this.

[Davidk]

Re: Warning that Modal Windows are not truly modal, and Panels have this issue too.

I think the bug should be re-submitted... addressing only the non-panel, popup modal window, tab out issue. In a web page, popup window... tabbing through fields is common. You should never be able to tab out... and into a disabled background window... that's ridiculous... I've never seen that.