IE (internext explorer) on Windows (perhaps only Vista, perhaps not) unable to load CoreGUI. The RHQ logo will pop up, left adjusted, and will continue to spin, the app never loads. I have seen on occasion the app load, wit IE8, after 7-9 minutes. But that is basically equivalent to not loading. The app should load, with a local or fast connection, in seconds. On my slow laptop running locally the app loads under 3 seconds on FF or Chrome.
After many failures I think I've nailed down the core problem. Relevant IRC chat: (1:59:21 PM) jshaughn: ips, so, we don't declare a DOCTYPE as far as I know. And this, I think, is actually the recommendation from Smartgwt. (2:00:47 PM) jshaughn: When IE, at least on Vista, maybe on other flavors as well, can not determine a valid DOCTYPE in remains in IE's "Quirks mode", which is basically IE's legacy non-standards mode. (2:01:23 PM) jshaughn: This was barfing on load in some way, perhaps related to gwts standard.css, I'm not sure. (2:02:24 PM) jshaughn: But, force IE into "standards mode", (basically making it more like a normal browser ; ) and voila, fast load and everything starts looking pretty normal. (2:03:41 PM) jshaughn: not to mention the fact that the RHQ logo actually gets centered :) (2:04:33 PM) jshaughn: if you see the logo left-adjusted you're basically in quirks mode, or using an IE version that does not support standards mode. (I think it was introduced in IE8) (2:12:56 PM) ips: so sounds like we def should add a doctype. we don't want to have to require users to switch the default browser mode (2:13:17 PM) ips: people who don't read the relnotes will miss it anyway (2:13:51 PM) jshaughn: We probably should. But what DOCTYPE I'm not sure, I thought I read in the smartgwt forums that they recommend not setting a DOCTYPE. (2:14:09 PM) jshaughn: We'll have to research. (2:14:19 PM) ips: we should add a note to the 4.0 relnotes though to tell Ie users how to change the mode (2:14:23 PM) jshaughn: also, I have not tried that yet. I've only tried forcing the browser setting.
Related: We should probably remove gwt's standard.css from our load: 1) it seemed like a trouble spot during initial load for certain IE configurations 2) we probably don't want to be defaulting to GWT standards as opposed to SmartGWT.
This link recommends the removal of standard.css, although the removal does not solve this issue: http://forums.smartclient.com/showthread.php?t=8159#aVisual Although smartgwt seems to recommend not applying a DOCTYPE, we are seeing better behavior, both the ability to load the app fast (because IE goes into standards mode) and rendering (more consistent with other browsers). So, the plan is to add this to CoreGUI.html: <!doctype html> This is a DOCTYPE used by google, and it seems sufficient to get the desired behavior.
As an aside, in IE8+ you can force the browser mode via the console provided when hitting F12. This is a nice way to try various combos of IE version (simulated via compatibility mode) and browser mode (quirks vs standards)
I turned off quirks mode and on my Vista/IE8 setup, this now works (where before, while in quirks mode, it did not work)
Adding a few more datapoints: With the doctype set the app does not load for me in IE8. That's using Windows 7, IE 8.0.7600.16385. Remove doctype and the app loads. With XP and IE7 7.0.5730.13 the app loads fine with and without the !doctype. Flipping back to ON_DEV to get more feedback on these new results.
It sounds like the guys on this thread may have been hitting the same issue: http://www.mail-archive.com/google-web-toolkit@googlegroups.com/msg22639.html Unfortunately, they never posted a resolution...
Another blurb I found on the Web related to my previous comment: When you're dealing with heavy AJAX environments, things can get complex. The window.onload event handler only fires when the document.readyState = "complete", which doesn't always happen if there are long downloads pending. You may want to change the event to window.onreadystatechange and check for the "interactive" state. That may be better for you, but know that the event will likely fire well before the document is fully complete. Another thing to consider is that, in a multi-frame environment, you have to ensure that the onload handler is attached to the correct frame's window. If child windows are created/destroyed, you can lose the event handler. I've also encountered one situation where the onload event handler spontaneously disappears (yet if you attach it to window.self, it remains). This is very rare, but I'd recommend monitoring your event handler and see if it's still registered. You may want to try attaching to window.self.onload and see if that helps. I've reported the issue to MS and am waiting to hear back. I'll post whatever I find. In the meantime, if anyone knows why window and window.self would be different, I'd be more than happy to hear about it.
Another thread regarding the same issue with some possible causes: http://groups.google.com/group/google-web-toolkit/browse_thread/thread/a322747b293de102
master commit be6c71ed2e27124addb6abb68526b66834dbaae1 release-4.0.0 commit b27171174d8671c0484a48d39de65aaf5cf7a89e Revert the use of DOCTYPE as "standards" mode causes various issues in several browsers. This is basically due to the fact that SmartGWT codes for browser's native "quirks" behavior. As such SmartGWT is more predictable when avoiding "standards" modes. But we still had a need to direct IE in some way to give us the behavior we want. Todo this we add the <meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" > directive to our initializing html (CoreGUI.html). This instructs IE to emulate IE7 quirks mode. In effect, this means that if our code looks good with IE7 it should continue to work well even if users upgrade to IE8, IE9, etc... It also seems to provide enough guidance to IE to get perform the proper loading, assuming we build the "ie6" gwt.userAgent. And it gets around a SmartGWT tree rendering issue with IE8 modes. Since this is ignored by non-IE browsers they will continue to run in their own quirks mode, thus avoiding issues like BZ 703515, which is a regression brought about by the original DOCTYPE approach. TEST NOTES: This should be tested against as many Windows/IE combos as possible. In particular, at least one Vista/XP and one Win7 env. Also, IE7 and IE8. Check for the ability to load the app in a reasonable amount of time. Also, once loaded ensure the resource tree looks well-formed.
logged bz 70449 while verifying this. https://bugzilla.redhat.com/show_bug.cgi?id=704499
logged bz 704354 while verifying this. https://bugzilla.redhat.com/show_bug.cgi?id=704354
the fix has introduced multiple regressions on IE: 704499 704354 the specific behavior of unable to load coregui does appear fixed.
Created attachment 498817 [details] tabs-ie7.jpg the tab labels look too far down in IE7. tested with the release-4.0.0 branch see attachment
except for the Summary tab, where the label looks too high...
changing to on-dev because of the new issues with tab labels.
Moving the Tab label positioning to a new BZ. https://bugzilla.redhat.com/show_bug.cgi?id=705038 The original issue is verified.
Bulk closing of issues that were VERIFIED, had no target release and where the status changed more than a year ago.