Attached test case to show issue.

Steps to reproduce:

• Click on "Open" button, modal popup is shown.
• Start to tab through the components (may need to focus on input field in popup), focus can be set on the inputFile component behind the modal background.

The input elements that are not disabled are found in an iframe.

The applied fix stops events from reaching input elements contained by the iframes found underneath the modal popup.

Applied fix to ICEfaces3 trunk and 3.0.x-maintenance branch.

Re-open.

This change has caused a regression in a customer app. In this app. they have pure-JSP application pages hosted inside an iframe in the ICEfaces app. From a submit button within the JSP application, they are invoking the bridge's modality layer (via Ice.modal.start('basePopup', 'xxx/xmlhttp/blank') as part of a scheme to put up a busy indicator while the JSP submit is occurring.

However, with this change in place, the JSP submit never actually occurs as the modal blocker disables the button that was triggering it before it gets generated.

Not at all sure what a good fix for this would be. Maybe the easiest thing is to add a configuration param to disable the blocking of iframe elements so they can turn this off since their use-case is atypical to say the least.

Attached test case to show current issue.

The test case uses an iframe to show some basic html content. There are two buttons that will submit the html form, one that activates the modal panelPopup and another that does not. Both buttons should submit the form, which will navigate to the outer original page. In the case with the button that activates the popup this doesn't take place. Removal of the Ice.modal.start from the JavaScript code allows the form to submit.

Cancel only the events that are not triggered within current iframe.