Announcement

**Isomorphic** · 21 Nov 2012, 14:27

Be sure to test this kind of thing only with a fresh instance of IE9 - just started after closing all other instances and all tabs.

The reason for this is: if you are either using the compatibility mode button to switch modes, or you are changing the <!DOCTYPE> declarations and reloading the page, IE9 frequently gets into a wedged state that is neither strict mode nor compatibility mode and is basically a broken state.

So make sure you can reproduce it with a freshly started browser.

At that point, if it is reproducible, try it with an outer page that has nothing except the iframe - no Struts-generated content. If it's still reproducible there, we need the DOCTYPE from the inner (SmartGWT) page, and we can check if it's reproducible for us.

**tamt** · 22 Nov 2012, 07:33

Answers for your questions:

1. We always test on a fresh browser start. It is 100% reproducible.

2. As stated before, the problem does not exhibit itself if we call the SmartGWT application URL directly from the browser (no struts generated content).

Please advice on what we need to collect to help debug the problem.

**Isomorphic** · 22 Nov 2012, 10:57

Just follow the remaining advice from the last post:

At that point, if it is reproducible, try it with an outer page that has nothing except the iframe - no Struts-generated content. If it's still reproducible there, we need the DOCTYPE from the inner (SmartGWT) page, and we can check if it's reproducible for us.

**tamt** · 22 Nov 2012, 14:15

Not reproducible outside of our struts framework with the simple test:

<iframe src="http://100.45.104.221/MyApp" width=1200 height=800></iframe>

Might not be struts code after all. Our situation is a follows. Our main application is written in struts, however, that application is being launched in a custom web framework. I'm launching my smartGWT application as a iFrame in the struts app. I noticed via the F12 debugger that the custom web framework is putting the following DOCTYPE in the HTML page:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

Would this affect the SmartGWT framework?

T.

**Isomorphic** · 22 Nov 2012, 15:08

In general, SmartGWT compensates for whatever DOCTYPE settings you apply (except totally incorrect ones, like XHTML). But we recommend the HTML5 DOCTYPE ("<!DOCTYPE html>") because without it, IE9 actually turns off certain key features.

Please try testing this situation without the recommended DOCTYPE declaration, and without your web framework involved; we're not sure what else it might be doing if it inserts DOCTYPE declarations automatically.

**tamt** · 30 Nov 2012, 07:39

Dear Isomorphic Support:

I hacked the web framework we were using so that it didn't embed the two DOCTYPE statements in the page and the problem went away. Seems the DOCTYPE that I posted previously does impact the SmartGWT framework.

T.

----

**Isomorphic** · 30 Nov 2012, 08:32

No, PickLists operate fine with that DOCTYPE. The problem is that you must also have some CSS that affects all elements of a certain type on the page (eg a style that affects <td> elements in general).

That kind of styling is very bad practice and is known to produce this specific effect. The difference in DOCTYPE has removed this particular symptom, but you should find and eliminate the bad CSS to avoid other problems in the future.

**tamt** · 3 Dec 2012, 09:43

Dear Isomorphic Support:

I don't think it is a CSS issue since I'm only using the default CSS that came from the SmartGWT SDK in the application. I would have to inject CSS into the iFrame for your speculation to be accurate.

I also entertained the theory by hacking the server and removed all the parent CSS prior to the iFrame and the issue still occurs.

Looking in F12 debugger it looks like the SDK auto injects:

sc/skins/Enterprise/skin_styles.css

and this is the only css that I didn't hack out. Below is the F12

HTML and style capture for the picklist in question (see code section) of what was left after the hacking.

Another interesting thing is it seems that the previous recommendation is to be in quirks mode and the change to standards mode was recent for the changes in IE9. I checked with IE7 and IE8 and the SDK seems to put the browser into compatibility mode automatically. The interesting part is the quick reference guide that the 3.0p nightly build is linking to still recommends putting the system into compatibility mode.

Does the 3.0 stream have all the IE9 changes in it. If it does, I am really at a loss here since I stripped out all the CSS except for the SmartGWT ones and the problem still seems to persist.

Please provide next steps.

T.

Code:



<td class="tallCell" align="left" style="WIDTH:100px;OVERFLOW:hidden;padding-top:0px;padding-bottom:0px;HEIGHT:22px;color:#0066CC;">
<div style="overflow:hidden;WIDTH:96px;" cellclipdiv="true" role="presentation">
<nobr>
<span id="isc_24" $89="isc_SelectItem_2" eventproxy="isc_DynamicForm_12" style="white-space:nowrap;">
<table id="isc_25" class="selectItemControl" cellspacing="0" cellpadding="0" style="cursor:default;width:96px;" $9a="$9f" $89="isc_SelectItem_2" role="presentation">
<tbody>
<tr>
<td style="margin:0px;border:0px;padding:0px;background-image:none;background-color:transparent;">
<div id="isc_26" class="selectItemText" tabindex="1930" style="width:73px;height:16px;overflow:hidden;white-space:nowrap;text-align:left;" $9a="$9d" $89="isc_SelectItem_2"> </div>
</td>
<td id="isc_27" class="selectItemPickerIcon" style="">
</tr>
</tbody>
</table>
</span>
</nobr>
</div>
</td>




element.style {
    height: 16px;
    overflow: hidden;
    text-align: left;
    white-space: nowrap;
    width: 73px;
}
.selectItemText, .selectItemTextError, .selectItemTextFocused, .selectItemTextDisabled {
    border-right: 0 none;
}
.textItem, .textItemFocused, .textItemDisabled, .textItemDisabledHint, .textItemError, .textItemHint, .selectItemText, .selectItemTextError, .selectItemTextFocused, .selectItemTextDisabled, .selectItemTextHint {
    background: none repeat scroll 0 0 #FFFFFF;
    border: 1px solid #AAACB2;
    color: black;
    padding: 2px;
}
.formTitle, .formTitleFocused, .formTitleDisabled, .formCellError, .formTitleError, .formHint, .headerItem, .headerItemDisabled, .headerItemError, .staticTextItem, .staticTextItemDisabled, .staticTextItemError, .textItem, .textItemFocused, .textItemDisabled, .textItemDisabledHint, .textItemError, .textItemHint, .selectItemControl, .selectItemControlError, .selectItemControlFocused, .selectItemText, .selectItemTextError, .selectItemTextDisabled, .selectItemTextFocused, .comboBoxItemPendingText, .pickListCell, .pickListCellSelected, .pickListCellDisabled, .pickListCellDark, .pickListCellSelectedDark, .tallPickListCell, .tallPickListCellSelected, .tallPickListCellDisabled, .tallPickListCellDark, .tallPickListCellSelectedDark, .labelAnchor, .labelAnchorDisabled, .labelAnchorError, .labelAnchorFocused {
    color: black;
    font-family: Arial,Verdana,sans-serif;
    font-size: 11px;
}
element.style {
    cursor: default;
}
.formTitle, .formTitleFocused, .formTitleDisabled, .formCellError, .formTitleError, .formHint, .headerItem, .headerItemDisabled, .headerItemError, .staticTextItem, .staticTextItemDisabled, .staticTextItemError, .textItem, .textItemFocused, .textItemDisabled, .textItemDisabledHint, .textItemError, .textItemHint, .selectItemControl, .selectItemControlError, .selectItemControlFocused, .selectItemText, .selectItemTextError, .selectItemTextDisabled, .selectItemTextFocused, .comboBoxItemPendingText, .pickListCell, .pickListCellSelected, .pickListCellDisabled, .pickListCellDark, .pickListCellSelectedDark, .tallPickListCell, .tallPickListCellSelected, .tallPickListCellDisabled, .tallPickListCellDark, .tallPickListCellSelectedDark, .labelAnchor, .labelAnchorDisabled, .labelAnchorError, .labelAnchorFocused {
    color: black;
    font-family: Arial,Verdana,sans-serif;
    font-size: 11px;
}
element.style {
    white-space: nowrap;
}
element.style {
    color: #0066CC;
}
.cell, .cellDark, .cellOver, .cellOverDark, .cellSelected, .cellSelectedDark, .cellSelectedOver, .cellSelectedOverDark, .cellDisabled, .cellDisabledDark, .tallCell, .tallCellDark, .tallCellOver, .tallCellOverDark, .tallCellSelected, .tallCellSelectedDark, .tallCellSelectedOver, .tallCellSelectedOverDark, .tallCellDisabled, .tallCellDisabledDark, .gridSummaryCell, .gridSummaryCellDisabled, .groupSummaryCell, .groupSummaryCellDisabled, .recordSummaryCell, .recordSummaryCellDark, .recordSummaryCellOver, .recordSummaryCellOverDark, .recordSummaryCellSelected, .recordSummaryCellSelectedDark, .recordSummaryCellSelectedOver, .recordSummaryCellSelectedOverDark, .recordSummaryCellDisabled, .recordSummaryCellDisabledDark, .expansionCellCell, .expansionCellCellDark, .expansionCellCellOver, .expansionCellCellOverDark, .expansionCellCellSelected, .expansionCellCellSelectedDark, .expansionCellCellSelectedOver, .expansionCellCellSelectedOverDark, .expansionCellCellDisabled, .expansionCellCellDisabledDark, .specialCol, .specialColOver, .specialColSelected, .specialColSelectedOver, .specialColDisabled, .groupNode {
    color: black;
    font-family: Arial,Verdana,sans-serif;
    font-size: 11px;
}
element.style {
    cursor: default;
    visibility: inherit;
}
element.style {
    cursor: default;
}
element.style {
    cursor: default;
    visibility: inherit;
}
element.style {
    cursor: default;
    visibility: inherit;
}
.normal {
    color: black;
    font-family: Arial,Verdana,sans-serif;
    font-size: 11px;
}

