Internet explorer and trac problem

[gandaflux@…]

There is little glitch with internet explorer from version 0.12.3+ All links on page are 'normal' for example: /changeset/596 but after click on it and loading in IE on end shows # and links looks: /changeset/596#

Now problem: User must click 2 times back button to real back to page where he been. Because from 596# click on back button move to 596 (without #) then user must click another time Back to prevoius page. Problem exists only in Internet Explorer, other browsers works fine.

Tested with IE 9.0 x64

[Remy Blank]

This is a side-effect of [10851] that I had also noticed in #10382, but unfortunately the alternative (a reload being triggered when clicking a hash link after a redirect) is even worse.

So, unless someone finds a fix for #10382 that doesn't have this drawback, it's a "wontfix".

[Jun Omae]

Replying to rblank:

This is a side-effect of [10851] that I had also noticed in #10382, but unfortunately the alternative (a reload being triggered when clicking a hash link after a redirect) is even worse.

So, unless someone finds a fix for #10382 that doesn't have this drawback, it's a "wontfix".

Changing hash when location.hash only is not empty, the workaround works and has the drawback when only no hash. I confirmed with IE6, IE7 and IE9. However, I couldn't reproduce the original issue, #10382, with IE8 on my environment (Windows XP sp3).

trac/templates/layout.html

@@ -12 +12 @@
     </title>
     <meta py:if="chrome.content_type == 'text/html'" http-equiv="Content-Type" content="text/html; charset=UTF-8" />
     <meta py:for="meta in chrome.metas" py:attrs="meta"/>
-    <!--[if IE]><script type="text/javascript">window.location.hash = window.location.hash;</script><![endif]-->
+    <!--[if IE]><script type="text/javascript">
+      if (window.location.hash)
+        window.location.hash = window.location.hash;
+    </script><![endif]-->
     <py:if test="chrome.links">
       <py:for each="rel, links in chrome.links.items()">
         <link rel="${rel}" py:for="link in links" py:attrs="link" />

[Remy Blank]

Reported again in #10608. Reopening to try Jun's suggestion.

[Jun Omae]

My suggestion on comment:2 still needs two back buttons to back when location.hash isn't empty.

I just found the another workaround for #10382 using location.replace(). It doesn't need two back-button to back and works fine for me on IE 6-9.

trac/templates/layout.html

@@ -12 +12 @@
     </title>
     <meta py:if="chrome.content_type == 'text/html'" http-equiv="Content-Type" content="text/html; charset=UTF-8" />
     <meta py:for="meta in chrome.metas" py:attrs="meta"/>
-    <!--[if IE]><script type="text/javascript">window.location.hash = window.location.hash;</script><![endif]-->
+    <!--[if IE]><script type="text/javascript">
+      if (window.location.hash)
+        window.location.replace(window.location);
+    </script><![endif]-->
     <py:if test="chrome.links">
       <py:for each="rel, links in chrome.links.items()">
         <link rel="${rel}" py:for="link in links" py:attrs="link" />

Thoughts?

[Christian Boos]

Looks good! I'll test the proposed fix.

[Christian Boos]

Seems to work great, with no regression on #10382. Tested with IE9 and IE7.

Note that if we had a way to detect we're currently being redirected, we could also add this condition to the check, but I didn't find a way.

[Jun Omae]

3rd proposal

[Jun Omae]

Replying to cboos:

Note that if we had a way to detect we're currently being redirected, we could also add this condition to the check, but I didn't find a way.

Thanks for your confirmation.

The detection is possible on server side. My 3rd proposal is t10590-msie-303-replace-r11014.diff​ tested with IE6-9.

In Request.redirect(), when user-agent is MSIE and new redirecting URL has hash, append #__msie303: to the URL (e.g. http://localhost/ticket/42#__msie303:comment:7).

In browser side, if location.hash has #__msie303:, call location.replace() with the real hash.

[Christian Boos]

Great! I think it's a good thing to be able to see in the code the two ends of the problem, the root cause (a redirect sent to an IE browser on the server) and its workaround (the IE js trick in the client).

Tested and verified the location replacement only happens after a redirect.

[Jun Omae]

Thanks. The patch has been committed in [11016].

[Remy Blank]

It's been some time since I last looked at this, so excuse me if I'm missing something, but why is the patch from comment:4 not good enough? Is it because it forces a reload of the page on IE when a hash is present regardless of whether it's actually necessary to reload (i.e. only after a redirect)?

[Christian Boos]

I wrongly assumed that a page reload would be triggered whenever the window.location would be reset, but that reload apparently only happens after redirect, so the check seems indeed to be redundant unless I'm again missing something ;-)

(if we simplify this like in comment:4, can we at least the comment from r11016 and put it in layout.html?)