IE August Cumulative Security Update Now Available

re: IE August Cumulative Security Update Now Available

tony — Wed, 18 Aug 2010 11:23:32 GMT

There is a lot of discussion about the innerHTML bugs in IE above here (and across the Internet) but it has been very quiet from Microsoft?!

Should we take silence as a good sign that you are busy working on the fixes for this? or that you are hoping to try and sweep this under the rug as soon as it quiets back down a bit?

re: IE August Cumulative Security Update Now Available

Klaus — Mon, 16 Aug 2010 16:48:51 GMT

just for the record the msdn documentation on innerHTML does not mention the "select" element in its list of "read-only" elements that innerHTML does not work on yet does include it in the list of elements that support it (at the end of the page)

msdn.microsoft.com/.../ms533897.aspx

just wondering - by any chance does it work on the "optgroup" element?

as for the argument on whether this is a bug or not (it most certainly is - those barking that the documentation states it isn't a bug are discredited with the above discrepancy and the blog post that does indicate that there is a an underlying bug in the IE Trident DOM parser).... but while we are at it can we bring up the return value? yikes! that is not the innerHTML that was set and content that was set in a valid well-formed format is returned in a mish mash of invalid tags regardless of the doctype specified.

If we are voting - I don't mind the getter not being fixed but it is about time that the setter was fixed it has been broken long enough thanks.

re: IE August Cumulative Security Update Now Available

Tired of trolls — Mon, 16 Aug 2010 14:53:18 GMT

"notaspade" -- yes, this is only one of many cases where the standards bodies (aka a de-facto cartel of Microsoft's competitors) have copied something out of IE (FavIcons, anyone?) and changed the spec just enough so that the inventor's application doesn't meet the "standard."

Leon -- if you want to whine, go over to Mozilla's bug database and look at how many bugs have NEVER even been looked at. Watch the collective incompetence as there are 8 year old debates about whether or not OnChange should fire when the contents of a SELECT control CHANGE via the keyboard rather than the mouse. And so on. Any non-trivial engineering undertaking (aka virtually all software) has a nearly infinite number of issues. The trick between being a successful, commonly used software product (e.g. IE) vs. a niche product with ardent fans (e.g. Opera) is being smart about which issues you choose to address.

Now, on the other hand-- the lack of a spell-checker in IE? That's just stupid.

re: IE August Cumulative Security Update Now Available

Not a spade — Mon, 16 Aug 2010 14:27:57 GMT

@Spade - check up your specs dude:

dev.w3.org/.../Overview.html

HTML5 has a getter/setter:

interface HTMLElement : Element {

// dynamic markup insertion

attribute DOMString innerHTML;

attribute DOMString outerHTML;

...

}

If IE plans to be HTML5 compatible - it had better get its darn parser bugs sorted out!

IE's implementation (even if it is just as they shipped it) is broken. Claiming crud about "we invented it to only work on some elements" is a load of junk. They wanted it to work on everything but had to limit their implementation due to other bugs in their core DOM parsing engine.

Rather than fix the engine (the obvious choice) they decided to let it slide and make the setter invalid on certain elements (*cough*, *cough*, "readonly")

.innerHTML was a proprietary extension when IE added it but once other vendors incorporated it - completely of course because they don't have the DOM bugs IE has - it became ubiquitous.

Long story short - Microsoft needs to clean up this mess ASAP - otherwise this "universal markup" thing won't fly because IE is holding back the web again.

All this junk about "MSFT invented it to be broken" is garbage.... think about cars... someone had to be first to invent the seatbelt (VOLVO)... later on others copied it... it became standard. If VOLVO starts claiming that they won't install seatbelts in the back seat of cars because they can't find suitable anchor points in their design, no one would accept this (whether they invented it or not).

All you ms-fanboys get off your high horses - you want these bugs fixed as much as we do - occasionally you have to just accept that Microsoft isn't perfect - but they can always fix or improve their software (that's how software works, it evolves)

Lets not fight over who invented it first, lets just get together and get it fixed in IE!

re: IE August Cumulative Security Update Now Available

Spade — Mon, 16 Aug 2010 13:35:33 GMT

I love this! :-)))

...so somebody (Microsoft in this case) invents something new, which is then copied by other browser vendors. It is no standard, but an extension to a standard, and the implementation of the other browser vendors is buggy, because it is not EXACTLY the same, as the implementation of the original inventor. Now the fanboys of the minority browsers want the ORIGINAL inventor to change their invention after the buggy fashion of the minority browsers. You've really got to love this! :-)))

