MSIE still not working in NT8.40 and other issues.

[Rob Kolanko]

Hi Bruce,
I updated from NT8.33 to NT8.39.  I notice a few issues with my current development application in Firefox, but nothing compared to the new issues when the same app is experiencing with MS IE.  I saw that there were fixes for IE in NT8.40, but I am finding that many problems still exist.  Attached is a app that I created to test some browsing techniques. I have compiled it for NT8.40. Below are the most obvious issues when used  with IE 8 and 11. The most common versions used by my clients.

IE Issues. (these are not issues when used with Firefox)
On the Single Table Browse Example tab
- the table buttons do not work with IE 11
- navigation buttons do not work with IE 8
On the Multi-table Browse Example tab
- Miss aligned screen: Locator line, bottom row of navigation buttons, and record update buttons have been moved off to the side of the browse. Both IE 8 and 11
-The bottom row navigation buttons do not work properly with IE 11.
-Clicking on the browse header does change sort in IE 11
-Locator does not position the browse in IE11

There are many more issues with IE in my current development application. I hoping that fixing these problems will fix the other issues. Both IE version 8 and 11 worked just fine in NT8.33.

The NT8.39 release notes has:
Change: Consolidated msie8, msie9, msie10 and msie11 css files into a single msie.css
However when I inspect the Styles web folder, I see are number of msie?.css files, all with dates of Jan 27, 2011. Maybe the latest msie.css file is not included in the release?

Another Issue with all browsers.
Many of my forms do not have a URL for Save or Cancel.  In NT8.33, the forms after update would return to the page containing the browse that the form page was launched by the browse update buttons. Compiling my major application in NT8.40,  and pressing the Save or Cancel buttons on some of these forms does not return to the browse page but shows a page not found error. The incorrect URL contains the correct page name but has the this text attached: “returns<name of page that called the browse page>”.  I have not been able to duplicate this issue on a example. In the attached example, the “EmailTemplateForm” NetWebForm does not have a URL for Save or Cancel supplied and pressing the Save or Cancel buttons does request the “EmailTemplateList”  page.  However, in my major application when a user presses the Save or Cancel buttons in this same form,  an unknown page  “EmailTemplateListreturns_master.htm” is requested. “s_master.htm” is the last page that was displayed before “EmailTemplateList”  page, even though “EmailTemplateList”  was requested by a menu option.  I am hoping that the incorrect page being requested my jog your memory of a change done after NT8.33

Thanks,
Rob Kolanko


[attachment deleted by admin]

[kingja]

Bruce,

     I also have issues with the browses in NT 8.40 and IE 11.  If I use F12 to go to developer mode and force IE 9 emulation, things go back to normal.  I added the following code to the ProcessLink embed:

self.MetaHeaders = '<meta http-equiv="X-UA-Compatible" content="IE=9" />'


This forces IE 9 mode as a work around but hopefully you will solve this quickly.

Jeff

[Bruce]

Hi Jeff,

>> This forces IE 9 mode as a work around but hopefully you will solve this quickly.

yes, it's a reasonable short-term work-around, although IE9 has it's own issues, so not perfect their either. Also be careful, you _really_ don't want to leave this in your app in the long-term, it will bite you really hard down the road sometime. So be sure to remove it, and re-test, and re-report if you have any issues with later builds.

Bit of a backstory - IE is becoming better and better with regard to compatibility, which is definitely a good thing - but it means that "old code" has to be regularly refreshed to deal with that. This is just one of many reasons why staying updated on the server side is so important.

more about your specific issues in a moment Rob.

cheers
Bruce

[Bruce]

Rob,

>> On the Single Table Browse Example tab
>> - the table buttons do not work with IE 11

this has to do with the locator - I've tweaked the JavaScript for 8.41 - there's a big difference here between IE8, and IE9 and IE 10/11. I think I've got all the cases now though so give it a try when it's up.

>> - navigation buttons do not work with IE 8

your data contains non-ascii characters. Set the Charset for the site to 'utf-8'. In fact everyone should do this all the time - so much so that I'm thinking of removing it as an option. Having the charset set to something else just causes hassles.

>> On the Multi-table Browse Example tab
- Miss aligned screen: Locator line, bottom row of navigation buttons, and record update buttons have been moved off to the side of the browse. Both IE 8 and 11

You're setting custom CSS on that browse - specifically nt-left for the table div, and nt-right for the locator. That's what is affecting the look. I think you'd get what you want by removing the 'nt-left' one.

>> -The bottom row navigation buttons do not work properly with IE 11.
>> -Clicking on the browse header does [not?] change sort in IE 11
>> -Locator does not position the browse in IE11

all I think related to the utf-8 charset.

>>  I am hoping that the incorrect page being requested my jog your memory of a change done after NT8.33

Unfortunately nothing springs to mind. Obviously somethign is different between your app, and the examples you've been making, but I don't know what it is. Make sure you have the page/popup mode matching though - that's the most likely cause of a difference.
Also charset, and also turn off all performance switches to see if that makes a difference.

Cheers
Bruce

[Rob Kolanko]

Hi Bruce,
It is hard to believe that you are not seeing the same results that I am viewing with same application. This app works and appears perfectly in firefox. As far as I recall the IE issues only appeared after NT8.39

your data contains non-ascii characters. Set the Charset for the site to 'utf-8'. In fact everyone should do this all the time - so much so that I'm thinking of removing it as an option. Having the charset set to something else just causes hassles.

There are two fields for character sets in the Advanced tab of the web server: "Character Set" and "Store Data As". I did have an ISO character set in the Character set field. I change it to 'utf-8' . After recompiling  with both  fields set to 'utf-8', all the same problems I reported for IE 11 still exist in layout, navigation buttons, etc.  As in non-ascii characters, I think you mean the accented characters to support French, yes we have those. With the "Store Data As" in 'utf-8' these characters appear as Chinese characters. If I change the  "Store Data As" to Western European then the accented characters appear correctly. The "Character Set" is still set to 'utf-8'.

You're setting custom CSS on that browse - specifically nt-left for the table div, and nt-right for the locator. That's what is affecting the look. I think you'd get what you want by removing the 'nt-left' one.

Removing the 'nt-left' on the browse did fix the layout issues with this page in IE, but caused layout issues in Firefox. In this test I was trying to move the locator to the right side of the browse on the same line as the navigation buttons. Anyway with the  "Character Set" set to 'utf-8' and removing the 'nt-left' on the browse; fixed the issues with IE8.

>> -The bottom row navigation buttons do not work properly with IE 11.
>> -Clicking on the browse header does [not?] change sort in IE 11
>> -Locator does not position the browse in IE11
all I think related to the utf-8 charset.

All these problems still exist using the utf-8 character set in IE 11.

Please help, thanks
Rob Kolanko

[Bruce]

Hi Rob,

>> There are two fields for character sets in the Advanced tab of the web server: "Character Set" and "Store Data As".

correct. The Charset was the one I was referring to. that should be 'utf-8'. IE8 was reporting an error "invalid xml character" with the French characters when using the ISO charset. (That was presumably a bug in IE8, because IE11 didn't consider that to be an error.)

The "save data as" is a completely different setting, and should be set to match the format you are storing your data in. In your case you've been storing as "ASCII" so you should keep that as something in line with that. In my test here I picked "French" because the text was obviously French. (hint: many of the options are equivalent, but best to pick the one that best describes your text.)

>> All these problems still exist using the utf-8 character set in IE 11.

There was a typo in my last note. These are all related to the _javascript_ as well as the charset - so are working now on my side.

>> It is hard to believe that you are not seeing the same results that I am viewing with same application.

but I was seeing the same thing - which is why I'm confident in the fixes.

>> This app works and appears perfectly in firefox. As far as I recall the IE issues only appeared after NT8.39

I suspect it goes back a couple builds before that. It has to do with the way locators are handled, and specifically a change that was made to support the X in the locator entry field.

I'm not as big a hater of IE as some - fortunately I've not had too many issues with it - but if you're interested a small hint of the problems working with it are summarized here;
http://help.dottoro.com/ljhxklln.php .

Probably the biggest issue with IE is that it's not "continually updated". So basically there's just 1 version of Firefox, and 1 of Chrome - but IE has at least 4 major builds still in the wild (with _very_ different behavior characteristics.) IE11 is pretty easy to deal with, but as one goes back in time it gets harder and more erratic.

Incidentally Spartan will also be continually upgraded so 5 years from now we'll be able to ignore IE completely...

cheers
Bruce

[Bruce]

Re: Many of my forms do not have a URL for Save or Cancel.
 
In netweb.clw is a method called .PlainText
 
it contains the following line;
 
p_notOk.KeepChars('0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcedfghijklmnopqrstuvwxyz/:._')
 
add three chars to the end of it;
 
p_notOk.KeepChars('0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcedfghijklmnopqrstuvwxyz/:._?&=')
 
and let me know if that sorts it out.
 
cheers
Bruce

[Rob Kolanko]

Hi Bruce,
NT 8.41 fixed all the previously stated issues in this thread. So far MSIE 11 and Nettalk getting along and the forms are returning to the browses without entering the Save/Cancel URL.

Thanks again for your prompt reply.
Rob Kolanko

[kingja]

Same for me Bruce.  Thanks!