We also encountered this problem with GWT 2.4. To complete previous messages, we also noticed that it depends on the calling context. But when the calling context is an event handler, all browsers don't have the same behavior (we have the expected behavior on all browsers but IE any version).
It sounds like the problem comes from the fact that GWT code is in an iframe and relative path resolution is done using the calling context whereas we could expect GWT to resolve it in the main window context since the fact that code is in a iframe is hidden to user. Here is a GWT code snippet that shows the problem: public class IERedirectBug implements EntryPoint { @Override public void onModuleLoad() { final Button redirectButton = new Button("Relative Redirection"); RootPanel.get().add(redirectButton); redirectButton.addClickHandler(new ClickHandler() { @Override public void onClick(ClickEvent event) { // Works with all browsers but IE Location.assign("target.html"); } }); } } To investigate the problem we did several test cases in pure Javascript. In the first case, we use a frame that is in a subfolder and that contains a function (as the GWT frame contains code) that does the main page redirection (window.parent.location.assign()). If we call this code from the main window (case #1), all browsers resolve correctly relative paths. If this code is called from the iframe (next to the function declaration, case #2), all browsers resolve the relative path according to the iframe location and not the main page location. This shows that calling context impacts relative path resolution and all browsers seem to have the same behavior (at least Google Chrome and IE 8 & 9 on which we really tested). Main window (test.html): <!DOCTYPE html> <html> <head></head> <body> <iframe src="folder/frame.html" id="frame"> </iframe> <h1>main</h1> <button>redirect</button> </body> </html> Iframe (folder/frame.html): <!DOCTYPE html> <html> <head> </head> <body> <h1>test2</h1> <script type="text/javascript"> function redirect() { window.parent.location.assign('target.html'); } </script> </body> </html> In case #1, we add to the button declaration in test.html the call to the redirect function: <button onclick="document.getElementById('frame').contentWindow.redirect()">redirect</button>. This redirects to target.html on any browser, the expected behavior. In case #2, we call the redirect function from the frame, just after its declaration: function redirect() { window.parent.location.assign('target.html'); } redirect(); It redirects to folder/target.html on any browser. These examples simply confirm that calling context impacts relative path resolution but don't explain why IE hasn't the same behavior as other browsers in our GWT case. So we tried to reproduce in a pure Javascript example the way GWT handles events (through the global handler), case #3. This way enabled us to reproduce the problem. For modern browsers and IE9, the standard global event handling system is used throw $wnd.addEventListener(). For IE 8 it's a specific code (case #4). But whatever global event handling system is used, Location.replace() and Location.assign() don't have the expected behaviour with relative paths on IE. In case #3, we use this code (just after redirect function declaration): // Works on any browser but IE9 window.parent.addEventListener('click', function(e) { redirect(); }, true); In case #4 (IE8), we use this code: window.parent.document.body.attachEvent('onclick', function(e) { redirect(); }); Cases #3 and #4 show that with global handler, IE has the same behavior as case #2 while other browsers work as in case #1, which is the expected behavior. Even if the problem can be solved by API users using GWT.getModuleBaseURL(), don't you think it sould be fixed in GWT itself since it doesn't respect the GWT "execution doesn't depend on browser" principle? I guess it could be solved by analyzing the parameter given to the assign() method. If it starts neither with a protocol (http:// for instance) nor with a slash, we can consider it's a relative path (unless I forget cases) and thus prefix it with GWT.getModuleBaseUrl(). Le mercredi 16 juillet 2008 23:47:25 UTC+2, Thomas Broyer a écrit : > > > > On Jul 16, 8:57 pm, jarrod <jarrod.carl...@gmail.com> wrote: > > This is even stranger. Observe the following EntryPoint code: > > > > public void onModuleLoad() { > > RootPanel.get().add(new Button("Redirect", new ClickListener() > > { > > public void onClick(Widget sender) { > > Window.Location.assign("index.html"); > > } > > })); > > RootPanel.get("root").add(root); > > } > > > > Click the button, and you get successfully redirected from "/context/ > > module.html" to "/context/index.html", just like you would expect. > > The onClick method is called in response to the button's click, and > the button lies in the /context/moduleA.html, so this URL is used as > the "base URL" for resolving relative URLs. > > > However, given this code (never mind the redirect in module load, it's > > just to illustrate a point): > > > > public void onModuleLoad() { > > Window.Location.assign("index.html"); > > } > > > > You are incorrectly redirected from "/context/module.html" to "/ > > context/com.domain.my.Module/index.html" > > > > So what's going on? > > onModuleLoad is called by the *.cache.html page, which in your case > lies in /context/com.domain.my.Module, which is thus used as the base > URL, hence the result. > > In a few words: the "calling context" is used to retrieve a base URL. > > To cater for these cases, GWT has GWT.getHostPageBaseURL() and > GWT.getModuleBaseURL() methods, that you prepend to your relative URL. -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/Qfkf1fdq_4UJ. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.