6 ms·

IE 11 Crashes After Clearing 5+ Input Elements

27 points by dahjelle 13y ago

dahjelle 13y ago
We ran into this in out application the other day, and it's a surprisingly "normal" thing to do to result in a hard crash of a browser. I'm especially curious if anyone knows: 1. Is there any hope of this being fixed in the near-term? The MS bug report didn't have much information. I'd sure like to avoid implementing the somewhat crazy workaround if I can help it. 2. It seems like this ought to be a pretty widespread problem. Are others seeing it? Are there other workarounds that aren't so ugly?
Piskvorrr 13y ago
Well, shit. And for a few short years, it seemed that IE has outgrown its monstrous reputation it had rightfully acquired in the 00s; nope, still the usual "spend enormous time catering to my quirks" IE. This makes me sad.
- dak1 13y ago
  There's definitely still some weird IE bugs, although they're more (but not exclusively) on the JavaScript side now rather than CSS. For example, if you have a form without a submit button in IE 10, and a `<button>` element anywhere else on the page, IE will treat the <button> as the submit and "click" it for you rather than submit the form. If you don't have a `<button>` element though it will submit the form as expected.
  - riquito 13y ago
    I think this is a long time bug, not IE10 specific.
  - dspillett 13y ago
    There are various inconsistencies between browsers (including between version of IE) when you do not explicitly set the type attribute of a button tag. Some will default to it being a submit button and some will default it to being a "button" button. In the instances where we hit this problem making sure to specify a type seems to make things more consistent.
- EarthLaunch 13y ago
  With each release of IE since IE7, there has been some kind of marketing push saying "THIS version is the one that is modern and totally standards-compliant, really", and a bunch of people repeat that. Then it turns out to be buggy. Then the cycle repeats. No one should be surprised at IE11's flaws. I believe IE's quality has been fairly consistent over the years. IE6 had a monstrous reputation mainly because it was outdated and widespread for so long.
  - Piskvorrr 13y ago
    I have passionately hated IE6, 7, and 8; IE9 has managed to reduce this to a resigned "meh, good enough, what took you so long?" (which _was_ a significant change to the better). I was hoping that IE was finally shaping up to be an A-grade browser. Oh well.
- belluchan 13y ago
  It hasn't outgrown it's monstrous reputation and it will probably never. IE has long gaps between updates so it will always quickly fall behind. Software can still install toolbars and change your default search engine. IE is not open source. IE 11 does not implement X standards for business reasons, where X is WebRTC, some missing CSS thing, touch events, etc. You can't test for IE except on Windows. IE's developer tools are terrible. IE is used by people bad with computers and corporations with bad IT departments. For me to care about IE, it would: have to be available on Mac OS X. have to have bigger market share in mobile just have more people using it in general (because frankly it's not used much by any of the people we care about). have much, much better development tools Our development cycle is to develop in Chrome Canary, and proactively test and fix for Firefox. We don't test in IE but fix IE issues when someone complains about something not working in IE and if we have the time or think it's important enough.
  - warfangle 13y ago
    IE11 has touch events, they're just a different api /than everyone else/.
  - Piskvorrr 13y ago
    I have come to terms with this - since most of the compatibility issues can be papered over nowadays, and there are viable alternatives - all I was hoping for was "write and debug once, give it a quick look in A-grade browsers, fix minor quirks", without the usual "...and then spend double the time fixing IE's idiosyncrasies."
  - strmpnk 13y ago
    Many of these points are partial truths or at least not as damning as it might seem. IE has had long gaps in the past because of IE being tied to larger updates and many people having invested in old technology depending on them changing that slowly to allow time to change. The IE team at MicroSoft is clear that they intend to do more regular releases and push updates out automatically. While it won't be monthly like other vendors, it's certainly a huge change from where it was. Software still installs toolbars on Chrome too. I recently tried Windows again for the first time in about 13 years and I'll tell you that I was caught off guard. Toolbars ended up in Chrome AND IE. Not sure if this is a browser problem as much as a software installation problem. Wish I would have learned about Chocolately earlier. Open source isn't something that makes the browser better at being a browser. It's possibly important in other aspects but you should be complaining about other browsers then. Many include lots of proprietary code on top of open engines like WebKit (i.e. Safari is really not all that open source) and then custom engines like Opera mobile. WebRTC isn't even half baked yet. Complaining that they don't release it to millions of devices as a feature is silly. It's great to see browsers experiment with new APIs that become standards... which leads me to: touch events. Touch events were a proprietary outgrowth of the early mobile web. While they've become defacto for mobiles, it's a limiting API that doesn't really help unify the way we handle input at all. MSFT released a vendor extension called pointer events which is a much better API that has now been proposed as a standard. It handles touch, mouse pointers, pen digitizers, and has space to interpret more kinds of devices. Much better than where touch events left us. It's sad that more developers don't demand this unified API either since it makes it far easier to implement cross-input-device friendly content. I haven't spent much time with the IE developer tools but it seems that MicroSoft now provides free VMs that can be installed to run IE for development (http://www.modern.ie/en-us/virtualization-tools http://www.modern.ie/en-us/virtualization-tools) and their developer tools seem to have been improved (most people now just complain they want chrome's developer tools everywhere). So what is left is that I see people either stuck in the past or thinking that this whole thing is IE vs everyone else. IE's got the same problems as many other browsers. We just pick our check list with bias by telling all browser vendors they should just become Chrome. What's the point in an "open" ecosystem if people just demand we all do things exactly one way defined largely by one vendor which happens to develop these "standards" as proprietary extensions just like IE has for all sorts of things (XHR anyone?). >_<
judah 13y ago
I'm running IE 11 here and couldn't get it to crash, despite clearing the forms, focusing one of the text boxes, and beginning to enter data.
- dahjelle 13y ago
  That's interesting. It crashes regularly for me. What version of IE are you running? I'm on 11.0.9600.16476 on Windows 7.
  - Yuioup 13y ago
    Nope. No crashes for me either. I'm also running 11.0.9600.16476
  - be5invis 13y ago
    No crush, I tried everything I can imagine, including editing these controls, performing drag-drop but nothing strange happens. ver 11.0.9600.16476 update 11.0.2 screenshot: http://ww3.sinaimg.cn/large/798f7769gw1eceujrxg30j20bf09c0tf.jpg http://ww3.sinaimg.cn/large/798f7769gw1eceujrxg30j20bf09c0tf...
    - dahjelle 13y ago
      Wow…same version I'm running, and on the same Windows version, but I'm regularly getting the crash. You don't suppose it has something to do with the system language or something? What other different factors could there be?
      - be5invis 13y ago
        Windows 7 x86 or x64? What plugins have you installed? I'm using Simplified Chiense and I cannot reproduce this bug.
        dahjelle 13y ago
        The only plugins I have enabled are Flash and Adobe Reader. All others—Dynatrace AJAX, Java, Messenger Companion, Windows Live ID, Blog This in Windows Live Writer—are disabled. I should mention I'm running in a VirtualBox VM, though I've seen this on a co-workers box running Windows direct on hardware.
be5invis 13y ago
Well, I tried this in IE11 on Windows 7 x64, all three buttons works. IE11 still works. screenshot: http://ww4.sinaimg.cn/large/798f7769gw1eceuea9cwhj211i0ox10b.jpg http://ww4.sinaimg.cn/large/798f7769gw1eceuea9cwhj211i0ox10b...
- dahjelle 13y ago
  The crash would usually happen after the alert box in your code. Typically after one clicked in one of the input boxes and started putting in more data.
  - be5invis 13y ago
    Nope, I tried to modify these fields and clicked the button more than once, there is still no crush. BTW, what are the plugins you've installed in IE? What's the OS version? Performing more information will help everyone to find the bug.
    - dahjelle 13y ago
      Windows 7 Home Premium. 64-bit. I have the dynaTrace AJAX tool installed, though disabled, Java installed but disabled, the Microsoft Messenger Companion installed but disabled, and the Adobe Reader and Flash plug-ins installed and enabled. I reset all IE settings to default, as well. I am running in a VirtualBox virtual machine, though I've reproduced this on non-virtual machines, as well. What else is useful?
      - be5invis 13y ago
        It's too weird. I'm on Windows 7 Ultimate, 64 bit version, I've tried everything I could imagine about these textboxes, but still no crush. Two of my friends tried on Windows 8.1 Pro x64, still no crush.
        dahjelle 13y ago
        Yeah, it's like the crash is depending on something other than Windows version or IE version, but I don't have any idea what. One commonality seemed to be Windows 7 Home Premium SP1, but I see someone else was using Windows 8 and reproduced it. Hmm…
izietto 13y ago
It doesn't work here :-( Win 8.1, IE 11.0.9431.228
- be5invis 13y ago
  So it is a bug in earlier version? or a Windows 8.1 specific bug? BTW, what are the plugins you installed in IE11?
  - izietto 13y ago
    Win 8.1 Pro, no plugins
- dahjelle 13y ago
  Reports of no crash are actually more interesting to me than the crash at the moment…maybe I can protect our customers. Are you running Windows 7 or 8? Any add-ons?
  - izietto 13y ago
    Win 8.1 Pro, no plugins
  - c0n5pir4cy 13y ago
    I'm running on Windows 7 (x86_64) with IE 11.0.9431.0, No addons at all and there are no crashes. DxDiag: http://pastebin.com/M0msHVh3 http://pastebin.com/M0msHVh3
adrianlmm 13y ago
It didn't crash for me.
nticompass 13y ago
Tried this and it crashed for me on IE 11.0.9600.16476 (Update Versions: 11.0.2) on Windows 7. Screenshot: http://i.imgur.com/oSi1rlL.png http://i.imgur.com/oSi1rlL.png Steps: - Filled in all fields - Clicked 1st clear button - Clicked in 1st field - Tried to type something
- be5invis 13y ago
  x86 or x64? -- update -- I tried the identical reproduction process and IE11 still working.
  - nticompass 13y ago
    Windows 7 x64 (Home Premium SP1)
    - be5invis 13y ago
      On a real machine OR inside a VM?
      - nticompass 13y ago
        This is on my actual machine, not a VM.
ignu 13y ago
personally, i think it's adorable that microsoft keeps trying to make a web browser.
- at-fates-hands 13y ago
  It's also frustrating as hell that they finally improved the dev tools and then removed all the browser and document modes. Pretty typical though for them. One step forward, three steps back.
  - nticompass 13y ago
    Noting will ever pull me away from Chrome's DevTools! Not IE, not even Firebug.
- ecaron 13y ago
  I feel the same with Apple's Safari. If you're making a browser and its platform specific, the internet would be a better place if you'd put it out to pasture.
  - actsasbuffoon 13y ago
    To the best of my knowledge Safari is available for OS X, Windows, and iOS. I used to use it on Windows because I liked the font rendering more than Chrome, Firefox, Opera, or IE.
    - nticompass 13y ago
      Safari for Windows was discontinued after version 5.1.7.
nticompass 13y ago
In case anyone is wondering, it doesn't crash in IE 8! :-D
dahjelle 13y ago
I was also able to reproduce this on all of the IE 11 instances on http://browserstack.com http://browserstack.com: Windows 8.1 desktop and metro and Windows 7. I did notice that the crash very occasionally didn't happen the first time, but did, perhaps, the second.
swehner 13y ago
This sounds very much like the bug at http://connect.microsoft.com/IE/feedback/details/808033/ie11-two-reproducible-crashes-on-assigning-the-value-of-an-input-element-with-javascript http://connect.microsoft.com/IE/feedback/details/808033/ie11... The (surprising) solution is to first assign a space character, then the empty string. So (I'm guessing), in that http://jsfiddle.net/dahjelle/zVjfY/ http://jsfiddle.net/dahjelle/zVjfY/ code, change field.value = clearValue; to field.value = ' '; field.value = clearValue;
- dahjelle 13y ago
  Fascinating! Yes, indeed, that's a valid workaround! Not exactly pretty, still, but better that that weird setTimeout mess. Thanks for the pointer!

27 points by dahjelle 13y ago

We ran into this in out application the other day, and it's a surprisingly "normal" thing to do to result in a hard crash of a browser. I'm especially curious if anyone knows: 1. Is there any hope of this being fixed in the near-term? The MS bug report didn't have much information. I'd sure like to avoid implementing the somewhat crazy workaround if I can help it. 2. It seems like this ought to be a pretty widespread problem. Are others seeing it? Are there other workarounds that aren't so ugly?

Piskvorrr 13y ago

Well, shit. And for a few short years, it seemed that IE has outgrown its monstrous reputation it had rightfully acquired in the 00s; nope, still the usual "spend enormous time catering to my quirks" IE. This makes me sad.

dak1 13y ago
There's definitely still some weird IE bugs, although they're more (but not exclusively) on the JavaScript side now rather than CSS. For example, if you have a form without a submit button in IE 10, and a `<button>` element anywhere else on the page, IE will treat the <button> as the submit and "click" it for you rather than submit the form. If you don't have a `<button>` element though it will submit the form as expected.
- riquito 13y ago
  I think this is a long time bug, not IE10 specific.
- dspillett 13y ago
  There are various inconsistencies between browsers (including between version of IE) when you do not explicitly set the type attribute of a button tag. Some will default to it being a submit button and some will default it to being a "button" button. In the instances where we hit this problem making sure to specify a type seems to make things more consistent.
EarthLaunch 13y ago
With each release of IE since IE7, there has been some kind of marketing push saying "THIS version is the one that is modern and totally standards-compliant, really", and a bunch of people repeat that. Then it turns out to be buggy. Then the cycle repeats. No one should be surprised at IE11's flaws. I believe IE's quality has been fairly consistent over the years. IE6 had a monstrous reputation mainly because it was outdated and widespread for so long.
- Piskvorrr 13y ago
  I have passionately hated IE6, 7, and 8; IE9 has managed to reduce this to a resigned "meh, good enough, what took you so long?" (which _was_ a significant change to the better). I was hoping that IE was finally shaping up to be an A-grade browser. Oh well.
belluchan 13y ago
It hasn't outgrown it's monstrous reputation and it will probably never. IE has long gaps between updates so it will always quickly fall behind. Software can still install toolbars and change your default search engine. IE is not open source. IE 11 does not implement X standards for business reasons, where X is WebRTC, some missing CSS thing, touch events, etc. You can't test for IE except on Windows. IE's developer tools are terrible. IE is used by people bad with computers and corporations with bad IT departments. For me to care about IE, it would: have to be available on Mac OS X. have to have bigger market share in mobile just have more people using it in general (because frankly it's not used much by any of the people we care about). have much, much better development tools Our development cycle is to develop in Chrome Canary, and proactively test and fix for Firefox. We don't test in IE but fix IE issues when someone complains about something not working in IE and if we have the time or think it's important enough.
- warfangle 13y ago
  IE11 has touch events, they're just a different api /than everyone else/.
- Piskvorrr 13y ago
  I have come to terms with this - since most of the compatibility issues can be papered over nowadays, and there are viable alternatives - all I was hoping for was "write and debug once, give it a quick look in A-grade browsers, fix minor quirks", without the usual "...and then spend double the time fixing IE's idiosyncrasies."
- strmpnk 13y ago
  Many of these points are partial truths or at least not as damning as it might seem. IE has had long gaps in the past because of IE being tied to larger updates and many people having invested in old technology depending on them changing that slowly to allow time to change. The IE team at MicroSoft is clear that they intend to do more regular releases and push updates out automatically. While it won't be monthly like other vendors, it's certainly a huge change from where it was. Software still installs toolbars on Chrome too. I recently tried Windows again for the first time in about 13 years and I'll tell you that I was caught off guard. Toolbars ended up in Chrome AND IE. Not sure if this is a browser problem as much as a software installation problem. Wish I would have learned about Chocolately earlier. Open source isn't something that makes the browser better at being a browser. It's possibly important in other aspects but you should be complaining about other browsers then. Many include lots of proprietary code on top of open engines like WebKit (i.e. Safari is really not all that open source) and then custom engines like Opera mobile. WebRTC isn't even half baked yet. Complaining that they don't release it to millions of devices as a feature is silly. It's great to see browsers experiment with new APIs that become standards... which leads me to: touch events. Touch events were a proprietary outgrowth of the early mobile web. While they've become defacto for mobiles, it's a limiting API that doesn't really help unify the way we handle input at all. MSFT released a vendor extension called pointer events which is a much better API that has now been proposed as a standard. It handles touch, mouse pointers, pen digitizers, and has space to interpret more kinds of devices. Much better than where touch events left us. It's sad that more developers don't demand this unified API either since it makes it far easier to implement cross-input-device friendly content. I haven't spent much time with the IE developer tools but it seems that MicroSoft now provides free VMs that can be installed to run IE for development (http://www.modern.ie/en-us/virtualization-tools http://www.modern.ie/en-us/virtualization-tools) and their developer tools seem to have been improved (most people now just complain they want chrome's developer tools everywhere). So what is left is that I see people either stuck in the past or thinking that this whole thing is IE vs everyone else. IE's got the same problems as many other browsers. We just pick our check list with bias by telling all browser vendors they should just become Chrome. What's the point in an "open" ecosystem if people just demand we all do things exactly one way defined largely by one vendor which happens to develop these "standards" as proprietary extensions just like IE has for all sorts of things (XHR anyone?). >_<

judah 13y ago

I'm running IE 11 here and couldn't get it to crash, despite clearing the forms, focusing one of the text boxes, and beginning to enter data.

dahjelle 13y ago
That's interesting. It crashes regularly for me. What version of IE are you running? I'm on 11.0.9600.16476 on Windows 7.
- Yuioup 13y ago
  Nope. No crashes for me either. I'm also running 11.0.9600.16476
- be5invis 13y ago
  No crush, I tried everything I can imagine, including editing these controls, performing drag-drop but nothing strange happens. ver 11.0.9600.16476 update 11.0.2 screenshot: http://ww3.sinaimg.cn/large/798f7769gw1eceujrxg30j20bf09c0tf.jpg http://ww3.sinaimg.cn/large/798f7769gw1eceujrxg30j20bf09c0tf...
  - dahjelle 13y ago
    Wow…same version I'm running, and on the same Windows version, but I'm regularly getting the crash. You don't suppose it has something to do with the system language or something? What other different factors could there be?
    - be5invis 13y ago
      Windows 7 x86 or x64? What plugins have you installed? I'm using Simplified Chiense and I cannot reproduce this bug.
      - dahjelle 13y ago
        The only plugins I have enabled are Flash and Adobe Reader. All others—Dynatrace AJAX, Java, Messenger Companion, Windows Live ID, Blog This in Windows Live Writer—are disabled. I should mention I'm running in a VirtualBox VM, though I've seen this on a co-workers box running Windows direct on hardware.

be5invis 13y ago

Well, I tried this in IE11 on Windows 7 x64, all three buttons works. IE11 still works. screenshot: http://ww4.sinaimg.cn/large/798f7769gw1eceuea9cwhj211i0ox10b.jpg http://ww4.sinaimg.cn/large/798f7769gw1eceuea9cwhj211i0ox10b...

dahjelle 13y ago
The crash would usually happen after the alert box in your code. Typically after one clicked in one of the input boxes and started putting in more data.
- be5invis 13y ago
  Nope, I tried to modify these fields and clicked the button more than once, there is still no crush. BTW, what are the plugins you've installed in IE? What's the OS version? Performing more information will help everyone to find the bug.
  - dahjelle 13y ago
    Windows 7 Home Premium. 64-bit. I have the dynaTrace AJAX tool installed, though disabled, Java installed but disabled, the Microsoft Messenger Companion installed but disabled, and the Adobe Reader and Flash plug-ins installed and enabled. I reset all IE settings to default, as well. I am running in a VirtualBox virtual machine, though I've reproduced this on non-virtual machines, as well. What else is useful?
    - be5invis 13y ago
      It's too weird. I'm on Windows 7 Ultimate, 64 bit version, I've tried everything I could imagine about these textboxes, but still no crush. Two of my friends tried on Windows 8.1 Pro x64, still no crush.
      - dahjelle 13y ago
        Yeah, it's like the crash is depending on something other than Windows version or IE version, but I don't have any idea what. One commonality seemed to be Windows 7 Home Premium SP1, but I see someone else was using Windows 8 and reproduced it. Hmm…

izietto 13y ago

It doesn't work here :-( Win 8.1, IE 11.0.9431.228

be5invis 13y ago
So it is a bug in earlier version? or a Windows 8.1 specific bug? BTW, what are the plugins you installed in IE11?
- izietto 13y ago
  Win 8.1 Pro, no plugins
dahjelle 13y ago
Reports of no crash are actually more interesting to me than the crash at the moment…maybe I can protect our customers. Are you running Windows 7 or 8? Any add-ons?
- izietto 13y ago
  Win 8.1 Pro, no plugins
- c0n5pir4cy 13y ago
  I'm running on Windows 7 (x86_64) with IE 11.0.9431.0, No addons at all and there are no crashes. DxDiag: http://pastebin.com/M0msHVh3 http://pastebin.com/M0msHVh3

adrianlmm 13y ago

It didn't crash for me.

nticompass 13y ago

Tried this and it crashed for me on IE 11.0.9600.16476 (Update Versions: 11.0.2) on Windows 7. Screenshot: http://i.imgur.com/oSi1rlL.png http://i.imgur.com/oSi1rlL.png Steps: - Filled in all fields - Clicked 1st clear button - Clicked in 1st field - Tried to type something

be5invis 13y ago
x86 or x64? -- update -- I tried the identical reproduction process and IE11 still working.
- nticompass 13y ago
  Windows 7 x64 (Home Premium SP1)
  - be5invis 13y ago
    On a real machine OR inside a VM?
    - nticompass 13y ago
      This is on my actual machine, not a VM.

ignu 13y ago

personally, i think it's adorable that microsoft keeps trying to make a web browser.

at-fates-hands 13y ago
It's also frustrating as hell that they finally improved the dev tools and then removed all the browser and document modes. Pretty typical though for them. One step forward, three steps back.
- nticompass 13y ago
  Noting will ever pull me away from Chrome's DevTools! Not IE, not even Firebug.
ecaron 13y ago
I feel the same with Apple's Safari. If you're making a browser and its platform specific, the internet would be a better place if you'd put it out to pasture.
- actsasbuffoon 13y ago
  To the best of my knowledge Safari is available for OS X, Windows, and iOS. I used to use it on Windows because I liked the font rendering more than Chrome, Firefox, Opera, or IE.
  - nticompass 13y ago
    Safari for Windows was discontinued after version 5.1.7.

nticompass 13y ago

In case anyone is wondering, it doesn't crash in IE 8! :-D

dahjelle 13y ago

I was also able to reproduce this on all of the IE 11 instances on http://browserstack.com http://browserstack.com: Windows 8.1 desktop and metro and Windows 7. I did notice that the crash very occasionally didn't happen the first time, but did, perhaps, the second.

swehner 13y ago

This sounds very much like the bug at http://connect.microsoft.com/IE/feedback/details/808033/ie11-two-reproducible-crashes-on-assigning-the-value-of-an-input-element-with-javascript http://connect.microsoft.com/IE/feedback/details/808033/ie11... The (surprising) solution is to first assign a space character, then the empty string. So (I'm guessing), in that http://jsfiddle.net/dahjelle/zVjfY/ http://jsfiddle.net/dahjelle/zVjfY/ code, change field.value = clearValue; to field.value = ' '; field.value = clearValue;

dahjelle 13y ago
Fascinating! Yes, indeed, that's a valid workaround! Not exactly pretty, still, but better that that weird setTimeout mess. Thanks for the pointer!