Right out of the textbook of the fundamentalist anti-microsoft taliban!

Ace of Spades

re: IE August Cumulative Security Update Now Available

steve — Mon, 16 Aug 2010 13:02:18 GMT

Ha ha ha ha ha! very nice @hAl - claiming they are not bugs because IE's original implementation was broken in several areas is a very, very weak argument.

As a developer you see this access property called "inner" "HTML" that gives you access to get/set the HTML on elements, all elements... it is only when you read the fine print on Microsoft's dev pages that you see they've conveniently added getters for everything, but setters only on most elements calling the remaining "read-only" due to internal bugs.

Lets call a spade a spade - it is a bug, it is ugly, and it needs fixing.

re: IE August Cumulative Security Update Now Available

hAl — Mon, 16 Aug 2010 11:55:21 GMT

@Leon

InnerHTML is not part of any webstandard.

InnnerHTML is actually a proprietary Internet Explorer extension of Javascript that some other browser builders have then embraced and further extented.

Unlike W3C DOM which is actually a W3C webstandard and which can achieve the same results as InnerHTML (though not always as easy).

Thus there is no requirement for IE9 to support innerHTML on any of the elements you suggest.

You are asking for IE to use other browsers proprietary extensions on IE's own proprietary extensions. That is just ridiculous.

Those are thus not bugs anyways. It is behaving as Microsoft actually created it.

re: IE August Cumulative Security Update Now Available

Leon — Mon, 16 Aug 2010 11:44:13 GMT

@hAI I'm not sure what bug site you want me to point to but these are all very easy to test and all very easy to reproduce by anyone.

Create a Table or a Select element and try to set the .innerHTML to add table rows or select options - it just fails (and wipes out any content you had, even if you try to concatinate with "+=".

Google for IE innerhtml bugs points to the following:

IE fails to set the innerHTML on the SELECT object

support.microsoft.com/.../276228

Filed in 2003 (7 years ago)

IE Pre/Textarea whitespace/linebreak issues:

www.quirksmode.org/.../innerhtml_and_t.html

IE Table (and related) element bugs:

webbugtrack.blogspot.com/.../bug-210-no-innerhtml-support-on-tables.html

that last report even includes a link to Eric Vasilik's old blog where he (@MSFT at the time) indicated some responsibility for the bug (due to building a sub-par HTML parser) whereby the bugs have existed since 1996!!!!! 14 years ago! - just how long does it take to get a fix for this?

As I stated, twice... THIS IS NOT NEWS! these are well known major bugs that have not been fixed.

All the msfanboys can whine all they want that I should really file these in connect but I assure you they were in Connect for the IE7 beta, ditto for IE8, ditto for IE9 - filing the bug doesn't fix it - only MSFT can fix it - and we've been waiting almost a decade now - I think it is about time for an ETA for the fix.

re: IE August Cumulative Security Update Now Available

hAl — Mon, 16 Aug 2010 11:22:59 GMT

@Leon

Trashing some bug on an arbitrary bugsite and not even have the decency to palce a link to those bugs on the site makes the critisism opf little value. I have been on several of those site in the past finding many issues with those so called bugtests.

If anyone caliming issues is not wiliing to put up any evidence of those issues you claim I have little faith in the issues really exisiting or being of any signifcance because they might test extremly rare occurence you will never find in the real world.

re: IE August Cumulative Security Update Now Available

Leon — Mon, 16 Aug 2010 11:06:06 GMT

@Mmmhmmm - I'm sorry we're you asleep for the past decade? it is common knowledge to every web developer that IE does not support setting .innerHTML on many elements.

Internet Explorer 6, 7, 8, & 9 all fail to set the .innerHTML on the following elements:

HTML element

TABLE element

TR element

TBODY element

THEAD element

TFOOT element

SELECT element

PRE element (where the content contains linebreaks)

any EMPTY element with overflow set to auto (where the content contains breaks)

On the contrary, all other browsers have had no issue implementing this correctly - it works fine in Chrome, Firefox, Safari, Konqueror, SeaMonkey, Opera, Flock, Arora, Camino, K-Meleon, OmniWeb, iCab, Galeon, Epiphany, Chromium... even deprecated versions of Netscape handle it fine!

So am I ranting? you bet I am! - and as noted I have no intention of filing these 9 bugs unless MSFT is going to step up to the plate and commit to fixing them! (they failed to do so in the last 9 years that they have been known and tracked)