Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 1.8.2
-
Fix Version/s: 1.8.2
-
Component/s: ICE-Components
-
Labels:None
-
Environment:ICEfaces trunk revision 19187
IE6 and IE7
Description
When exporting data, a save dialog shows up. On IE browsers, the file type cannot be determined at that point of time. If saving file to a different type as defined, the file will only contain funky data.
This affects component showcase sample application, too.
This affects component showcase sample application, too.
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
No can do. See screenshot-1 and screenshot-2.
withOptions() is called when the resource is served. By that time the FacesContext is already long gone. We need that to do browser detection. We need browser detection because content disposition file name is browser dependent. See ICE-4342 for more details.
I remember we discussed all this in a meeting. And Ted (or Mark?) suggested something to fix this in the future.
Show
yip.ng
added a comment - No can do. See screenshot-1 and screenshot-2.
withOptions() is called when the resource is served. By that time the FacesContext is already long gone. We need that to do browser detection. We need browser detection because content disposition file name is browser dependent. See ICE-4342 for more details.
I remember we discussed all this in a meeting. And Ted (or Mark?) suggested something to fix this in the future.
There is a MIME standard for the header that should help – but existing browsers are ignoring the standard. Was that the future fix?
Show
Ted Goddard
added a comment - There is a MIME standard for the header that should help – but existing browsers are ignoring the standard. Was that the future fix?
Fixed by not writing the content disposition at all when file name is missing in registered resource. See screenshot-3.
Fix confirmed on ICEfaces 1.8.2 build 1 (Tested on IE 6 and 7)
Show
Joanne Bai
added a comment - Fix confirmed on ICEfaces 1.8.2 build 1 (Tested on IE 6 and 7)
It works fine on 1.8.1 release. I reverted trunk back to revision 19076, and it worked fine too. But this issue existed when testing on revision 19114. So, it should be some revision in between 19076 and 19114 where it firstly occurred.