ICEfaces
  1. ICEfaces
  2. ICE-6697

ACE fileEntry with IE9 when upload is first postback in session

          Details

          • Type: Bug Bug
          • Status: Closed
          • Priority: Major Major
          • Resolution: Won't Fix
          • Affects Version/s: 2.0.1
          • Fix Version/s: 3.2
          • Component/s: ACE-Components
          • Labels:
            None
          • Environment:
            ACE fileEntry, ace-showcase, IE9
          • Assignee Priority:
            P3

            Description

            When a JSF page is first rendered, it doesn't know if the browser has cookies enabled, for storing the session id, so it renders the jsessionid into every single link in the page. Then, after the first postback, it detects that cookies are enabled, and stops rendering the jsessionid into every link, and our dom diff sees that lots of the page have changed, and sends all the changes to the browser. Usually that doesn't cause any problems.

            http://localhost:8080/ace-showcase/fileEntry.jsf

            But, in IE9, if the very first page you bring up has an ACE fileEntry in it, and the very first postback is from uploading a file, then the custom fileEntry ajax technique does not succeed in applying the dom updates to the page. And upload after that, will update the page. There is no problem in Firefox, WebKit, or older versions of IE.

              Activity

              Descending order - Click to sort in ascending order
              Hide
              Permalink
              John Hellier added a comment -

              Mark,

              Looked at ICE-8388. We came up with an alternative solution. We are using Weblogic and we put the following in weblogic.xml

              <wls:session-descriptor>
              <wls:cookie-name>AISSessionID</wls:cookie-name>
              <wls:url-rewriting-enabled>false</wls:url-rewriting-enabled>
              </wls:session-descriptor>

              AIS is the name of our app. This solved the problem with the jsessionId issue. Now the jsessionid is not being appended the first time through. The dialogs now work properly as do any components that are activated first on the first rendered page. All our session interactions appear to be stable and complete. We are using a mixture of Application, Window and Request scopes throughout. We are using Tuckey for custom rewriting and there is no overlap with the above.

              So far so good. Thank you for your responses. Definitely appreciated!

              Show
              John Hellier added a comment - Mark, Looked at ICE-8388 . We came up with an alternative solution. We are using Weblogic and we put the following in weblogic.xml <wls:session-descriptor> <wls:cookie-name>AISSessionID</wls:cookie-name> <wls:url-rewriting-enabled>false</wls:url-rewriting-enabled> </wls:session-descriptor> AIS is the name of our app. This solved the problem with the jsessionId issue. Now the jsessionid is not being appended the first time through. The dialogs now work properly as do any components that are activated first on the first rendered page. All our session interactions appear to be stable and complete. We are using a mixture of Application, Window and Request scopes throughout. We are using Tuckey for custom rewriting and there is no overlap with the above. So far so good. Thank you for your responses. Definitely appreciated!
              Hide
              Permalink
              Mark Collette added a comment -

              Please look at ICE-8388, where this issue is discussed some more. I'm thinking that a filter that does a temporary redirect back to the same url might solve this. Care must be taken to not infinitely redirect, especially when cookies are in fact disabled.

              Show
              Mark Collette added a comment - Please look at ICE-8388 , where this issue is discussed some more. I'm thinking that a filter that does a temporary redirect back to the same url might solve this. Care must be taken to not infinitely redirect, especially when cookies are in fact disabled.
              Hide
              Permalink
              John Hellier added a comment -

              Thanks for you response.

              I tried the commandButton. It fails if I don't put a type="button" attribute. If I do have the type="button attribute it stays open but then we have a set of radio buttons in the dialog that dynamically change the content in the dialog. After clicking on any one of the radio buttons, a post is made with the jsesssionid, the dialog disappears and we are back to the same problem. I saw this behavior yesterday when I tried using a straight <a> tag to allow access to the dialog.

              The showcase works because the dialog that comes up is strictly client side. If you were to put any components in the dialog that required a post back while keeping the dialog open then I am pretty sure it would fail there too. Again all of this works find after we have reloaded the page. It is that pesky first load that messes it up. I have been down the path of urlrewriting but I don't think that is the problem or can fix it.

              This is a problem that is somewhat independent of any component. We have a URL to a help page that was failing because the jsessionid was appended to it. We changed the tag to an <a> tag and it works. There needs to be a way to capture that first request from the page and filter out the jsessionid if it is going to be a problem. How to determine if it is going to be a problem is unclear to me.

              I can replicate this in Chrome but it is important to have a new instance of the browser running each time.

              Were there changes in the codebase that addressed this? We are using 3.1 pulled down in July.

              Thanks

              Show
              John Hellier added a comment - Thanks for you response. I tried the commandButton. It fails if I don't put a type="button" attribute. If I do have the type="button attribute it stays open but then we have a set of radio buttons in the dialog that dynamically change the content in the dialog. After clicking on any one of the radio buttons, a post is made with the jsesssionid, the dialog disappears and we are back to the same problem. I saw this behavior yesterday when I tried using a straight <a> tag to allow access to the dialog. The showcase works because the dialog that comes up is strictly client side. If you were to put any components in the dialog that required a post back while keeping the dialog open then I am pretty sure it would fail there too. Again all of this works find after we have reloaded the page. It is that pesky first load that messes it up. I have been down the path of urlrewriting but I don't think that is the problem or can fix it. This is a problem that is somewhat independent of any component. We have a URL to a help page that was failing because the jsessionid was appended to it. We changed the tag to an <a> tag and it works. There needs to be a way to capture that first request from the page and filter out the jsessionid if it is going to be a problem. How to determine if it is going to be a problem is unclear to me. I can replicate this in Chrome but it is important to have a new instance of the browser running each time. Were there changes in the codebase that addressed this? We are using 3.1 pulled down in July. Thanks
              Hide
              Permalink
              Mark Collette added a comment -

              That is, I tested using the ace:dialog sample in showcase.

              Show
              Mark Collette added a comment - That is, I tested using the ace:dialog sample in showcase.
              Hide
              Permalink
              Mark Collette added a comment -

              Using trunk ICEfaces, and running the showcase, which uses an h:commandButton, I can't reproduce this in Chrome. Can you please try with either an h:commandButton or with the most recent HEAD of trunk to see if this problem still exists in you app?

              http://anonsvn.icesoft.org/repo/icefaces3/trunk/icefaces/

              Show
              Mark Collette added a comment - Using trunk ICEfaces, and running the showcase, which uses an h:commandButton, I can't reproduce this in Chrome. Can you please try with either an h:commandButton or with the most recent HEAD of trunk to see if this problem still exists in you app? http://anonsvn.icesoft.org/repo/icefaces3/trunk/icefaces/
              5 older comments

                People

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

                  Dates

                  • Created:
                    Updated:
                    Resolved: