bug 593 - IE leaks all your windows mouse movements

Issue: #593
Affects: IE6, IE7, IE8, IE9, IE10

Internet Explorer leaks all your mouse movements regardless where in Windows they occur.

There's a lot of discussion about this bug at the moment as any browser bug that gives a website access to any information outside of the browser sandbox is considered a security bug.

In this case IE's classic legacy single global event model has an issue whereby the mouse movements in Windows are fully available to Internet Explorer even if they originate outside of the browser viewport, and even the browser chrome, even when IE doesn't have the active focus... even on a 2nd/3rd screen if you have a multiple screen desktop!

At the same time certain specific keystrokes are also leaked... the SHIFT, CTRL & ALT keys.

Full details of the bug specifics can be found over on the Spider.io blog: http://spider.io/blog/2012/12/internet-explorer-data-leakage/ and there is even a demo http://iedataleak.spider.io/demo

Microsoft has responded to this bug on their IE Blog IE Information leak and Security Issue however they are not taking the issue very seriously... rather trying to dispel the severity of the issue and imply that the bug report is only the result of an ad network that is fearing that this issue is affecting their competitive ability.

We'd really prefer if the politics of business stayed completely out of this discussion.  The bug has been responsibly reported, vastly ignored by Microsoft and then ultimately disclosed to the developer public when talks with Microsoft were not moving fast enough.

So lets get hypothetical - just what could one do with this info?  Well we can use JavaScript to determine the exact version of Internet Explorer, we can also determine the desktop extents and browser window extents.

We can fairly accurately track movements to anywhere within the browser chrome to see if the user goes to click on the zoom controls or the JavaScript error icon in the bottom left...

We could capture events near the "Red X" of the browser window to block users from being able to easily close their browser... know when they are going to their address bar or search bar... the desktop taskbar/start button...

Any combo of ALT key followed by navigation to the top left portion of the IE chrome would indicate access to some part of the IE menu... followed by fairly precise movements would expose which menu options were accessed...

Can you think of other potential things that could be tracked? Let us know in the comments.

Meanwhile lets hope that Microsoft really is taking this seriously now that it has gone public and that a priority patch for all versions of IE is available before Christmas.

Known Workarounds: None.

Related Issues: None.
Bug/Site Feedback | Submit a bug

bug 234 - showModalDialog Array returnValue now fails

Issue: #234
Affects: IE6, IE7, IE8

We haven't discovered if this bug is exclusive to VBScript or if it affects JavaScript too (but feel free to update us in the comments if you know).

If you downloaded the latest IE Cumulative Security Update for October 2009 security patch, which "fixed" Microsoft Knowledge Base Article 974455 then you may have noticed that the showModalDialog documentation indicates that the window.returnValue accepts an Array.

However after updating KB974455, there was an undocumented change that now Array return values are no longer allowed.

So what can you do if you depend on this non-standard dialog? Well, the workaround is ugly but there hasn't been confirmation from Microsoft that this bug was introduced - nor that a fix is on the way.

Known Workarounds: One. Use something other than an Array and handle the return value accordingly.

Example Workaround Code:

On the Popup window:

<script type="text/vbscript">
  //was
  window.returnValue = arrayValue;

  //now use
  arrString = Join(arrayValue, ";");
  window.returnValue = arrString;
</script>

On the Calling window (e.g. Opener):

<script type="text/vbscript">
  //was
  retArray = window.showModalDialog( ... );

  //now use
  tempRetArray = window.showModalDialog( ... );
  retArray = Split(tempRetArray, ";");
</script>

Related Issues: None.



Bug/Site Feedback |
Submit a bug

bug 231 - noscript elements render when script enabled in IE8 Standards Mode

Issue: #231
Affects: IE8 (Standards Mode), IE9 PP1, IE9 PP2, IE9 PP3, IE9 PP4, IE9 PP6

The <noscript> tag serves 1 basic purpose and that is to provide content when scripting is turned off in the browser.

