ICEfaces
  1. ICEfaces
  2. ICE-6893

Disabling history iframe causes endless content loading status on some browsers

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.8.2-EE-GA_P02
    • Fix Version/s: EE-1.8.2.GA_P03
    • Component/s: Framework
    • Labels:
      None
    • Environment:
      ICEfaces 1, FF, IE

      Description

      When using the following context parameter:

       <context-param>
          <param-name>com.icesoft.faces.disableBrowserHistoryTracking</param-name>
          <param-value>true</param-value>
      </context-param>

      when the initial page is loaded, FF and IE will both display that content is loading even after all content has been received.

        Activity

        Hide
        Deryk Sinotte added a comment -

        When the context parameter is set, there is logging in the Firebug console to indicate the request for the browser history iframe src has been disabled:

        [window.synchronizer] Browser history tracking is disabled.

        and the history iframe markup looks like this:

        <iframe frameborder="0"
        title="Icefaces Redirect"
        style="z-index: 10000; visibility: hidden; width: 0; height: 0; position: absolute; opacity: 0.22; filter: alpha(opacity=22);"
        src="javascript:document.write('<html></html>');"
        name="history-frame:w-tba787KQtAv_zB9l9y8g:1"
        id="history-frame:w-tba787KQtAv_zB9l9y8g:1">
        </iframe>

        So the "src" attribute attempts to write an empty HTML page rather than make a request to the server. By setting disableBrowserHistory=false, the iframe markup looks like this:

        <iframe frameborder="0"
        title="Icefaces Redirect"
        style="z-index: 10000; visibility: hidden; width: 0; height: 0; position: absolute; opacity: 0.22; filter: alpha(opacity=22);"
        src="/DummyIcefacesWar/xmlhttp/blank"
        name="history-frame:Qb4FdTBzmfnjWd5CIJYicQ:1"
        id="history-frame:Qb4FdTBzmfnjWd5CIJYicQ:1">
        </iframe>

        This is the default behaviour and a request will be sent to the server to retrieve a blank document that looks something like this:

        <html>
        <head>
        </head>
        <body>
        </body>
        </html>

        So when it's disabled and we use the javascript: URL method to write out some content, on Firefox and IE, the page gives the impression that the content doesn't fully load - the tab shows the content loading animation and the status bar (in Firefox, anyway) shows "Transerring data from localhost...". And this continues to display forever.

        Chrome and Safari do not show this behaviour. There does not appear to be an open connection in this case but the browsers are simply in a state where the status indicators for incoming data are set incorrectly and are never properly set back. Perhaps there is something not being executed (like the iframe.onload) which would lead to some of the browsers thinking that the documented had not completed loading yet.

        Show
        Deryk Sinotte added a comment - When the context parameter is set, there is logging in the Firebug console to indicate the request for the browser history iframe src has been disabled: [window.synchronizer] Browser history tracking is disabled. and the history iframe markup looks like this: <iframe frameborder="0" title="Icefaces Redirect" style="z-index: 10000; visibility: hidden; width: 0; height: 0; position: absolute; opacity: 0.22; filter: alpha(opacity=22);" src="javascript:document.write('<html></html>');" name="history-frame:w-tba787KQtAv_zB9l9y8g:1" id="history-frame:w-tba787KQtAv_zB9l9y8g:1"> </iframe> So the "src" attribute attempts to write an empty HTML page rather than make a request to the server. By setting disableBrowserHistory=false, the iframe markup looks like this: <iframe frameborder="0" title="Icefaces Redirect" style="z-index: 10000; visibility: hidden; width: 0; height: 0; position: absolute; opacity: 0.22; filter: alpha(opacity=22);" src="/DummyIcefacesWar/xmlhttp/blank" name="history-frame:Qb4FdTBzmfnjWd5CIJYicQ:1" id="history-frame:Qb4FdTBzmfnjWd5CIJYicQ:1"> </iframe> This is the default behaviour and a request will be sent to the server to retrieve a blank document that looks something like this: <html> <head> </head> <body> </body> </html> So when it's disabled and we use the javascript: URL method to write out some content, on Firefox and IE, the page gives the impression that the content doesn't fully load - the tab shows the content loading animation and the status bar (in Firefox, anyway) shows "Transerring data from localhost...". And this continues to display forever. Chrome and Safari do not show this behaviour. There does not appear to be an open connection in this case but the browsers are simply in a state where the status indicators for incoming data are set incorrectly and are never properly set back. Perhaps there is something not being executed (like the iframe.onload) which would lead to some of the browsers thinking that the documented had not completed loading yet.
        Hide
        Deryk Sinotte added a comment -

        In DOMResponseWriter.enhanceBody() method, changing the iframe src from;

        frameURI = "javascript:document.write('<html></html>');

        to

        frameURI = "javascript:;

        appears to solve this problem. Simply not writing anything to the document allows the browser status to stay in the correct state.

        Show
        Deryk Sinotte added a comment - In DOMResponseWriter.enhanceBody() method, changing the iframe src from; frameURI = "javascript:document.write('<html></html>'); to frameURI = "javascript:; appears to solve this problem. Simply not writing anything to the document allows the browser status to stay in the correct state.
        Hide
        Deryk Sinotte added a comment -

        Looks like having no content via:

        javascript:;

        causes IE 6 to complain about "secure and insecure" items on a page which we need to avoid. According to a blog that I found:

        http://wolfewebservices.com/blog/fancybox-ssl-security-warning-ie6-and-ie7

        the javascript: URL cannot be empty. Instead, they recommend the following, which seems to work:

        javascript:false;

        It's been tested by Arran running with IE via SSL. The content loading issues are gone and older versions of IE do not raise any security warnings.

        Show
        Deryk Sinotte added a comment - Looks like having no content via: javascript:; causes IE 6 to complain about "secure and insecure" items on a page which we need to avoid. According to a blog that I found: http://wolfewebservices.com/blog/fancybox-ssl-security-warning-ie6-and-ie7 the javascript: URL cannot be empty. Instead, they recommend the following, which seems to work: javascript:false; It's been tested by Arran running with IE via SSL. The content loading issues are gone and older versions of IE do not raise any security warnings.
        Hide
        Deryk Sinotte added a comment -

        Checked in revision #24631 to the icefaces/trunk.

        Show
        Deryk Sinotte added a comment - Checked in revision #24631 to the icefaces/trunk.

          People

          • Assignee:
            Deryk Sinotte
            Reporter:
            Deryk Sinotte
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: