IE6 Generic Trouble: nothing work !

Hi guys !

I’ve got another nice one !
After the IE7 specific bugs, FF3 specific bugs… here comes the IE6 specific bugs !

And those are… creepy.

On my computer, on a test laptop, and on my client boxes, with IE6, my application does not work. At all. Blank page, never ending loading, and an I6 going down in flames.
I’ve tested (only on my computer & my test laptop) to access the ITMill Toolkit demo on … And it does not work. Blank page again, sometimes with a JS error, sometimes not. At least, IE6 does not crash on the demo app…

The creepy part is that on my boss computer, the toolkit demo does work with IE6. My app does not, though.

Oh, and a week ago, my app was thoroughly tested with IE6, and everything worked fine. And I can’t think of anything of importance that have been changed since then.

So, err…
Does anyone have an idea of what could have gone wrong ?
I mean, if that was up to me, I would drop support for IE6, but it seems I can’t do that :frowning:

Thank you for any hint, idea or thought !


One week ago it worked and now it doesn’t? Something has changed for sure. Couple of (stupid) checks:

  • Have you cleared IE6 cache?
  • Have you upgraded Toolkit since you last tested?
  • Are you running 5.2.x series (not nightly builds)
  • If you have your own widgetset, have you remembered to recompile it?
  • You did not limit the widgetset recompilation to firefox, did you?
  • Have you added any browser-specific code since it worked? Custom layout changes?
  • Do you have a customized index.html? Did you make any changes to it?

If these did not help, could you describe how the IE6 do not work? Do you

  • Get the index-page?
  • Does it load widgetset?
  • Does it render any parts of the DOM-tree?
  • Does IE7 work?

Well, yeah, something obviously changed ^^
I’ll continue to do test to try & understand precisely
did change… I do love spending hours testing one SVN version after the other, trying to see what did change and what did not =) Especially when it is only to convince that damn IE6 browser to work…

But what really bug me is that on 2 of the 3 computers I can use to do IE6 test, I can’t even access the toolkit demo :expressionless:

And, yeah, IE7 is working fine.
As I need the MenuBar component, I use a nightly build version of the toolkit.

I do suspect some strange JS bug on my custom widgetset…
The worse kind of bugs ^^ It is so nice & quick to debug JS for IE6 !


Is the javascript enabled on those 2 IE:s?

If these did not help, could you describe how the IE6 do not work? Do you

  • Get the index-page?

  • Does it load widgetset?

  • Does it render any parts of the DOM-tree?

  • Does IE7 work?
    [/quote]To be a bit more specific…

  • Yeah, the index page work fine. But my app is a bit, err, special on that point: the index page is not controlled by the toolkit, it is a jsp login page (in order to use our business specific authentication system, based on spring security). IE6 crash as soon as I log in, on the very first access to the servlet. The ITMill servlet is ok, I can see it in my log.

  • I don’t know exactly where it hang. As I said, IE6 crash (I’m forced to kill it), I can’t access to the dom, or to anything. I just see a blank page with the loading widget displaying once (and then freezing).



Is the javascript enabled on those 2 IE:s?
[/quote]Yep. I’ve tried to track down the diff between the browser, but I can’t see any :frowning: But, well, that’s IE6, not exactly the browser which give the most details about what is happening…

And by going far away enough on my SVN repo, I can find a version where my magic IE6 accept to display something. I’m currently trying to find the diff between those versions… Not an easy nor a pleasant task :frowning:

Try to deploy using Toolkit-generated index-page. Does it work any better? If so, please assure that your JSP contains startup code exactly as defined in the Toolkit-generated index-page.

BTW: Which version of Toolkit you are using?

Ooooook… I think I found the source of the issue…

And, YES ! It is another of those “WTF IE ?” thingy.

I have, somewhere in my app, on the first page of the app, an OrderedLayout. Wanting to style that component, I use a layout.addStyleName(“theme”);
And this is it.

If I replace that line by, say, layout.addStyleName(“IE_DIE”), and adjust my CSS in consequence, everything work fine.
I mean… :expressionless: How can I explain that kind of bug to my client ?
Anyway, now it work, and that is what most important. But, meh… I can’t help myself but pray to the day where IE6 support will be dropped by everybody. All that stuff is just insane, in my opinion !

And, no, I’ve checked & double checked all my CSS, nowhere else I do reference another i-orderedlayout-theme.

Anyway, that does not explain why I’m not able to execute the live demo on . But that will be a mistery for another day :smiley:

Quentin, disapointed webdev :expressionless:

Great that you found a way to ‘fix’ it!

One tip for IE6 debugging is to compile gwt-output to “pretty”-format and then use some js-debugger to find problem.

I’ve once debugged ajax-applications that had very serious problems with IE6. It crashed without js-errors.

I found few options:

Microsoft Script Debugger:

  • sucks: Useful only for some basic js-errors.
  • sucks: Might cause ie6 to crash on different errors if this tool is installed.

Microsoft Script Editor:

  • A lot better than Script Debugger
  • Only available with Microsoft Office
  • Compile gwt ouput to “pretty”-format and this tool is almost what firebug is for firefox.

Visual Studio 2005 pro on newer:

  • Pro debugging, this is what you need if IE-crashes. You get total control over ie6, set breakpoints where you like, get stacktrace, halt excecution, automatic breaking if uncaught exception.
  • If I remember correctly, free version and standard edition comes with crippled debugger. You have to buy professional. I’d recommend you’d check what debugger free-version offers.

Microsoft debugging tools and symbols

  • Downloadable from MSDN
  • CLI (When IE6 crashes, it gives you option to open this tool). Writing “kb” to cli gives you stack trace
  • To enable you have to make few “regedit” adjustments.
  • Stack trace is not JS-stacktrace. You get only ms-dll stacktrace example:
    mshtml.dll?CDoc:InsertElement() + 0x98 bytes
    mshtml.dll?CDocument:get_implementation () + 0x135 bytes
    mshtml.dll?CElement:insertBefore() + 0x1b bytes
    mshtml.dll?CElement:appendChild() + 0x33 bytes
  • Really hard to figure out what caused it to crash (example from stacktrace above: that sequence can be anywhere where you added elements to DOM)

Wow! IMO just leave the style to be IE_DIE ;)

That is really strange and we would be really interested to hear if you find any solution. Could you try out to clear cache and see if it helps?

Thanks Mauno :slight_smile:

Joonas, yeah, I think I will let the “IE_DIE” style ^^

I’ve tried once again just now to access the live demo with my test laptop (which is now able to access my app). Cache is cleared, nav history is deleted, everything’s clear.
And nothing shows up.
I go an oh so explicit “Incorrect character - line 2 char 1” JS error when I attempt to open the page.

I’ll try to install those debug soft Mauno talked about, to see if I can get a more explicit error message…


And the bug strike again !

And all I had to do to solve it was to change the style name to “IE_DIE_2”…
This browser IS creepy :expressionless:


EDIT: I think I’m beginning to understand the beast.
It seems that each time I recompile my custom widget with my dedicated ant task, I have to change the style name on my component…
IE6 sure is a good mental sanity test =)

I have not heard of this kind of problem before and thus I just keep guessing… Try to clear all caches once more, both in browser and in gwt compiler; re-deploy the application from scratch. Try to remove the CSS-selector or IE_DIE altogether to and ensure that the style declarations (added by that selector) are compatible with IE.