[Isomorphic]

Thanks for this test case.
We are now seeing a scrollbar on the selectItem in IE9, running against the 3.1p nightly build dated Jan 24 2013.

We are investigating this and will let you know as soon as we have more information

Regards
Isomorphic Software

[Isomorphic]

We have addressed the bug we saw with the simple sample code you posted.
The problem we saw was this - the SelectItem showed an unnecessary vertical scrollbar in its pickList in IE9 (running in a standard SGWT app, with the HTML5 doctype specified).

This should be resolved in the next nightly build.

Please try the next nightly build and let us know if you continue to see issues with unnecessary scrollbars.

Regards
Isomorphic Software

[Isomorphic]

Just to clarify - as expected, the issue with browser-level scrollbars from the original video was not reproducible, and the best guess remains that this a problem with third-party libraries, browser zoom or similar.

[fhisg]

the issue with browser-level scrollbars from the original video was not reproducible, and the best guess remains that this a problem with third-party libraries, browser zoom or similar.

That turns out to be a quirks vs. standard issue in all IEs (tested 6-9) with SmartGWT 3.1. I removed "X-UA-Compatible" meta instructions from HTML, made sure there are no "document.compatMode" instructions or the like in *.gwt.xml and made sure the HTML5 doctype is correct.

I had somehow missed that your FAQ now recommends to use HTML5 (standard) for IEs in particular. True, switching to standards mode removes the odd scroll bars but causes lots of other issues in our application we first need to look into (e.g. vertical overflow scrollbars in grids blocked, grid row heights not respected, etc.).

Is it correct you're no longer looking into issues that quirks mode causes in IE9?

[Isomorphic]

We now recommend HTML5 doctype be specified. We now take advantage of some HTML5 features within the framework in various places (including our Drawing and Charting subsystems, certain skinning effects, etc).
Having said this, these features should degrade gracefully on older browsers with no HTML5 support, or on browsers where no doctype is set, or a backcompat doctype is explicitly specified.

So to answer your question - it is not true that we are not interested in issues seen in quirks mode in IE9. We still take such issues seriously.

Having said that, we have had difficulty ever reproducing the original problem described in this thread whereby showing a SelectItem drop down would introduce browser level scrollbars. We have run your test cases without success so we must be missing something.

If you're still seeing this, we can take another look, but we really need a foolproof way to reproduce. What we'd recommend is:

- pare your application down to the simplest possible source code you can use to reproduce the problem. Ideally an EntryPoint class with a small onModuleLoad() implementation that creates and draws the offending component(s)

- ensure your bootstrap HTML file is clean of any additional external CSS, third party libraries, or other unrelated logic.

- verify which SmartGWT package you're working with (for best results, grab the latest nightly build in the branch you're on, then tell us the version number reported by evaluating "isc.version" in the developer console so we can be sure we're testing with the same package).

- show us your bootstrap HTML file, your entry point class, and your .gwt.xml file (so we can be sure the set of "inherits" is correct)

- list out full steps to reproduce (including detailing whether you're running in development or compiled mode).

You also list out a number of other issues you're seeing within your application when you switch into HTML5 mode. We will be happy to look at these as well, but we'd recommend you post a new forum thread for each problem so we can address them individually. We're not aware of anything that should be causing the problems you're describing, but it may become clear once we see how you are reproducing the problem.

Also a side note - as a sanity check we'd recommend you clear the browser cache, and quit and restart the browser before hitting your application to test once you make changes such as changing the specified doctype. We have seen cases where Internet Explorer fails to correctly switch between rendering engines on a simple page reload (or hangs onto cached resources inappropriately).


Thanks for your patience with this. Please be aware that we take your reports seriously, and will do what we can to get you a quick resolution. We just can't do much when we aren't able to reproduce the problem on our end.

Regards
Isomorphic Software

[fhisg]

First and foremost, thanks for your thorough response.

So to answer your question - it is not true that we are not interested in issues seen in quirks mode in IE9. We still take such issues seriously.

That's really good to hear. I've always hated to work in quirks mode but since it's been your recommendation for so long our apps are now based on it. I'd like to switch to standards mode but at the moment we see too many issues in our app with IE9.

- pare your application down to the simplest possible source code you can use to reproduce the problem. Ideally an EntryPoint class with a small onModuleLoad() implementation that creates and draws the offending component(s)

That'd be the class in post #15 above.

- ensure your bootstrap HTML file is clean of any additional external CSS, third party libraries, or other unrelated logic.

<!-- quirks -->
<!DOCTYPE HTML>
<html>
  <head>
    <script type="text/javascript" src="smartgwt/smartgwt.nocache.js"></script>
  </head>
  <body>
  </body>
</html>

- verify which SmartGWT package you're working with (for best results, grab the latest nightly build in the branch you're on, then tell us the version number reported by evaluating "isc.version" in the developer console so we can be sure we're testing with the same package).

It's the near latest, v8.3p_2013-01-29/LGPL.

- show us your bootstrap HTML file, your entry point class, and your .gwt.xml file (so we can be sure the set of "inherits" is correct)

<?xml version="1.0" encoding="UTF-8"?>
<module rename-to='smartgwt'>
  <inherits name='com.google.gwt.user.User'/>
  <inherits name="com.smartgwt.SmartGwt"/>
  <inherits name="com.smartgwt.tools.SmartGwtTools"/>  
  <entry-point class='com.corp.smartgwt.client.SmartGwt'/>
</module>

- list out full steps to reproduce (including detailing whether you're running in development or compiled mode).

Running in dev mode from Eclipse:

• removing /gwt-unitCache and /war/smartgwt (compiled artifacts) in Eclipse
• closing IE, opening it again, clearing cache, closing IE
• running app in dev mode
• opening it in IE -> all good
• opening SelectItem pick list -> scroll bars

See the new screen shot I attached (smartgwt-selectitem-ie9-quirks.png).

You also list out a number of other issues you're seeing within your application when you switch into HTML5 mode. We will be happy to look at these as well, but we'd recommend you post a new forum thread for each problem so we can address them individually.

Yes, I know I must first write test cases for those standards mode issues (might as well be our CSS).

We just can't do much when we aren't able to reproduce the problem on our end.

I do understand that. It's the same we tell our customers when they report a problem - except that they are not able to write test cases....

[Isomorphic]

Please confirm you are not zoomed (we've mentioned this twice, but you haven't confirmed).

Please confirm you can reproduce this on at least one other machine, and on a machine that has no extensions installed for IE9.

[fhisg]

Please confirm you are not zoomed (we've mentioned this twice, but you haven't confirmed).

Ah, yes, I tested but failed to report sorry. I'm not zoomed. However, I can also confirm that the problem is present when zoomed, too.

Please confirm you can reproduce this on at least one other machine, and on a machine that has no extensions installed for IE9.

I compiled the app and moved it to plain Win2008 server installation (I'm on Win7) with no browser extensions. I can confirm that the problem is present there, too.

[Isomorphic]

Aha - we seem to be reproducing the problem using exactly your bootstrap file / other settings.
We have a developer investigating this now. We'll let you know when we have more information

Regards
Isomorphic Software

[fhisg]

What a relieve...*sigh*

I just found out that the same problem exists if you have a MenuButton-Menu-MenuItem combination and then click the menu button. I suppose similar/same code is used for that, too.

[Isomorphic]

We have made a change which we believe will take care of this. Please try the next nightly build dated Feb 5 or greater

Regards
Isomorphic Software

[fhisg]

Please try the next nightly build dated Feb 5 or greater.

At long last...Thanks for fixing this, works fine in my test case now. However, I had to add

body {
  overflow: auto;
}

because without it IE9 displayed a greyed out (ie. disabled) vertical scroll bar. This has nothing to do with the current fix from Feb 5th, though. That behavior was present ever since I upgraded to 3.1 as can be seen in the video I posted in my first post. The IE9 dev tools don't indicate that your code would be fiddling with overflow at html/body level. Not sure where this comes from...maybe something to do with quirks and the hidden iframes?
Anyway, I can certainly have this in my CSS but it'd be interesting to know why it's got to be there.