ICEfaces
  1. ICEfaces
  2. ICE-9985

blockUiOnSubmit - Blocker overlay is removed upon redirect

          Details

          • Type: Bug Bug
          • Status: Closed
          • Priority: Major Major
          • Resolution: Fixed
          • Affects Version/s: EE-3.3.0.GA_P01
          • Fix Version/s: EE-3.3.0.GA_P02, 4.0
          • Component/s: Bridge
          • Labels:
            None
          • Environment:
            All

            Description

            In this scenario a redirect is executed on click of a button. There is a delay in the getting the response which contains the new page that is being redirected to. The redirect is causing the ui-blocker overlay to be removed which leaves the underlying page exposed to clicks and interaction until the update is returned.

              Activity

              Ascending order - Click to sort in descending order
              Arran Mccullough created issue -
              Hide
              Permalink
              Arran Mccullough added a comment -

              Attached test case that shows this issue. The icefaces, icefaces-ace, icefaces-compat jar files need to be added into the war to run.

              Steps:

              • Load page1.jsf (I recommend opening the browser console to see the issue better).
              • Click on the Continue button.
              • In the console it will show the ui-blocker displayed, then it is hidden. After a few seconds page2 content is shown.
              Show
              Arran Mccullough added a comment - Attached test case that shows this issue. The icefaces, icefaces-ace, icefaces-compat jar files need to be added into the war to run. Steps: Load page1.jsf (I recommend opening the browser console to see the issue better). Click on the Continue button. In the console it will show the ui-blocker displayed, then it is hidden. After a few seconds page2 content is shown.
              Arran Mccullough made changes -
              Field Original Value New Value
              Attachment Case12789Example.war [ 17105 ]
              Attachment Case12789Example.zip [ 17106 ]
              Hide
              Permalink
              Arran Mccullough added a comment -

              It's likely the cause of this change are from ICE-9323.

              Show
              Arran Mccullough added a comment - It's likely the cause of this change are from ICE-9323 .
              Hide
              Permalink
              Carlo Guglielmin added a comment - - edited

              There was a change in the aforementioned ICE-9323 so that the UI blocker is hidden "onBeforeUpdate", whereas previously it was "onAfterUpdate".

              This has an unintended consequence in the case of a Redirect to a slow page. As in a faces-config navigation rule that has <redirect/>, or a commandButton action with "?faces-redirect=true" as part of the returned string.

              Going from the code sample, if the user clicks "Continue" they POST to the server. But the response from that POST is content that simply says "redirect to page 2". But since the POST is completed the "onBeforeUpdate" will fire, closing the UI blocker.

              Then the browser will do a GET of page 2, with the UI unblocked at this point. Normally on fast pages and requests this isn't a problem.

              However if page 2 is extremely slow to load (such as a lot of work done on initialization or getters), such as the GET taking 10 seconds, that means the user can interact with page 1 (unblocked) for those 10 seconds.

              Reverting the change (at the end of icefaces/core/src/main/javascript/blockui.js) to "onAfterUpdate" fixes this issue, but may potentially introduce the old issue with panelPopup that ICE-9323 was meant to fix.

              Show
              Carlo Guglielmin added a comment - - edited There was a change in the aforementioned ICE-9323 so that the UI blocker is hidden "onBeforeUpdate", whereas previously it was "onAfterUpdate". This has an unintended consequence in the case of a Redirect to a slow page. As in a faces-config navigation rule that has <redirect/>, or a commandButton action with "?faces-redirect=true" as part of the returned string. Going from the code sample, if the user clicks "Continue" they POST to the server. But the response from that POST is content that simply says "redirect to page 2". But since the POST is completed the "onBeforeUpdate" will fire, closing the UI blocker. Then the browser will do a GET of page 2, with the UI unblocked at this point. Normally on fast pages and requests this isn't a problem. However if page 2 is extremely slow to load (such as a lot of work done on initialization or getters), such as the GET taking 10 seconds, that means the user can interact with page 1 (unblocked) for those 10 seconds. Reverting the change (at the end of icefaces/core/src/main/javascript/blockui.js) to "onAfterUpdate" fixes this issue, but may potentially introduce the old issue with panelPopup that ICE-9323 was meant to fix.
              Hide
              Permalink
              Ken Fyten added a comment -

              Might need to make this configurable as to whether the onbeforeupdate vs onafterupdate is used, with onafterupdate being the default?

              Show
              Ken Fyten added a comment - Might need to make this configurable as to whether the onbeforeupdate vs onafterupdate is used, with onafterupdate being the default?
              Ken Fyten made changes -
              Assignee Mircea Toma [ mircea.toma ]
              Fix Version/s EE-3.3.0.GA_P02 [ 11371 ]
              Fix Version/s 4.0 [ 11382 ]
              Assignee Priority P1 [ 10010 ]
              Repository Revision Date User Message
              ICEsoft Public SVN Repository #40902 Wed Apr 30 18:16:04 MDT 2014 mircea.toma ICE-9985 Start blocking the UI when "beforeUnload" event is triggered, which can be caused by page navigation or reload.
              Files Changed
              Commit graph MODIFY /icefaces4/trunk/icefaces/core/src/main/javascript/application.js
              Commit graph MODIFY /icefaces4/trunk/icefaces/core/src/main/javascript/blockui.js
              Hide
              Permalink
              Mircea Toma added a comment -

              The blocking of the UI seems to work as expected. The UI unblocking occurs after the redirect command is received by the JSF bridge, only after that the request for the next page is issued by the browser (not the bridge). Since the (GET) request is issued by the browser itself the callbacks that block UI registered with bridge are not invoked.

              Show
              Mircea Toma added a comment - The blocking of the UI seems to work as expected. The UI unblocking occurs after the redirect command is received by the JSF bridge, only after that the request for the next page is issued by the browser (not the bridge). Since the (GET) request is issued by the browser itself the callbacks that block UI registered with bridge are not invoked.
              Hide
              Permalink
              Mircea Toma added a comment -

              Modified the bridge to also start the blocking of the UI when "beforeUnload" event is triggered, which can be caused by page navigation or reload.

              Show
              Mircea Toma added a comment - Modified the bridge to also start the blocking of the UI when "beforeUnload" event is triggered, which can be caused by page navigation or reload.
              Mircea Toma made changes -
              Status Open [ 1 ] Resolved [ 5 ]
              Resolution Fixed [ 1 ]
              Hide
              Permalink
              Liana Munroe added a comment -

              Verified functioning as expected Icefaces ee-3.3.0 maintenance branch r40997, Tomcat 7, all browsers.

              Show
              Liana Munroe added a comment - Verified functioning as expected Icefaces ee-3.3.0 maintenance branch r40997, Tomcat 7, all browsers.
              Ken Fyten made changes -
              Status Resolved [ 5 ] Closed [ 6 ]

                People

                • Assignee:
                  Mircea Toma
                  Reporter:
                  Arran Mccullough
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  5 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: