Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 2.0-Beta2
-
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
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
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
This maybe relevant: http://jira.portletfaces.org/browse/BRIDGE-238
Show
Keith Garry Boyce
added a comment - This maybe relevant: http://jira.portletfaces.org/browse/BRIDGE-238
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