ICEfaces
  1. ICEfaces
  2. ICE-6171

FileEntry not updating page in WebKit browsers

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0-Beta2
    • Fix Version/s: 2.0-Beta2, 2.0.0
    • Component/s: Framework, ICE-Components
    • Labels:
      None
    • Environment:
      ace showcase fileEntry demo
      WebKit: Safari 4.0.3, Chrome 7.0.517.41.

      Description

      Open the fileEntry page in the ace showcase sample application. In Firefox, if you upload a file, the Messages and Uploaded Files will update. In a WebKit browser, the page won't update, but if you refresh the page, you'll then see that the upload was successful, since the bean is in session scope.

        Activity

        Repository Revision Date User Message
        ICEsoft Public SVN Repository #22947 Wed Oct 27 13:40:52 MDT 2010 mark.collette ICE-6171 : FileEntry not updating page in WebKit browsers
        Files Changed
        Commit graph MODIFY /icefaces2/trunk/icefaces/ace/component/resources/org.icefaces.component.fileentry/fileEntry.js
        Commit graph MODIFY /icefaces2/trunk/icefaces/core/src/main/java/org/icefaces/impl/application/WindowScopeManager.java
        Commit graph MODIFY /icefaces2/trunk/icefaces/ace/component/src/org/icefaces/component/fileentry/FileEntryPhaseListener.java
        Commit graph MODIFY /icefaces2/trunk/icefaces/ace/component/src/org/icefaces/component/fileentry/FileEntryLoader.java
        Repository Revision Date User Message
        ICEsoft Public SVN Repository #22957 Wed Oct 27 14:55:09 MDT 2010 mark.collette ICE-6171 : FileEntry not updating page in WebKit browsers
        Files Changed
        Commit graph MODIFY /icefaces2/trunk/icefaces/core/src/main/java/org/icefaces/impl/application/WindowScopeManager.java
        Commit graph MODIFY /icefaces2/trunk/icefaces/ace/component/src/org/icefaces/component/fileentry/FileEntryPhaseListener.java
        Commit graph MODIFY /icefaces2/trunk/icefaces/ace/component/src/org/icefaces/component/fileentry/FileEntryLoader.java
        Mark Collette created issue -
        Mark Collette made changes -
        Field Original Value New Value
        Salesforce Case []
        Fix Version/s 2.0-Beta2 [ 10242 ]
        Assignee Mark Collette [ mark.collette ]
        Hide
        Mark Collette added a comment -

        Investigation showed that the file was being uploaded, but the dom diff was causing the whole form to be updated. That in itself should be wrong, since only the Messages and Uploaded files sections should have been updated. Investigation of the application revealed no obvious fault. Inspection of the returned form markup showed that the ice.window hidden input field, which has no id and is immediately within the form, was getting a new value each time it came back from the server. This meant that window scope was being broken by the fileEntry. Investigation of the ice.window generation revealed that it ran in a PhaseListener in pre-RestoreView, which is the same phase that FileEntryPhaseListener runs, and converts the multi-part request into the format that JSF requires. If the WindowScopeManager ran before FileEntryPhaseListener, then it would break. Likely, any PhaseListener running before FileEntryPhaseListener would break. A search of all PhaseListeners indicated that only WindowScopeManager was affected. No generic way was found to ensure that FileEntryPhaseListener would execute first, so FileEntryPhaseListener was registered with WindowScopeManager, so it would be executed first. This worked, and solved the changing ice.window problem, and caused the form to not be updated.

        But, the WebKit browsers continued to not update. Investigation of that showed that the first issue could never have caused the WebKit problem. The iframe onload handler was being invoked, it just didn't recognise how to update the view with it. The Firefox and IE specific code did not cover the WebKit case. Once that support was invented and added, the updates worked properly.

        Subversion 22947

        Show
        Mark Collette added a comment - Investigation showed that the file was being uploaded, but the dom diff was causing the whole form to be updated. That in itself should be wrong, since only the Messages and Uploaded files sections should have been updated. Investigation of the application revealed no obvious fault. Inspection of the returned form markup showed that the ice.window hidden input field, which has no id and is immediately within the form, was getting a new value each time it came back from the server. This meant that window scope was being broken by the fileEntry. Investigation of the ice.window generation revealed that it ran in a PhaseListener in pre-RestoreView, which is the same phase that FileEntryPhaseListener runs, and converts the multi-part request into the format that JSF requires. If the WindowScopeManager ran before FileEntryPhaseListener, then it would break. Likely, any PhaseListener running before FileEntryPhaseListener would break. A search of all PhaseListeners indicated that only WindowScopeManager was affected. No generic way was found to ensure that FileEntryPhaseListener would execute first, so FileEntryPhaseListener was registered with WindowScopeManager, so it would be executed first. This worked, and solved the changing ice.window problem, and caused the form to not be updated. But, the WebKit browsers continued to not update. Investigation of that showed that the first issue could never have caused the WebKit problem. The iframe onload handler was being invoked, it just didn't recognise how to update the view with it. The Firefox and IE specific code did not cover the WebKit case. Once that support was invented and added, the updates worked properly. Subversion 22947
        Mark Collette made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Hide
        Mark Collette added a comment -

        Came up with a more generic solution to getting the FileEntryPhaseListener to execute first. The worry was that the solution was brittle, and only covered the case of WindowScopeManager, whereas third party libraries might exhibit a similar problem. The solution was to remove all other PhaseListener objects, add the FileEntryPhaseListener at the head of the list, and then re-add the other PhaseListener object after FileEntryPhaseListener, so that LifecycleImpl would execute them after. It relies on an implementation detail, but one that seems reasonable.

        Subversion 22957

        Show
        Mark Collette added a comment - Came up with a more generic solution to getting the FileEntryPhaseListener to execute first. The worry was that the solution was brittle, and only covered the case of WindowScopeManager, whereas third party libraries might exhibit a similar problem. The solution was to remove all other PhaseListener objects, add the FileEntryPhaseListener at the head of the list, and then re-add the other PhaseListener object after FileEntryPhaseListener, so that LifecycleImpl would execute them after. It relies on an implementation detail, but one that seems reasonable. Subversion 22957
        Ken Fyten made changes -
        Fix Version/s 2.0.0 [ 10230 ]
        Ken Fyten made changes -
        Status Resolved [ 5 ] Closed [ 6 ]
        Hide
        Keith Garry Boyce added a comment -
        Show
        Keith Garry Boyce added a comment - This maybe relevant: http://jira.portletfaces.org/browse/BRIDGE-238

          People

          • Assignee:
            Mark Collette
            Reporter:
            Mark Collette
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: