This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 703252 - IE (IE7, IE8) unable to load CoreGUI
IE (IE7, IE8) unable to load CoreGUI
Status: CLOSED CURRENTRELEASE
Product: RHQ Project
Classification: Other
Component: Core UI (Show other bugs)
4.0.0
All Windows
urgent Severity urgent (vote)
: ---
: ---
Assigned To: Jay Shaughnessy
Mike Foley
:
Depends On:
Blocks: 614447 rhq401
  Show dependency treegraph
 
Reported: 2011-05-09 14:13 EDT by Jay Shaughnessy
Modified: 2013-09-02 03:20 EDT (History)
4 users (show)

See Also:
Fixed In Version: 4.0.1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-09-02 03:20:46 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
tabs-ie7.jpg (12.60 KB, image/jpeg)
2011-05-13 12:50 EDT, John Mazzitelli
no flags Details

  None (edit)
Description Jay Shaughnessy 2011-05-09 14:13:08 EDT
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.
Comment 1 Jay Shaughnessy 2011-05-09 14:20:34 EDT
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.
Comment 2 Jay Shaughnessy 2011-05-09 14:21:35 EDT
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.
Comment 3 Jay Shaughnessy 2011-05-09 15:03:01 EDT
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.
Comment 4 Jay Shaughnessy 2011-05-09 15:06:01 EDT
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)
Comment 5 John Mazzitelli 2011-05-09 15:30:53 EDT
I turned off quirks mode and on my Vista/IE8 setup, this now works (where before, while in quirks mode, it did not work)
Comment 6 Simeon Pinder 2011-05-11 08:30:59 EDT
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.
Comment 7 Ian Springer 2011-05-11 16:49:18 EDT
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...
Comment 8 Ian Springer 2011-05-11 17:39:25 EDT
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.
Comment 9 Ian Springer 2011-05-11 22:26:57 EDT
Another thread regarding the same issue with some possible causes:

http://groups.google.com/group/google-web-toolkit/browse_thread/thread/a322747b293de102
Comment 10 Jay Shaughnessy 2011-05-12 14:23:32 EDT
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.
Comment 11 Mike Foley 2011-05-13 08:40:39 EDT
logged bz 70449 while verifying this.  https://bugzilla.redhat.com/show_bug.cgi?id=704499
Comment 12 Mike Foley 2011-05-13 08:42:23 EDT
logged bz 704354 while verifying this.

https://bugzilla.redhat.com/show_bug.cgi?id=704354
Comment 13 Mike Foley 2011-05-13 08:49:03 EDT
the fix has introduced multiple regressions on IE:
704499
704354

the specific behavior of unable to load coregui does appear fixed.
Comment 14 John Mazzitelli 2011-05-13 12:50:03 EDT
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
Comment 15 Ian Springer 2011-05-13 13:01:50 EDT
except for the Summary tab, where the label looks too high...
Comment 16 Mike Foley 2011-05-13 16:49:26 EDT
changing to on-dev because of the new issues with tab labels.
Comment 17 Mike Foley 2011-05-16 09:21:59 EDT
Moving the Tab label positioning to a new BZ.

https://bugzilla.redhat.com/show_bug.cgi?id=705038

The original issue is verified.
Comment 18 Heiko W. Rupp 2013-09-02 03:20:46 EDT
Bulk closing of issues that were VERIFIED, had no target release and where the status changed more than a year ago.

Note You need to log in before you can comment on or make changes to this bug.