You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Venkata Guddanti (Created) (JIRA)" <de...@myfaces.apache.org> on 2012/01/06 23:24:42 UTC
[jira] [Created] (TRINIDAD-2194) Trinidad PPR blocking does not
work with 2 clicks that post
Trinidad PPR blocking does not work with 2 clicks that post
-----------------------------------------------------------
Key: TRINIDAD-2194
URL: https://issues.apache.org/jira/browse/TRINIDAD-2194
Project: MyFaces Trinidad
Issue Type: Bug
Components: Infrastructure
Reporter: Venkata Guddanti
n IE the blocking is initiated on the very first click that happens after a ppr request is sent to server. This is done via "onclick" attachEvent handler(_pprConsumeFirstClick) on the document. The problem is that attachEvent is invoked only in the bubble phase. In IE7/IE8 there is no way to set up an event handler at the capture phase. In this case the AJAX requests are initiated by the "onclick" event handler on the link. Since the click event listener is at target phase, it is always invoked first. So here is what happens when the user clicks on the Next link 2 times:
1) AJAX Request initiated on "onclick" handler
2) Set up the "onclick" attachEvent on the document (_pprConsumeFirstClick)
3) User clicks on link again
4) Since there is already an "onclick" handler, another AJAX request is queued.
5) the _pprConsumeFirstClick "onclick" document handler kicks in, which setups event capture. It is now too late.
We believe because of TRINIDAD-952 we do not need to start blocking after the second click. We can start immediately since we are letting the first event pass through because of a timeout:
if (_agent.isIE)
{
// see TRINIDAD-952 - IE does not update the activeElement in time before
// blocking starts. Use a timeout to allow the update.
win._pprTimeoutFunc = win.setTimeout("_doPprStartBlocking(window);",
1);
return;
}
The second part of the fix is to restore the scroll location after we set focus on the blocking div.
--
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
[jira] [Issue Comment Edited] (TRINIDAD-2194) Trinidad PPR blocking
does not work with 2 clicks that post
Posted by "Venkata Guddanti (Issue Comment Edited) (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TRINIDAD-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13192310#comment-13192310 ]
Venkata Guddanti edited comment on TRINIDAD-2194 at 1/24/12 5:55 PM:
---------------------------------------------------------------------
Please re-commit escalatedCustPPRBlocking1.2.12.6.2.patch to the 1.2.12.6.2 branch
Please also commit escalatedCustPPRBlocking.patch to https://svn.apache.org/repos/asf/myfaces/trinidad/branches/2.0.0.1-branch branch as well
was (Author: venkata.guddanti):
Please commit escalatedCustPPRBlocking.patch to https://svn.apache.org/repos/asf/myfaces/trinidad/branches/2.0.0.1-branch branch as well
> Trinidad PPR blocking does not work with 2 clicks that post
> -----------------------------------------------------------
>
> Key: TRINIDAD-2194
> URL: https://issues.apache.org/jira/browse/TRINIDAD-2194
> Project: MyFaces Trinidad
> Issue Type: Bug
> Components: Infrastructure
> Reporter: Venkata Guddanti
> Assignee: Blake Sullivan
> Fix For: 2.0.0-core
>
> Attachments: escalatedCustPPRBlocking.patch, escalatedCustPPRBlocking1.2.12.3.patch, escalatedCustPPRBlocking1.2.12.6.2.patch
>
> Original Estimate: 8h
> Remaining Estimate: 8h
>
> n IE the blocking is initiated on the very first click that happens after a ppr request is sent to server. This is done via "onclick" attachEvent handler(_pprConsumeFirstClick) on the document. The problem is that attachEvent is invoked only in the bubble phase. In IE7/IE8 there is no way to set up an event handler at the capture phase. In this case the AJAX requests are initiated by the "onclick" event handler on the link. Since the click event listener is at target phase, it is always invoked first. So here is what happens when the user clicks on the Next link 2 times:
> 1) AJAX Request initiated on "onclick" handler
> 2) Set up the "onclick" attachEvent on the document (_pprConsumeFirstClick)
> 3) User clicks on link again
> 4) Since there is already an "onclick" handler, another AJAX request is queued.
> 5) the _pprConsumeFirstClick "onclick" document handler kicks in, which setups event capture. It is now too late.
> We believe because of TRINIDAD-952 we do not need to start blocking after the second click. We can start immediately since we are letting the first event pass through because of a timeout:
> if (_agent.isIE)
> {
> // see TRINIDAD-952 - IE does not update the activeElement in time before
> // blocking starts. Use a timeout to allow the update.
> win._pprTimeoutFunc = win.setTimeout("_doPprStartBlocking(window);",
> 1);
> return;
> }
> The second part of the fix is to restore the scroll location after we set focus on the blocking div.
--
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
[jira] [Commented] (TRINIDAD-2194) Trinidad PPR blocking does not
work with 2 clicks that post
Posted by "Blake Sullivan (Commented) (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TRINIDAD-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13181667#comment-13181667 ]
Blake Sullivan commented on TRINIDAD-2194:
------------------------------------------
Resolved in trunk in revision 1228484
Resolved in 1.2.12.6.2 in revision 1228488
> Trinidad PPR blocking does not work with 2 clicks that post
> -----------------------------------------------------------
>
> Key: TRINIDAD-2194
> URL: https://issues.apache.org/jira/browse/TRINIDAD-2194
> Project: MyFaces Trinidad
> Issue Type: Bug
> Components: Infrastructure
> Reporter: Venkata Guddanti
> Attachments: escalatedCustPPRBlocking.patch, escalatedCustPPRBlocking1.2.12.6.2.patch
>
> Original Estimate: 8h
> Remaining Estimate: 8h
>
> n IE the blocking is initiated on the very first click that happens after a ppr request is sent to server. This is done via "onclick" attachEvent handler(_pprConsumeFirstClick) on the document. The problem is that attachEvent is invoked only in the bubble phase. In IE7/IE8 there is no way to set up an event handler at the capture phase. In this case the AJAX requests are initiated by the "onclick" event handler on the link. Since the click event listener is at target phase, it is always invoked first. So here is what happens when the user clicks on the Next link 2 times:
> 1) AJAX Request initiated on "onclick" handler
> 2) Set up the "onclick" attachEvent on the document (_pprConsumeFirstClick)
> 3) User clicks on link again
> 4) Since there is already an "onclick" handler, another AJAX request is queued.
> 5) the _pprConsumeFirstClick "onclick" document handler kicks in, which setups event capture. It is now too late.
> We believe because of TRINIDAD-952 we do not need to start blocking after the second click. We can start immediately since we are letting the first event pass through because of a timeout:
> if (_agent.isIE)
> {
> // see TRINIDAD-952 - IE does not update the activeElement in time before
> // blocking starts. Use a timeout to allow the update.
> win._pprTimeoutFunc = win.setTimeout("_doPprStartBlocking(window);",
> 1);
> return;
> }
> The second part of the fix is to restore the scroll location after we set focus on the blocking div.
--
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
[jira] [Issue Comment Edited] (TRINIDAD-2194) Trinidad PPR blocking
does not work with 2 clicks that post
Posted by "Venkata Guddanti (Issue Comment Edited) (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TRINIDAD-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13185929#comment-13185929 ]
Venkata Guddanti edited comment on TRINIDAD-2194 at 1/17/12 9:15 PM:
---------------------------------------------------------------------
This fix needs to be rolled out of since it did not go through the oracle internal process for getting it approved.
Once the internal process provides the permission to commit, the fix needs to be then committed to appropriate branch.
was (Author: venkata.guddanti):
This fix needs to be rolled out of 11.1.1.6.2 since it did not go through the oracle internal process for getting it approved.
Once the internal process provides the permission to commit, the fix needs to be then committed to 11.1.1.6.2 branch.
> Trinidad PPR blocking does not work with 2 clicks that post
> -----------------------------------------------------------
>
> Key: TRINIDAD-2194
> URL: https://issues.apache.org/jira/browse/TRINIDAD-2194
> Project: MyFaces Trinidad
> Issue Type: Bug
> Components: Infrastructure
> Reporter: Venkata Guddanti
> Assignee: Blake Sullivan
> Fix For: 2.0.0-core
>
> Attachments: escalatedCustPPRBlocking.patch, escalatedCustPPRBlocking1.2.12.6.2.patch
>
> Original Estimate: 8h
> Remaining Estimate: 8h
>
> n IE the blocking is initiated on the very first click that happens after a ppr request is sent to server. This is done via "onclick" attachEvent handler(_pprConsumeFirstClick) on the document. The problem is that attachEvent is invoked only in the bubble phase. In IE7/IE8 there is no way to set up an event handler at the capture phase. In this case the AJAX requests are initiated by the "onclick" event handler on the link. Since the click event listener is at target phase, it is always invoked first. So here is what happens when the user clicks on the Next link 2 times:
> 1) AJAX Request initiated on "onclick" handler
> 2) Set up the "onclick" attachEvent on the document (_pprConsumeFirstClick)
> 3) User clicks on link again
> 4) Since there is already an "onclick" handler, another AJAX request is queued.
> 5) the _pprConsumeFirstClick "onclick" document handler kicks in, which setups event capture. It is now too late.
> We believe because of TRINIDAD-952 we do not need to start blocking after the second click. We can start immediately since we are letting the first event pass through because of a timeout:
> if (_agent.isIE)
> {
> // see TRINIDAD-952 - IE does not update the activeElement in time before
> // blocking starts. Use a timeout to allow the update.
> win._pprTimeoutFunc = win.setTimeout("_doPprStartBlocking(window);",
> 1);
> return;
> }
> The second part of the fix is to restore the scroll location after we set focus on the blocking div.
--
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
[jira] [Updated] (TRINIDAD-2194) Trinidad PPR blocking does not
work with 2 clicks that post
Posted by "Venkata Guddanti (Updated) (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TRINIDAD-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Venkata Guddanti updated TRINIDAD-2194:
---------------------------------------
Status: Patch Available (was: Open)
> Trinidad PPR blocking does not work with 2 clicks that post
> -----------------------------------------------------------
>
> Key: TRINIDAD-2194
> URL: https://issues.apache.org/jira/browse/TRINIDAD-2194
> Project: MyFaces Trinidad
> Issue Type: Bug
> Components: Infrastructure
> Reporter: Venkata Guddanti
> Attachments: escalatedCustPPRBlocking.patch, escalatedCustPPRBlocking1.2.12.6.2.patch
>
> Original Estimate: 8h
> Remaining Estimate: 8h
>
> n IE the blocking is initiated on the very first click that happens after a ppr request is sent to server. This is done via "onclick" attachEvent handler(_pprConsumeFirstClick) on the document. The problem is that attachEvent is invoked only in the bubble phase. In IE7/IE8 there is no way to set up an event handler at the capture phase. In this case the AJAX requests are initiated by the "onclick" event handler on the link. Since the click event listener is at target phase, it is always invoked first. So here is what happens when the user clicks on the Next link 2 times:
> 1) AJAX Request initiated on "onclick" handler
> 2) Set up the "onclick" attachEvent on the document (_pprConsumeFirstClick)
> 3) User clicks on link again
> 4) Since there is already an "onclick" handler, another AJAX request is queued.
> 5) the _pprConsumeFirstClick "onclick" document handler kicks in, which setups event capture. It is now too late.
> We believe because of TRINIDAD-952 we do not need to start blocking after the second click. We can start immediately since we are letting the first event pass through because of a timeout:
> if (_agent.isIE)
> {
> // see TRINIDAD-952 - IE does not update the activeElement in time before
> // blocking starts. Use a timeout to allow the update.
> win._pprTimeoutFunc = win.setTimeout("_doPprStartBlocking(window);",
> 1);
> return;
> }
> The second part of the fix is to restore the scroll location after we set focus on the blocking div.
--
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
[jira] [Commented] (TRINIDAD-2194) Trinidad PPR blocking does not
work with 2 clicks that post
Posted by "Blake Sullivan (Commented) (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TRINIDAD-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13188041#comment-13188041 ]
Blake Sullivan commented on TRINIDAD-2194:
------------------------------------------
Reverted changes to branch 1.2.12.6.2 in revision 1232592
> Trinidad PPR blocking does not work with 2 clicks that post
> -----------------------------------------------------------
>
> Key: TRINIDAD-2194
> URL: https://issues.apache.org/jira/browse/TRINIDAD-2194
> Project: MyFaces Trinidad
> Issue Type: Bug
> Components: Infrastructure
> Reporter: Venkata Guddanti
> Assignee: Blake Sullivan
> Fix For: 2.0.0-core
>
> Attachments: escalatedCustPPRBlocking.patch, escalatedCustPPRBlocking1.2.12.3.patch, escalatedCustPPRBlocking1.2.12.6.2.patch
>
> Original Estimate: 8h
> Remaining Estimate: 8h
>
> n IE the blocking is initiated on the very first click that happens after a ppr request is sent to server. This is done via "onclick" attachEvent handler(_pprConsumeFirstClick) on the document. The problem is that attachEvent is invoked only in the bubble phase. In IE7/IE8 there is no way to set up an event handler at the capture phase. In this case the AJAX requests are initiated by the "onclick" event handler on the link. Since the click event listener is at target phase, it is always invoked first. So here is what happens when the user clicks on the Next link 2 times:
> 1) AJAX Request initiated on "onclick" handler
> 2) Set up the "onclick" attachEvent on the document (_pprConsumeFirstClick)
> 3) User clicks on link again
> 4) Since there is already an "onclick" handler, another AJAX request is queued.
> 5) the _pprConsumeFirstClick "onclick" document handler kicks in, which setups event capture. It is now too late.
> We believe because of TRINIDAD-952 we do not need to start blocking after the second click. We can start immediately since we are letting the first event pass through because of a timeout:
> if (_agent.isIE)
> {
> // see TRINIDAD-952 - IE does not update the activeElement in time before
> // blocking starts. Use a timeout to allow the update.
> win._pprTimeoutFunc = win.setTimeout("_doPprStartBlocking(window);",
> 1);
> return;
> }
> The second part of the fix is to restore the scroll location after we set focus on the blocking div.
--
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
[jira] [Reopened] (TRINIDAD-2194) Trinidad PPR blocking does not
work with 2 clicks that post
Posted by "Venkata Guddanti (Reopened) (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TRINIDAD-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Venkata Guddanti reopened TRINIDAD-2194:
----------------------------------------
This fix needs to be rolled out of 11.1.1.6.2 since it did not go through the oracle internal process for getting it approved.
Once the internal process provides the permission to commit, the fix needs to be then committed to 11.1.1.6.2 branch.
> Trinidad PPR blocking does not work with 2 clicks that post
> -----------------------------------------------------------
>
> Key: TRINIDAD-2194
> URL: https://issues.apache.org/jira/browse/TRINIDAD-2194
> Project: MyFaces Trinidad
> Issue Type: Bug
> Components: Infrastructure
> Reporter: Venkata Guddanti
> Assignee: Blake Sullivan
> Fix For: 2.0.0-core
>
> Attachments: escalatedCustPPRBlocking.patch, escalatedCustPPRBlocking1.2.12.6.2.patch
>
> Original Estimate: 8h
> Remaining Estimate: 8h
>
> n IE the blocking is initiated on the very first click that happens after a ppr request is sent to server. This is done via "onclick" attachEvent handler(_pprConsumeFirstClick) on the document. The problem is that attachEvent is invoked only in the bubble phase. In IE7/IE8 there is no way to set up an event handler at the capture phase. In this case the AJAX requests are initiated by the "onclick" event handler on the link. Since the click event listener is at target phase, it is always invoked first. So here is what happens when the user clicks on the Next link 2 times:
> 1) AJAX Request initiated on "onclick" handler
> 2) Set up the "onclick" attachEvent on the document (_pprConsumeFirstClick)
> 3) User clicks on link again
> 4) Since there is already an "onclick" handler, another AJAX request is queued.
> 5) the _pprConsumeFirstClick "onclick" document handler kicks in, which setups event capture. It is now too late.
> We believe because of TRINIDAD-952 we do not need to start blocking after the second click. We can start immediately since we are letting the first event pass through because of a timeout:
> if (_agent.isIE)
> {
> // see TRINIDAD-952 - IE does not update the activeElement in time before
> // blocking starts. Use a timeout to allow the update.
> win._pprTimeoutFunc = win.setTimeout("_doPprStartBlocking(window);",
> 1);
> return;
> }
> The second part of the fix is to restore the scroll location after we set focus on the blocking div.
--
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
[jira] [Commented] (TRINIDAD-2194) Trinidad PPR blocking does not
work with 2 clicks that post
Posted by "Venkata Guddanti (Commented) (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TRINIDAD-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13192310#comment-13192310 ]
Venkata Guddanti commented on TRINIDAD-2194:
--------------------------------------------
Please commit escalatedCustPPRBlocking.patch to https://svn.apache.org/repos/asf/myfaces/trinidad/branches/2.0.0.1-branch branch as well
> Trinidad PPR blocking does not work with 2 clicks that post
> -----------------------------------------------------------
>
> Key: TRINIDAD-2194
> URL: https://issues.apache.org/jira/browse/TRINIDAD-2194
> Project: MyFaces Trinidad
> Issue Type: Bug
> Components: Infrastructure
> Reporter: Venkata Guddanti
> Assignee: Blake Sullivan
> Fix For: 2.0.0-core
>
> Attachments: escalatedCustPPRBlocking.patch, escalatedCustPPRBlocking1.2.12.3.patch, escalatedCustPPRBlocking1.2.12.6.2.patch
>
> Original Estimate: 8h
> Remaining Estimate: 8h
>
> n IE the blocking is initiated on the very first click that happens after a ppr request is sent to server. This is done via "onclick" attachEvent handler(_pprConsumeFirstClick) on the document. The problem is that attachEvent is invoked only in the bubble phase. In IE7/IE8 there is no way to set up an event handler at the capture phase. In this case the AJAX requests are initiated by the "onclick" event handler on the link. Since the click event listener is at target phase, it is always invoked first. So here is what happens when the user clicks on the Next link 2 times:
> 1) AJAX Request initiated on "onclick" handler
> 2) Set up the "onclick" attachEvent on the document (_pprConsumeFirstClick)
> 3) User clicks on link again
> 4) Since there is already an "onclick" handler, another AJAX request is queued.
> 5) the _pprConsumeFirstClick "onclick" document handler kicks in, which setups event capture. It is now too late.
> We believe because of TRINIDAD-952 we do not need to start blocking after the second click. We can start immediately since we are letting the first event pass through because of a timeout:
> if (_agent.isIE)
> {
> // see TRINIDAD-952 - IE does not update the activeElement in time before
> // blocking starts. Use a timeout to allow the update.
> win._pprTimeoutFunc = win.setTimeout("_doPprStartBlocking(window);",
> 1);
> return;
> }
> The second part of the fix is to restore the scroll location after we set focus on the blocking div.
--
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
[jira] [Updated] (TRINIDAD-2194) Trinidad PPR blocking does not
work with 2 clicks that post
Posted by "Venkata Guddanti (Updated) (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TRINIDAD-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Venkata Guddanti updated TRINIDAD-2194:
---------------------------------------
Status: Patch Available (was: Reopened)
> Trinidad PPR blocking does not work with 2 clicks that post
> -----------------------------------------------------------
>
> Key: TRINIDAD-2194
> URL: https://issues.apache.org/jira/browse/TRINIDAD-2194
> Project: MyFaces Trinidad
> Issue Type: Bug
> Components: Infrastructure
> Reporter: Venkata Guddanti
> Assignee: Blake Sullivan
> Fix For: 2.0.0-core
>
> Attachments: escalatedCustPPRBlocking.patch, escalatedCustPPRBlocking1.2.12.3.patch, escalatedCustPPRBlocking1.2.12.6.2.patch
>
> Original Estimate: 8h
> Remaining Estimate: 8h
>
> n IE the blocking is initiated on the very first click that happens after a ppr request is sent to server. This is done via "onclick" attachEvent handler(_pprConsumeFirstClick) on the document. The problem is that attachEvent is invoked only in the bubble phase. In IE7/IE8 there is no way to set up an event handler at the capture phase. In this case the AJAX requests are initiated by the "onclick" event handler on the link. Since the click event listener is at target phase, it is always invoked first. So here is what happens when the user clicks on the Next link 2 times:
> 1) AJAX Request initiated on "onclick" handler
> 2) Set up the "onclick" attachEvent on the document (_pprConsumeFirstClick)
> 3) User clicks on link again
> 4) Since there is already an "onclick" handler, another AJAX request is queued.
> 5) the _pprConsumeFirstClick "onclick" document handler kicks in, which setups event capture. It is now too late.
> We believe because of TRINIDAD-952 we do not need to start blocking after the second click. We can start immediately since we are letting the first event pass through because of a timeout:
> if (_agent.isIE)
> {
> // see TRINIDAD-952 - IE does not update the activeElement in time before
> // blocking starts. Use a timeout to allow the update.
> win._pprTimeoutFunc = win.setTimeout("_doPprStartBlocking(window);",
> 1);
> return;
> }
> The second part of the fix is to restore the scroll location after we set focus on the blocking div.
--
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