You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Volker Malzahn (JIRA)" <de...@myfaces.apache.org> on 2012/05/29 12:27:23 UTC

[jira] [Commented] (TRINIDAD-1439) Blocking during PPR for IE on return from dialog

    [ https://issues.apache.org/jira/browse/TRINIDAD-1439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13284710#comment-13284710 ] 

Volker Malzahn commented on TRINIDAD-1439:
------------------------------------------

With IE8 I have unsatisfying behaviour with the blocking approach with an invisible DIV:
1. sometimes the blocking functions for normal mouse clicks, sometimes not
2. shortcuts (accesskeys) for HTML elements of the page aren't blocked
3. the browser content is flickering when the focus is set to the divElement and scrollbars are set explicitly after that focussing

I have included a trinidad-fixes.js in our webapp which uses the fixes of trinidad-ui-blocking.patch (mainly setting the DIV's position, width and height) and adds some code to solve the issues 2 and 3. I attach this file to this ticket in the hope that a future release of Trinidad 2.x will contain a more suitable IE blocking.

Regards, Volker
                
> Blocking during PPR for IE on return from dialog
> ------------------------------------------------
>
>                 Key: TRINIDAD-1439
>                 URL: https://issues.apache.org/jira/browse/TRINIDAD-1439
>             Project: MyFaces Trinidad
>          Issue Type: Bug
>          Components: Build
>    Affects Versions:  1.2.11-core
>         Environment: win XP IE
>            Reporter: Gary VanMatre
>         Attachments: Bug8230631.zip, trinidad-blocking-ie-fixes.js, trinidad-ui-blocking.patch
>
>
> The blocking during PPR is not working in IE on a return from dialog.  Trinidad has two strategies for installing blocking during a PPR request.  In FF can register capture listeners to prevent events - maximum timeout of 8 seconds.  In IE, we set focus to a blocking div and register capture events there.  This blocking div was not covering the client area to prevent user input. In addition, the block handler is sometimes not installed until the first click.  This can be problematic for command buttons that get first crack at the event before it bubbles to the document.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira