[prev in list] [next in list] [prev in thread] [next in thread] 

List:       myfaces-dev
Subject:    [jira] [Commented] (TRINIDAD-1439) Blocking during PPR for IE on return from dialog
From:       "Volker Malzahn (JIRA)" <dev () myfaces ! apache ! org>
Date:       2012-05-29 10:27:23
Message-ID: 707146151.10472.1338287243384.JavaMail.jiratomcat () issues-vm
[Download RAW message or body]


    [ https://issues.apache.org/jira/browse/TRINIDAD-1439?page=com.atlassian.jira.plug \
in.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

        


[prev in list] [next in list] [prev in thread] [next in thread]