Years ago the main purpose was to provide alternative content so that your page still worked in browsers without script however these days due to better popup blocking and more interactive content scripting is typically turned on.

Thus the main use of the noscript tag today is to inform the user that JavaScript is turned off and that things won't work until it is turned back on.

[Fake] You need to turn on JavaScript to use the uber cool features on this page. [Fake]

However warnings like this would seem quite out of place when JavaScript is turned on so they are not rendered. Well except that IE8 (Standards Mode) does render the noscript tag container when JavaScript is turned on. This is a regression bug from IE6/7.

Example:

If you are viewing this page in IE8 Standards mode (you'll need to use the IE developer tools [F12] since blogger forces IE7 rendering mode) you will see the outline of noscript tags even when JavaScript is enabled.

Known Workarounds: One. Setting the noscript tag to be display:inline; vs display:block seems to make the container disappear.

Related Issues: None.

Bug/Site Feedback |
Submit a bug

bug 444 - IE8 printing issues in standards mode

Issue: #444
Affects: IE8

MSIE Feedback ID: 431489

IE8 has a new bug with printing. When you change a checkbox or radio button on a page either by clicking it or calling some JavaScript function to toggle it - it looks like it changed but if you try to print it, it won't print in the new state.

In fact it won't even show up correctly in the print preview window!

According to sources at Microsoft there is no intention of fixing this until IE9!

The best part is that this ONLY occurs in Standards Mode. If you render your pages in the Legacy IE7 Mode the checkboxes and radio buttons print (and preview) properly.

Known Workarounds: None.

Related Issues: None.


Bug/Site Feedback |
Submit a bug

Microsoft releases Internet Explorer 8 RTM

Microsoft releases Internet Explorer 8 RTM

It has been in development for some time now and had a fairly thorough public test cycle with (Beta 1, Beta 2, PR 1, & RC1) but without a much desired RC2... on March 19th the IE8 RTM was released for download.

The good news is that many of the bugs that plagued IE6, and IE7 have now finally been fixed. There are of course some bug fixes that didn't make it into the final, and those that are Broken By Design.

As developers we're very excited to get our hands on a new Modern Browser however with bringing in the new we need to look at dragging out the old. Yes IE6, we are talking about you! IE6 is now 2,763 days old (and counting!) (over 7.5 years old!). Supporting 3 versions of a particular browser is a lot to swallow in terms of development effort and designing workarounds to bugs and so don't be surprised in the slightest as many sites will start officially dropping support for IE6 (I Dropped IE6, Do Not Want IE6, IE Death March 2009, IE6 Update,even Steve Ballmer says to Drop IE6).

Of course there is a balance between desire to drop IE6 and supporting customers/users that are still using it (or are forced to by I.T. Admins that won't upgrade)

So tell us your story... are you dropping IE6 support any time soon? Have you downloaded IE8? What do you think of it? Find a bug? or better yet is an old one fixed?

Congrats to the IE Team for improving Internet Explorer once again. There's still lots of work to do but it sure has come a long way in the past 3 years!


Bug/Site Feedback |
Submit a bug

bug 521 - IE8 won't render in Standards Mode.... if rendered in a Web Slice

Issue: #521
Affects: IE8
Status: Microsoft has confirmed this will NOT be fixed in IE8 RTM

With much rejoice Web Developers everywhere cheered when Microsoft announced that IE8 would render in its best effort at Standards Mode by default when IE8 ships. This is still true, with a few exceptions.

1.) Intranet (e.g. internal network sites) will still render in IE7 mode by default [ITNOBC*]
2.) When you add one of the nifty IE8 Web Slices (e.g. brand spanking new to IE8, never ever supported in IE6 or IE7 before)... even when you serve up 100% valid Standards Based HTML content... IE8 will ALWAYS, Without exception... render it like IE7.

So its another case of 2 steps forward, 1 step back. You can update/maintain your pages to ensure IE8 renders them well just like they appear in Firefox, Safari, Chrome and Opera, etc. but if you want to add one of these Web Slice (think mini-graphical RSS) things to your page, you'd better make sure that that content renders just as well in IE7 mode.

Don't bother with Conditional Comments looking for IE7 though, because the Web Slice "engine" will report itself as IE8.

Developers find it very puzzling that new features are broken right out-of-the-gate when so much focus for IE8 was on fixing the mistakes of the past. Oh well.

Known Workarounds: None.

Related Issues: None.

[ITNOBC]: "In The Name Of Backward Compatibility"

Bug/Site Feedback |
Submit a bug

bug 155 - IE8 InPrivate mode destroys your sites sessions

Issue: #155
Affects: IE8 RC1

Internet Explorer 8 has a feature called InPrivate, a.k.a. "porn mode". in which the browser will automatically "lose" all your browsing information when you close the browser so that no other user, coworker, family member, or significant other can see where you've been. No history, no cookies, no cache, no search keywords, nada.

The feature isn't only for secretly viewing porn but also for checking private email on a shared computer, buying someone a secret gift, quietly searching for another career, or posting updates on imManEnoughToCollectChiPets.com without anyone knowing.

However the key to the success of this feature is ensuring that every last minuscule detail is removed - otherwise the feature is useless.

In the first previews of this feature, some traces were left behind so Microsoft worked hard to clean up any lose ends but they went a bit too far.

When you open an InPrivate window to check say your web based email, there's a good chance that you'll open one of those emails or internal links in another tab (that is the beauty of having tabs) however when you open the new tab... it strips every little bit of info about where you've been away - including the session information that confirmed you were a valid, logged in user!

So all of a sudden on the new tab - you are no longer logged in! In fact if you go back to the first tab and try to click a link or refresh - you're logged out there too!

We're sure they plan to fix this before the final IE8 RTM release... we'll keep you posted with updates when we see that this is fixed.

Example:

1.) Go to about:tabs in IE8 RC1
2.) Click the link to open an InPrivate browsing session
3.) Go to Gmail or a similar online web site that requires you to log in
4.) Browse around, all is well
5.) Now open some links in new tabs (middle-click the links)
6.) Are you still logged in? or did you get dropped?
7.) After being dropped out of your session, go back to the first tab and browse around
8.) Now you are dropped out of your session in all tabs - woops!

Known Workarounds: None.

Related Issues: None.


Bug/Site Feedback |
Submit a bug

bug 519 - IE8 InPrivate/Windows Media Player Fail - OS integration issues

Issue: #519
Affects: IE8 (IE6, IE7 also fail the basic privacy issue disclosed below)

So, you think that IE8's InPrivate will cover your tracks when you surf... *cough*, *cough* questionable video content on the Internet?

Think again! do you remember a battle between the D.O.J. (Department Of Justice) and Microsoft over Internet Explorer being "part" of the Operating System and therefore they couldn't remove it to make a even playing field for other Web Browsers?

Well IE is tied to the OS... even if you aren't using IE! because the IE "favorites" and "history" are tied to the OS (not just IE).

So if you went and downloaded/watched some videos in say... Firefox... that opened up in Windows Media Player.

Then in Firefox you clicked the "Clear Private Data" link to remove all traces in Firefox.

Now open IE... and view IE8's History... what on earth?! the videos you watched from Firefox/Windows Media Player now show up in your IE History!

So who gets credit for the bug? Is it Firefox? likely not because it erased all data it stored. So its between Windows Media Player and IE8. In Windows Media Player's options... Privacy Tab... the History checkbox is unchecked - therefore requesting that URL/file history NOT be saved.

So where is the bug? Is Windows Media Player storing history when you told it not to? or is Internet Explorer tracking its own copy of your OS history without consent? or is Windows itself somehow to blame?

Either way Microsoft has a bug to fix. No history means No history.

It should be noted that surfing in IE8's InPrivate, downloading videos, and closing the InPrivate session does seem to clear the history.

Note: This bug was discovered on Windows XP SP3, IE8 RC1 and Windows Media Player 10. (it may not occur in other setups)
Update: This bug affects all versions of IE and Windows (Windows7/IE8 combo not tested yet - please send in a comment if you can confirm that this bug still exists/does not still exist in Windows 7)

Known Workarounds: None.

Related Issues: None.


Bug/Site Feedback |
Submit a bug

Fixed bugs in IE8

Fixed bugs in IE8:

We've started to aggressively mark those bugs that are fixed in IE8 as such. The final version of IE8 has yet to be released but there is a presumption that a bug that is fixed in IE8 RC1 will remain fixed for the IE8 RTM release.

However there is a significant catch. When Microsoft fixed most of these bugs, they only fixed them in the "IE8 Standards Mode" which is the new mode that IE renders content in its "best possible, most standards way that it can".

This means that in order to see any of these fixes work, you MUST generate your pages with a valid doctype and the page MUST be somewhere on the Internet, not the Intranet (A point most developers argued against but Microsoft stood firm).

That all said, bugs marked with the "Fixed" tag are bugs that from preliminary testing appear to be working fine in IE8 in IE8 Standards Mode.

With deep regret (ours) there are also bugs that Microsoft has indicated will not be fixed in IE8 RTM, and those have been marked with the "Broken By Design" tag.

IE8 RTM is on the horizon now and the IE Team has indicated that there will not be any more public IE releases before the final (we hope that means there will be another private release, but we aren't getting our hopes up).

If/When time permits, we'll publish a complete list right here so that there is a quick list to check against. Thanks for all the input and bug submissions (for any browser of course) and feedback.

[List will go here]
Fixed:
(bug 101) - buttons render stretched and distorted in IE (WinXP)

(bug 152) - getElementById returns incorrect objects in IE and Opera

(bug 154) - getElementById is NOT case sensitive in IE

(bug 163) - no valign in table cells in IE8

(bug 165) - dynamic pre population fails in IE

(bug 184) - The catch to Try Catch Finally in IE

(bug 190) - fieldsets are broken in IE8

(bug 215) - no hasAttributes() support in IE6, IE7

(bug 217) - getAttribute doesn't always work in IE

(bug 229) - not everything is absolute in IE

(bug 268) - hasAttributes not supported in IE

(bug 293) - can't disable options in IE

(bug 299) - setAttribute "checked" does not work in IE

(bug 329) - Element.setAttribute('style', '...') fails in IE8 Beta 1

(bug 333) - microsoft drops all support for opacity in IE8!

(bug 341) - the button element submits the wrong value in IE

(bug 347) - IE8 Beta 1 - text highlighting background issue

(bug 371) - named anchor links are broken in IE8

(bug 471) - font-weight:600 stretches text in IE



Broken By Design:
Status: Microsoft has confirmed that these bugs will NOT be fixed in IE8 RTM
(bug 109) - JavaScript prompt() in IE - How did this not get fixed in IE7?!

(bug 126) - no W3C DOM Level 2 Event Listeners

(bug 132) - slow checking checkboxes required in IE

(bug 210) - No .innerHTML support on Table, THead, TBody, TFoot, Tr's in IE

(bug 237) - type is a readonly attribute in IE

(bug 256) - DOM nodeType constants are not in IE and Opera

(bug 274) - DOM Methods on Select Lists don't work in IE

(bug 342) - Connecting... in IE7 / IE8 takes F-O-R-E-V-E-R

(bug 411) - getElementsByName doesn't work in IE

(bug 421) - IE fails to pass the HTTP Referer on many navigations

Bug/Site Feedback |
Submit a bug

bug 143 - createTextNode() doesn't work on the style tag in IE

Issue: #143
Affects: IE6, IE7, IE8

Using the DOM to generate elements is ideal, but when you want to generate a style tag, you can't use the DOM methods to populate it in IE.

Example:

<script type="text/javascript">
  var styleTag = document.createElement('style');
  styleTag.appendChild( document.createTextNode('.foo {color:#ff0000;}') );
  var bodyTag = document.getElementsByTagName('body')[0];
  bodyTag.appendChild( styleTag );
</script>

In all browsers except IE, this will append a style element to the page, with the style definition for the "foo" class as the content.

Known Workarounds: One. For IE, we have to divert from the spec., and use the styleTag.styleSheet.cssText property instead.

Example Workaround Code:

<script type="text/javascript">
  var styleTag = document.createElement('style');
  styleTag.styleSheet.cssText = '.foo {color:#ff0000;}';
  var bodyTag = document.getElementsByTagName('body')[0];
  bodyTag.appendChild( styleTag );
</script>

Related Issues: (bug 142).

bug 375 - no window.onresize event in IE8 Beta 2

Issue: #375
Affects: IE8 Beta 2, IE8 PR1, IE8 RC1
MSIE Feedback ID: 410707

MSIE Feedback ID: 390166

MSIE Feedback ID: 377719

MSIE Feedback ID: 364571

Note: There was a partial fix in IE8 RC1 however iframes still do not fire resize events properly.

When IE8 Beta 2 shipped it was a significant improvement over Beta 1 - quite simply by the fact that it was actually usable!

There is however a regression bug (that MS claims is fixed in their internal builds moving towards a Q1,2009 RC1 release) with the window.resize event never, ever firing!

As a result, any attempt to capture this event and execute some JavaScript logic on it will fail. Hopefully this will be fixed in the RC release... but we are wondering... does this mean (bug 104) will also be fixed? or will it behave like IE7 did? or IE6 did?

Known Workarounds: None.

Related Issues: One. (bug 104)

Bug/Site Feedback |
Submit a bug

bug 476 - Slow SVG rendering in IE8

Issue: #476
Affects: IE8

For anyone that has noticed that SVG rendering in IE8 (w/Adobe 3.x plugin) is really slow (like 10 seconds to load a simple image... kind of slow) you'll be glad to hear that there is a solution!

The issue is that IE attempts to load a resource file (script or style) that it can't locate.

Example:

<defs>
  <script xlink:href="/js/nonExistingFile.js"/>
</defs>

To remove the delay that is caused by IE/Adobe Plugin (not sure which is stalling) attempting to find and load your JS / CSS file simply correct your SVG markup to point to only valid resource files.

Known Workarounds: One. Check that you are not pointing to any non-existing resources if you are noticing heavy delays in rendering.

Related Issues: None.

Bug/Site Feedback |
Submit a bug

bug 505 - you can't programatically focus a link in IE unless another link has the focus

Issue: #505
Affects: IE6, IE7, IE8

Here's the scenario: You want to put the current focus on a hyperlink on the page, complete with that dotted border that indicates to the user, that the link has the focus.

Easy enough, right?

Example:

<script type="text/javascript">
  var firstLink = document.getElementsByTagName('a')[0];
  firstLink.focus();
</script>

Well, try it out. In fact, just drop it in the location bar of any other browser as a bookmarklet to verify that it works.

javascript:document.getElementsByTagName('a')[0].focus();

Try the same thing in IE, and you'll notice that the dotted border doesn't show up! Press Tab, and you'll move focus to the next filed, press Shift Tab, and you'll move back, complete with the dotted border. The link does have the focus though... press Enter and you will activate the link.

To see how it should work, press Tab to move between the links on the page. Once you are on a link, complete with the visible dotted border focus, now call .focus() on any other link. Thus it only works in IE, if another link already has the focus, and it was achieved manually.

Known Workarounds: None.

Related Issues: None.


Bug/Site Feedback |
Submit a bug

bug 512 - can't scroll zoomed page in IE8....... wait... maybe...

Issue: #512
Affects: IE8 Beta 2, IE8 PR1, IE8 RC1

Keeping in mind that IE8 is still in Beta there's an issue in IE8 when scrolling a page up and down vertically and horizontally.

On any page with content (about:tabs) (http://www.msn.com/) (http://www.yahoo.com) scroll the page up and down using the mouse wheel, or the scrollbar on the right hand side. (resize window if necesary to obtain scrollbars).

Works like normal, right?

Ok, now zoom in to say 120% or 160% ([CTRL] + [+]) now try scrolling as before.

Woah! what happened? did your performance just tank? on some screens it will take 5-6 seconds to get to the top/bottom.

The good news is that this is just a beta, so there is still plenty of time to fix this. (we hope!)

Known Workarounds: None.

Related Issues: None.

Bug/Site Feedback |
Submit a bug

Internet Explorer first to need a "Fish Bicycle"!

Internet Explorer first to need a "Fish Bicycle"!

*&%$#@! on earth is a Fish Bicycle?

Fish Bicycle:
A Fish Bicycle is just that. A bicycle for a fish.

"But a fish doesn't need a bicycle!" you say?

- Exactly! -

A Fish does not need a bicycle. The idea of a fish needing a bicycle is beyond humorous to the point of gosh darn absurdity.

The term is used in many circles to describe something that is just plain not needed... not yesterday, not now, not ever.

As a developer you may have had a client ask for a Fish Bicycle. They insisted on one of those huge 6 paragraph legal footnotes on every page of a site and every email, or that data get saved to 5 redundant databases "just to be sure".

Did they need it? of course not... it was a Fish Bicycle.

---

So, what's the Fish Bicycle in Internet Explorer you ask? Ah ha! We're about to find out... but not so fast.

A Fish Bicycle in programming is when you need to "give a fish a bicycle" in order to workaround a bug.

For example: If you had to add an <input/> tag to the <head/> of a page in order to add a <div/> to the <body/>, that would be a Fish Bicycle. The body tag shouldn't have any issue adding a div, and the head tag certainly doesn't need an input tag.

Lets see if you can figure it out first! Here's a few clues.

1. It happens in all versions of IE, including IE8 Beta 2


2. It is definitely a bug, no question of that


3. It isn't a bug already reported on Web Bug Track


4. It is a JavaScript issue


5. Oct. 4 - New Tip! It isn't related to any element in the <body/>


6. Nov. 6 - New Tip! It involves popup windows


7. {tip coming...}

Got an idea? Need more info? Ask away in the comments! I'll publish a full writeup in a few days but I want to see if any of the readers can guess it first.

bug 215 - no hasAttributes() support in IE6, IE7

Issue: #215
Affects: IE6, IE7
Fixed In: IE8 Beta 2

The hasAttributes() method is available on the Node element in DOM 2 (W3C).

Test:

Known Workarounds: One. Test using a try/catch for the specific attribute you care about.

Related Issues: None.


Bug/Site Feedback |
Submit a bug

bug 342 - Connecting... in IE7 / IE8 takes F-O-R-E-V-E-R

Issue: #342
Affects: IE7, IE8

Update: It is well known that addon/extensions slow down IE. Disable any that are not required. In particular, MS Research is very slow and not needed.

Note: IE is still extremely slow after disabling addons, but the speed will improve.
Status: Microsoft has confirmed this will NOT be fixed in IE8 RTM



Normally the bugs posted on here deal with the content served up to the browser in HTML, CSS & JavaScript.

However Today's bug is about opening a new Tab in IE7/IE8, and the fact that it takes a V-E-R-Y long time (read:unacceptable), while "Connecting..."

Now we would be okay with the slowness if it were downloading something complex like the Digg or Slashdot, front page... but this happens opening the "about:blank" page!

For those unaware, the HTML code for the "about:blank" page is listed below.

"about:blank" HTML:

<html></html>

(That's it folks! No JavaScript!, No CSS!, No Head!, No Body!, Nada, Zip, Zilch!)

What is really frustrating with this, is that it seems to lock up resources while loading thus making it very hard to do anything else while the new tab is loading.

The final blow comes when you are opening the new tab, to paste in a new URL. If you paste it in reasonably quickly, it will kind of get there, but then get overwritten with "about:blank"... and IE can't load the page so you need to re-select the URL and re-paste it in to get to the site you wanted.

Usability is apparently one of the key objectives in IE8, so lets hope that this gets fixed before IE goes RTM. ;-)

Addition: By default in IE8 Beta 2, the "about:Tabs" page appears for a new tab, with a collection of additional items/options. This page is very slow also, but setting it to use "about:blank" doesn't speed things up.

Known Workarounds: None.

Related Issues: None.


Bug/Site Feedback |
Submit a bug

bug 404 - Operation Aborted in IE

Issue: #404
Affects: IE6, IE7, IE8

MSDN KB#: 927917

This issue in IE has a deep explanation over on the IE Blog in a post titled: What Happened to Operation Aborted. It is believed to be the source of pain that Sitemeter users were suffering from this past week in IE7.

To sum up, it happens when you use an inline script tag in your page to modify the contents of any of the un-closed ancestor tags of the script tag (excluding the direct parent).

In IE8 they are attempting to fix this, however thus far only the modal error message has been removed, and the page no longer goes blank.

Exact Conditions:

1. The HTML file is being parsed


2. script is executing


3. The executing script attempts to (add or remove) an element from an unclosed ancestor in the markup tree (excluding immediate parent of the script element)

Example:

<html>
<body>
  <div>
    <script>
      var newDiv = document.createElement('div');
      document.body.appendChild(newDiv);
    </script>
  </div>
</body>
</html>

The problem is, this is a very easy scenario to encounter, and to make it worse... if the bug is triggered in an iframe (*cough*, *cough* 3rd party ads anyone?) it affects the parent document, not just the iframe.

To make it worse the dialog is modal, requiring the user to interact with it to close it and when you close it IE navigates to an error page not letting you have a chance to debug it.

Known Workarounds: One. Do whatever you need to do to avoid this scenario. E.g. execute the script after the tag in question has closed, or only alter the script tags immediate parent.

Related Issues: None.


Bug/Site Feedback |
Submit a bug

bug 190 - fieldsets are broken in IE8

Issue: #190
Affects: IE8 Beta 1
Fixed in: IE8 Beta 2
MSIE Feedback ID: 336258
An anonymous poster has indicated that this is fixed in "Internal" builds shared with 3rd parties. Am I the only one that would love to be in on this "special list"? ;-) That said, glad to hear a fix is apparently on the way.

A Fieldset is really simple, you have a wrapper, and a legend which graphically wrap 1 or more form fields.

Communication preferences:

Please use the following methods to contact me;
Email
ICQ
MSN Messenger
Yahoo! Messenger
Google Talk
Phone
Fax
Skype

As you can see, (if you use IE8) the legend does not render correctly at all. Hopefully this is just a bug in this first Beta. Stay tuned for updates as further beta releases become available.

Known Workarounds: None.

Related Issues: None.

Bug/Site Feedback |
Submit a bug

bug 149 - no DOM Level 2 Mutation Events in IE

Issue: #149
Affects: IE6, IE7, IE8

The W3C specs for (W3C DOM2 Mutation Events) (Nov 2000) specify events that allow developers to listen for changes in the DOM, so that they can apply JavaScript on-demand, as needed.

In particular, noting when a DOM element has children added or changed are the key moments developers would like to be able to apply a sprinkle of JS.

Being able to use these events would be fantastic, but support for them in IE is non-existent at the moment.

Known Workarounds: None.

Related Issues: None.


Bug/Site Feedback |
Submit a bug