**Isomorphic** · 3 Dec 2012, 13:22

As far as why you're still seeing the problem when we can't reproduce it, again we would point out the issue with IE tools. Make sure you test with a fresh browser and clear cache.

Since an IFRAME is involved, and IE also has some problems around "super-caching" iframe assets, we'd also recommend changing the URL just to be sure you aren't somehow loading something old despite clearing the cache.

Bigger picture, it seems you already have a fix - use either no DOCTYPE or the HTML5 DOCTYPE (<!DOCTYPE html>).

Also, you should be using 3.1; there's no reason to be using 3.0 for new development.

**tamt** · 3 Dec 2012, 13:32

We do a fresh browser clear cache in all our tests just for the very reason you point out.

The DOCTYPE removal (going in quirks mode) is not an option for production and I just did that for testing purposes to help debug. Also to note, the HTML 5 doc type <DOCTYPE html> also shows the problem. The only way for the problem to go away is to have the document in quirks mode (no DOCTYPE).

In terms of SmartGWT 3.1, when we started development two months ago, the web site had 3.0 as the stable load. Just noticed that it is now 3.1.

Is there a way to get notified what the current stable load is without having to poll the download page?

Will switch our base to 3.1, however, still need help on why the picklist is not rendering correctly in standard mode and only works in quirks mode. As stated before, I stripped it down to only the Isomorphic CSS and still have the issue.

Recommendations please, T.

**Isomorphic** · 3 Dec 2012, 13:38

3.1 was announced with a mass email to all registered developers. Most likely the announcement was erroneously caught in your spam filter. Title was "Smart GWT 3.1 / SmartClient 8.3 Released and 30% off Holiday Sale" and it went out Nov 21.

We'd recommend upgrading to 3.1 now, since we still suspect that this unreproducible issue is related to something cached on stale on your system, and doing the upgrade (which you need to do anyway) will probably flush it out.

**tamt** · 3 Dec 2012, 13:54

Indeed caught by the spam filter.

I upgraded to 3.1 and still see the issue. Still starting a new browser session and clearing the cache on all procedures.

T.

----

**Isomorphic** · 3 Dec 2012, 18:07

Just re-confirmed again: display is fine in all 3 DOCTYPEs when embedded in a frame in IE9. We're using a copy of the Databound Dependent Selects example, modified to show only two categories.

Time to check basic assumptions:
1. are you actually running this outside of your Struts app
2. can it be reproduced on any other machine
3. what is the actual SmartGWT sample code you're running
4. what skin are you using
5. are you using browser-level zoom
6. do you have any non-default browser settings, such as a "user stylesheet" or changing the default browser font?

Finally, can you show a screenshot of what you're seeing (with the PickList open)

**tamt** · 4 Dec 2012, 06:50

I think I narrowed down what the issue is. It seems that IE doesn�t seem to be completely standards compliant and is switching into quirks mode for some reason by the time it reaches my iFrame.

I added a force standards mode tag:
<meta http-equiv="X-UA-Compatible" content="IE=9; IE=8; IE=7; IE=EDGE" />

In the application html page and it renders correctly. Have a look at the attachment:
F12_quirks.jpg.

F12 debugger thinks browser mode is IE9 and document mode is IE9 standards since we have a <!DOCTYPE hml> in the first line of our bootstrap html. I put in a <!DOCTYPE html> tag in the SmartGWT project for testing and notice that IE converted it to <!�DOCTYPE html --> as it would do in quirks mode. Verified that it is an IE behavior by debugging in Firefox and the test doc type does render <!DOCTYPE html> in the SmartGWT application index page.

I found this on the web:
http://stackoverflow.com/questions/6529728/html5-doctype-putting-ie9-into-quirks-mode

Where it indicates that there are conditions where IE doesn�t honor, however, I don�t think this one is my case since I don�t have any comments before the DOCTYPE or conditional statements. So perhaps there are other situations where the HTML 5 tag is not being adhered too with IE for standards mode.

Moving forward we need to determine :

1. Can the Isomorphic code really depend on DOCTYPE to determine which mode to operate in since it seems that Microsoft is not adhering to it anyways for some conditions? If not, what can be done with the Isomorphic code to handle this.

2. Is it a valid workaround (or maybe something for best practice) to hard code the browser mode (eg. <meta http-equiv="X-UA-Compatible" content="IE=9; IE=8; IE=7; IE=EDGE" />) to work around the IE behavior. I am always leery on putting any custom Microsoft tags since it usually breaks other browsers. Is this a safe work around when used with the SmartGWT SDK.

I also included a capture of the bad rendering in bad_picklist.jpg.

Cheers, T.

Attached Files

Announcement

Picklist in listgrid not rendering correctly in IE 9 when launched from a iFrame

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment