Nightly build v1.10.7-dev Build: 16th Apr 2015 kills IE7

wjhumphreys

Nightly build v1.10.7-dev

Build: 16th Apr 2015

and a few versions before kills IE7. It actually makes the browser crash. This isn't in emulation mode but the real IE7 on XP.

If you emulate it its OK.

If I go back to DataTables 1.10.5-dev its ok

Billy

allan

Thanks for letting me know about this. I don't have an IE7 machine available right at this moment, so I can't immediately look into it, but I will do next week.

Allan

wjhumphreys

I have emailed you :-)

allan

Thanks for the e-mail. I can indeed confirm that the current build crashes IE7 for some reason. I currently don't have any idea why I'm afraid - I will try to look into this next week.

Allan

allan

Hi,

I've just been looking into this and it appears that IE7 has "issues" if you bind a resize event handler to the window on page load - you take the browser out!

I've just committed a fix for this and it will be in the 1.10.7 release I'm going to package up soon.

Worth me pointing out that IE6/7 support will be dropped in DataTables 1.11.

Allan

wjhumphreys

I must admit one of the main reason I use datatables is because it supports IE7 (IE 6 is dead). It is also more widely used than people realise. Like the whole of the NHS and most of government. Is also not going to be replaced any time soon.These statistics dont tend to come upon 'Internet' reports as a lot are on Intranets. Just food for thought but if its being dropped and I completely understand why would it be possible to maybe have an additional fix file to be loaded maybe after the main one rather like the IE7.css file you tend to find for css.

Kind Regards

BIlly

larsonator

IE7 users should upgrade :/

wjhumphreys

I have to say that though this is the ideal from a developer point of view its not so simple. the tax funded UK National Health Service has over 1.4 Million users and is the fifth largest employer in the world. It also has billions of pounds of software that was written to run in IE 7 (and certified for it) that can not easily be replaced. The update of all this software comes to a cost of billions of pounds to UK tax payers so frankly you statement is just fashionable nonsense and just shows a lack of understanding of the real issues with old software (I guess we should stop using Cobol as well, which most of the banking infrastructure is written on and STILL using). I go into even small company's every day with small networks that have been functioning quite happily on XP and IE 7 for years that simply dont have the money to upgrade for thousands of pounds (as they have to upgrade their bespoke software as well). It is not unusual for me to find this and is quite the norm. You will also find that most of China especially the government is still using XP (Not always IE7 though). A lot of expensive software historically was written and certified for IE 7 and can not simply be replaced without large cost. So a stupid statement like 'IE7 users should upgrade' is a bit like saying everybody in the world should by a new car because it uses less fuel......................

larsonator

I can certainly appreciate the larger picture,
but the maintenance and upgrade of technologies is an ongoing process, and should be budgeted for. (and yes i also understand that many public services in this day and age get their funding cut),
but IE7 is 9 years old now. and how will technology evolve in another 5 years time? and then 10 years?
how much would it cost to upgrade in 10 years times or at a point where the use of IE7 just isn't viable anymore?

allan

@wjhumphreys - as a developer I hope you charge extra for supporting IE7 :-)

DataTables 1.10 will still be around when I release 1.11 and may still receive critical updates if issues are found - so legacy versions of IE can still use DataTables. They just won't get some of the latest and greatest features.

To be honest, legacy IE support in DataTables is actually relatively easy as jQuery takes almost all of the pain away. Removing the code that supports IE6/7 might save a few kilobtyes at most, but what is the real killer for me is the amount of time it takes to debug issues. Case in point - I'm still actually seeing a problem with IE7 this morning, despite my fix above - working on it...

I suspect that what I will be doing with 1.11 is removing support for scrolling tables in IE6/7 (which will just result in a small rendering error), but everything else should still work. I'll probably have to leave the fix from this thread in place as it just wouldn't be right for the library to crash the browser - even if it is a browser bug and is an unsupported browser. I like the old YUI style of browser support - generally target A grade browsers, C grade for basic support and what else happens, happens.

What would make a real different in library size is being able to support only IE9+. But I'm not ready to drop IE8 support...

Allan

allan

I've just committed another fix that was killing IE6/7 when using DataTables' column width calculations due (apparently) to a clone of a clone.

This is where we actually see the benefit of supporting old browsers - it was a pain to debug, but it reduced the code size a little (56 bytes) and improves performance a little in all browsers...

Is now in the nightly and I'm going to package up 1.10.7 shortly.

Allan

wjhumphreys

Cheers. I must admit as much as I hate IE 7 it is true that you have to create very precise and accurate code as the newer browsers do let a lot slip which I dont think is a good thing.

wjhumphreys

Ive just updated to the latest 1.10.7 but it still kills Windows XP running IE 7. Its better than before but just creates the send error to Microsoft dialog blah blah and then closes the browser.

wjhumphreys

Just another note but I'm also using the scroller as well.

allan

If you disable Scroller does it work then?

I haven't been able to reproduce the crash with just plain old DataTables since 1.10.7.

Allan

wjhumphreys

Ive not had the chance to test yet but if it helps this is my current code.

Server side paging with scroller.

_fooDataTable = $("#table-foo").DataTable({
      "destroy": true,
      "serverSide": true,                            
      "ajax": function (data, callback, settings) {  
        $.ajax({
          url: "/FormAjaxHandler/MYAPI",
          type: "POST",
          dataType: "json",
          data: {
            draw:           data.draw,
            start:            data.start,
            length:         data.length,
            someId:        $("#Foo").val()
          },
          beforeSend: function (xhrObj) {
            $(".DTS_Loading").show();
          }
        })
        .done(function (data, textStatus, jqXHR) {
          
          // Whatever

          callback(data);

        })
        .fail(function (jqXHR, textStatus, errorThrown) {
          // Whatever
        })
        .always(function (data, textStatus, jqXHR) {
          $(".DTS_Loading").hide();
        });
      },
      "autoWidth": false,         
      "deferRender": true,        
      "scrollX": "100%",          
      "scrollY": "28.125em",      
      "scrollCollapse": true,     
      "orderClasses": false,      
      "lengthChange": false,      
      "searching": false,         
      "ordering": false,          
      "info": true,               
      "dom": "rtiS",               
      "scroller": {               
        "loadingIndicator": true,
        "displayBuffer": 12       
      },
      "language": {
        "emptyTable": "There are no foo" 
      },
      "initComplete": function (settings, json) {    
        this.api().scroller().measure();              
      },
      "columns": [
         {
           "render": function (data, type, row, meta) {
             return "<a id='" + data + "' class='form-guid-link' href='#'>Display Foo</a> ";
           }
         },
         null,
         null,
         null,
         null,
         null,
         null,
         null
      ]
    });

allan

I've just committed a change that disables smart column width handling for IE6/7 has it is proving to be an absolute nightmare to get it working properly (a simple $().remove() or $().clone() is killing the browser).

However, there is still a problem with scrolling which can crash the browser, I suspect related to cloning the nodes as well, but not sure where.

I'm going to have to come back to it as it is taking up rather a lot of time and there is a huge pile of other things that need to be done unfortunately. I've been trying to reproduce a simple test case that causes the issue, but haven't managed yet.

Allan