Web Bug Track View RSS

Microsoft reverts their decision to block Flash by default in IE10! 19 Mar 2013 8:59 AM (12 years ago)

Microsoft reverts their decision to block Flash by default in IE10 - Users and Developers rejoice!

If you've been following along you'll know that Microsoft announced back on September 2011  that IE10 running in what they used to call "Metro Mode" would no longer be running addons including Adobe Flash.

• They required developers to test on hardware that wasn't commercially available
• They ruined the user experience by taking control away from the user.
• The user would visit a site and the content would be blocked - yet they had no way to know nor any way to enable it if they wanted.

• They used a whitelist instead of a blacklist (classic programming flaw when dealing with billions of anything)

bug 345 - keyboard locks up in iOS WebKit textarea 13 Mar 2013 9:47 AM (12 years ago)

Issue: #345
Affects: iOS WebKit 536.26 (Safari & Chrome on iPhone, iPad, & iPod)

Note: this issue is specific to iOS.  WebKit running on BlackBerry / Android devices are unaffected by this bug.

Under normal circumstances a TextArea (even in WebKit) works just fine however on iOS6 and WebKit 536.26 there is a bug with textareas if they are within an iframe.


Example:

<iframe src="somePage.html"></iframe>

<textarea cols="60" rows="6">

type a bunch of multi-line content (e.g. "abc" [Enter] over and over)

</textarea>

bug 571 - IE 10 Textarea focus is broken (Breaks Fitts's Law) 4 Mar 2013 9:37 AM (12 years ago)

Issue: #571
Affects: IE10 (Windows 7) (Might affect Windows 8)

Microsoft released IE10 RTM for Windows 7 on February 26th exactly 4 whole months after it was released for Windows 8.

While this was a welcome upgrade for the developer community it was met with a lack-luster response.

The UI skin was directly ported from Windows 8 and so every control is rendered flat, no longer responds to the hover event visually and has lost all the visual styling and clues that made Windows 7 such a successful operating system.

2 significant issues have come out of this (1 is related to select lists (but that will be coming in a future post)) but the other is a behavior regression in the Textarea Element.

In normal use a user can place the cursor at the end of any line of text by clicking in the textarea anywhere to the right of that line.  This enables easy navigation within the textarea to jump in at any point and start editing.

In IE10 it does work but only in very specific circumstances.

The bug exhibits itself currently in any Textarea where the field is defined but no line break appears in the content of the tag. e.g. an empty Textarea (the default for most textarea's initially). Instead of putting the focus at the end of the line IE 10 places it at the beginning of the next line unless you click within a pixel or two of the last character.

If any developers can test this in IE10 on Windows 8 (both Desktop and Metro) please let us know if the issue exists there too.

Example:

This Fails:

<textarea cols="60" rows="8">Add Lines and try to navigate!</textarea>

<textarea cols="60" rows="8">

</textarea>

bug 593 - IE leaks all your windows mouse movements 16 Dec 2012 1:33 PM (12 years ago)

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.

bug 503 - window.prompt() no longer supported in IE10 "Metro" 12 Nov 2012 8:17 AM (12 years ago)

Issue: #503
Affects: IE10 "Metro" on Windows 8

Note this bug affects "Metro" (and we need to use air quotes because Microsoft has not clarified what this new OS mode will be called after Metro AG staked their legal claim to the copyright name).

One of the many changes in IE10 "Metro" is that not only do plugins no longer work (with the exception of a minor chance of running Adobe Flash) but some basic functionality has been removed.

In IE10 Metro the window.prompt(msg, default); method no longer works - period. 


Example:

<script type="text/javascript">
  var username = prompt('What is your name?','');

  alert('Your username is: ' + username); 

</script>

IE10 for Windows 8 to be released on October 26th, 2012 22 Oct 2012 6:28 AM (12 years ago)

IE10 for Windows 8 to be released on October 26th, 2012.

For developers keeping up to date on IE developments this likely isn't news however there's lots of new things coming that developers need to be aware of.

For starters even though it won't be available on the Oct. 26th launch date there is a version of Internet Explorer 10 coming to Windows 7.  There's been no confirmation from Microsoft yet but there has been a preview announced for Windows 7 in mid November (lets call that Nov.15th) which would suggest at the earliest an RC (Release Candidate) in December and an actual release by January 2013.

What this means is that Web Developers need to be ready to support IE10 even if they haven't yet downloaded the Windows 8 RTM preview OS they probably really should go get a copy as the promised Windows 7 version is way behind schedule.

3 Versions?

A lot is changing in IE10 so lets take a moment to go over the highlights.  For starters there are (or at least will be) 3 versions of IE10. IE10 for Windows 7, IE10 for Windows 8 in Metro Mode and IE10 for Windows 8 in Desktop Mode.

The most interesting (and also most controversial) is IE10 for Metro.  It provides the perfect full screen touch friendly interface for the upcoming Windows 8 tablets including the tablet that Microsoft calls "The Slate" (Forgive me while I LOL thinking about The Flintstones or any other ancient reference.

On the positive side Microsoft added Back/Forward navigation overlays at the middle of the screen on the left and right sides perfect for thumb navigation while holding the tablet... and the full screen mode helps the user dive right in on the content they are viewing.  While on the tablet you can use gestures similar to those on the BlackBerry PlayBook or some Android devices to swipe up/down from the bottom/top of the screen to expose the location bar and a thumbnail list of your active tabs.

On the negative side (yeah you knew there would be one right?) there are several usability issues that affect IE10 and Windows 8 that your users might not realize are due to the browser/OS and not your site.

Before we get into the details of each one its important to understand "how we got here" and thus the back story as best understood by the collective Internet (as Microsoft has failed to provide the story themselves).


The Story:

In developing their next Operating System Microsoft realized that they were starting to significantly lose their dominance in the market.  Apple was making a major comeback with sexy hardware, an OS that just worked and 3 little things called the iPod, the iPhone and the iPad.  In fact that last device, the iPad was inventing an entirely new market and Apple was taking it all by storm!  This was upsetting to Microsoft as they had tried to create this market years ago and had failed... and their music player that they had recently built (the Zune) had failed to take any market away from the iPod.  Microsoft was in serious trouble and even they knew it this time.

They needed to make a tablet that could compete in the market and somehow use their desktop dominance to help upsell the tablet and so they realized that being able to use the full Windows desktop on the tablet (not just a VNC/Remote Desktop) was needed - and that would be their biggest selling feature!  However the UI from Windows (even Windows 7) simply wouldn't cut it on a tablet as it was never meant to be driven by touch as a keyboard and mouse provided so much more control.  The solution was to add the UI from their flailing Windows Phone device (even though Microsoft themselves had admitted it was a failed design) that had some very compelling usability features to the tablet and thus kill 2 birds with 1 stone giving both the phone and the new tablet a consistent look and feel.

However now there was a new problem... Microsoft wanted to make the tablet and the desktop version of Windows to have a consistent look to help lure consumers into buying a Windows Tablet when it shared similarities to the desktop they would be familiar with... and thus they decided that both the tablets and the PCs would both have the "touch friendly" Metro interface by default... but both would also have the full blown desktop experience hiding just underneath.  Conceptually this was a massive marketing win and I don't blame Microsoft for taking this approach to try and C.T.A.

The Analysis:

Wait! What? But won't that make 1/2 of the experience on the tablet suck... and the other 1/2 on the desktop PC suck? - why yes... exactly!

There's a very good reason why the iPad was so successful.  It was pre-seeded with 1,000's of iPod/iPhone apps when it was released and the UI was simple, designed entirely for touch... the UI was tailored to the device and the form factor.

Metro is simple too (its just a bunch of squares and rectangles) in fact many think it is too minimalistic... there's no "love" for this UI... no shadows, no rounded corners, no glossy igons, not even shadows or the most basic of 3D effects... you know, the ones that afford usability by making a button so obviously click-able vs. a flat rectangle that isn't.

The classic "desktop" experience on a tablet however... just plain sucks.  It's not touch friendly and anyone that has used VNC or similar tools on an iPad knows that its handy to be able to use a desktop app in an emergency but no one in their right mind would want to do this regularly by choice.

The reverse is also true.  Desktop users love their PCs because they can do anything and get things done. Data entry? you bet! 3D Modeling? yup! Spreadsheets and Databases... legacy Enterprise apps - yeah it all just works.  Metro on a desktop though is clumsy... there's no options for "power users" and unless your boss wants to let you play Angry Birds and other games all day... 99% of Metro will be "fluff" to you.

Wow... so much info to explain and digest.  I think I'll save the really technical details for another post (and I'll add a link below once posted).

(Link to part 2 - The technical details)

In the meantime if you've already tried out Windows 8 and IE 10 let us know your thoughts... have you tested your sites and apps?

bug 517 - Internet Explorer Zoom doesn't always work 29 Aug 2012 7:36 AM (12 years ago)

Issue: #517
Affects: IE7, IE8, IE9, IE10 Preview

Ever since Internet Explorer supported zooming page content in the browser there have been issues with the Zoom feature.

In IE7 it was rough and it was particularly bad scaling form elements unequally not to mention framesets were a disaster.  In IE8 things got much better and the scaling was much more predictable.

However there are 4 issues with Zoom in IE to this day that drive developers and users alike bonkers.

1.) The default keyboard shortcut of [CTRL] + [0], [CTRL] + [-], and [CTRL] + [+]  to adjust the zoom do NOT work if you use the numberpad keys.

2.) The zoom isn't a graceful increase when zooming in 5% at a time like in other browsers.  IE's first "step" is a whopping 125%!  As developers this isn't always easy to accommodate gracefully... many users just want to bump up the zoom a "notch" and 125% is overkill.

3.) The performance of a web page drastically decreases when zoomed in to the point that on heavy web pages the site becomes almost unusable - Most corporate web applications do not support use of Zoom in IE as a result.

4.) Zoom isn't applied to everything! Oh sure, you probably knew that radio buttons don't scale but did you know that if you have any dialog windows created using Microsoft's proprietary showModalDialog() or showModelessDialog() methods that the content inside them completely ignores the users request to have the content zoomed.

Does your site/application support the Zoom feature in IE? Have you seen how it behaves compared to other browsers?

Note: The Modal, and Modeless dialogs in Internet Explorer have been deprecated in IE10 Metro Mode thus if you were still using them for some strange reason it is time to update your code!

 

Bug or Feature - Round Six 28 Aug 2012 7:21 AM (12 years ago)

Round Six Enabling the non-Disabled.

Other rounds: [One|Two|Three|Four|Five|Six]

We're back again with another round of "Bug or Feature?" highlighting a particular behavior in one or more browsers, that, well, could be a Bug, or it could be a Feature... we'll open up the comments for your vote and opinion.

Alright, what's today's "Bug or Feature"?

Synopsis:
Everyone knows that form elements [button|input|select|textarea] can be disabled to stop users interacting with them and to ensure they are not "successful controls" when a form is submitted.

So... what happens if you disable non form elements?

In most browsers... Just like you'd expect... absolutely nothing because it isn't supported.

However in IE there is a different behavior.

In IE when you set the disabled flag on an element it "kinda-sorta" disables all the child elements.

Example:

<div disabled="disabled">
  Email:
  <input type="text" name="foo" value="bar"/><br/>
  Send me spam:
  <input type="checkbox" name="baz" value="yes" checked="checked"/><br/>
</div>

Microsoft drops support for features in Metro IE 10 10 Jul 2012 8:00 AM (12 years ago)

Microsoft drops support for features in Metro IE 10 Affects: IE10 Metro Microsoft has dropped support for some legacy IE-only features in IE10 (Metro version) in Windows 8 (due out later this year). Two methods in particular have been dropped: showModalDialog() and showModelessDialog(). Example:

<script type="text/javascript">
 var legacyModalPopup = showModalDialog(url, args, options);
 var legacyModelessPopup = showModelessDialog(url, args, options);
</script>

bug 523 - disabling option elements fails in Safari on iOS 21 Sep 2011 8:30 AM (13 years ago)

Issue: #523 Affects: Safari on iOS (iPod, iPhone, iPad) Select options support a disabled attribute so that developers can optionally disable individual options if/when they are not applicable. Safari on the desktop (Windows or Mac) both support this attribute however Safari on iOS (so iPod, iPhone, & iPad) the attribute doesn't actually do anything and the user is free to select the option even though it is supposed to be disabled. Example:

<select>
  <option value="1">first<option>
  <option value="2">second<option>
  <option value="3" disabled="disabled">third<option>
  <option value="4">forth<option>
</select>

bug 196 - IE9 fixes almost .setAttribute('type', value); 17 Nov 2010 8:12 AM (14 years ago)

Issue: #196
Affects: IE9 PP4, IE9 Beta, IE9 Platform Preview 6

We're happy to say that IE9 has brought many, many improvements to Internet Explorer in terms of updating the IE engine to properly handle standards based code.

IE had issues in the past with the Element.setAttribute(name, value); method for a long time not supporting it on a wide array of elements (bug 242) of which the type attribute was a significant one (bug 237).

We were hoping that after IE9 Platform Preview 4 was released and we found that the .setAttribute('type', value); method had finally been fixed that the "new" bug with the value being erased when switching an HTMLInputElement from type "password" to "text" would have been fixed 2 public releases later.

Unfortunately it is still broken and thus we're tracking this new issue separately here.

Example:

<input type="password" id="accessCode" name="accessCode" value="bfg10k"/>
<script type="text/javascript">
  function exposeCode(){
    var field = document.getElementById('accessCode');
    field.setAttribute('type', 'text');
    //Oopsie! the value is now gone in IE9!
  }
</script>

bug 387 - setAttribute('type','file'); fails in Chrome & Safari 7 Sep 2010 8:17 AM (14 years ago)

Issue: #387
Affects: IE6, IE7, IE8, IE9 Beta, Chrome 5,6,7, Safari 5
Fixed In: IE9 Platform Preview 6 (only when rendering in IE9 Standards Document Mode)

We've long known that IE has problems with both setAttribute (bug 242), and specifically changing the type attribute (bug 237) however it looks like it is Chrome and Safari that have an issue now.

It seems that in Chrome and Safari you can't set an input element's type attribute to "file". Try it out below! (It will fail in IE too of course, but that's a known issue)

Example:
filename:

bug 493 - no onbeforeunload event in Safari on iPad 2 Jul 2010 7:15 AM (14 years ago)

Issue: #493
Affects: Safari on iPad

Web Developers have long used the onbeforeunload event to catch users leaving a form partially filled out and prevent them from losing their work. ;-)

On the down side, horribly shady sites have used it to try and keep users on a site with messages about free or cheap offers of electronics or porn if they stay on the site. :-(

It is a great tool when used correctly and thus it is rather unfortunate that Apple has left it off the iPad version of Safari... Users indicate that they have accidentally left a page trying to scroll the view to see better when the keyboard pops up.

Hopefully this will get fixed in a future patch to the OS.

bug 391 - IE is strict in setting innerHTML but not appendChild 28 Jun 2010 9:14 PM (14 years ago)

Issue: #391
Affects: IE6, IE7, IE8, IE9 PP3

IE is well known historically as a browser that doesn't follow the strictness of standards well. IE will often let you do things that you shouldn't be able to do (e.g. add a div to a select element)

However there are cases where IE is very picky - although confusingly arbitrary in how and when it decides to be strict.

Take for example the <p> element. By definition, this is an inline element which means it should not contain block elements.

The following however seems to work fine in all browsers (e.g. the "rule" isn't strictly enforced")

Example:

<script type="text/javascript">
  var newHeading = document.createElement('h1');
  newHeading.appendChild(document.createTextNode('I am an H1 element!'));
  myParagraph.appendChild(newHeading);
</script>

<script type="text/javascript">
  var newString = '<h1>I am an H1 element!</h1>';
  try {
    myParagraph.innerHTML = newString;
  } catch(ex){
    alert('Failed: ' + ex['message']);
  }
</script>

bug 552 - no double-click event on the iPad 28 Jun 2010 8:26 PM (14 years ago)

Issue: #552
Affects: Safari on the iPad

Ok, calling this a bug is a big stretch because it was intentionally removed. This is more of a footnote that the dblclick event is not available in Safari on the iPad.

The reason is that the iPad reserves the double "tap" event to zoom in and out of a Web page.

However there's a few additional events that Safari on the iPad doesn't support (with no obvious reason) but we'll tackle in another post. ;-)

Example:

<script type="text/javascript">
  <div ondblclick="alert('this will never fire');">DBL Click Me</div>
</script>

bug 543 - no window.print() in Safari on the iPad 25 Jun 2010 8:53 AM (14 years ago)

Issue: #543
Affects: Safari on the iPad

Printing web pages is very common when you just want to be able to hold something physically in your hands or take home with you after work to read when you have time.

With Safari on the iPad - there isn't a print option, and likewise there is no

window.print();

method implementation in the iPad version of Safari.

With any luck this won't be an issue for most users as they can surf and read the online content wherever they want... but if you were hoping to scribble notes, correct content or go to town with your rainbow array of highlighters you are out of luck.

bug 536 - no file upload in Safari on the iPad 25 Jun 2010 7:41 AM (14 years ago)

Issue: #536
Affects: Safari on the iPad

The iPad is great for everyday web surfing on the couch or on your daily commute but Safari on the iPad has some quirks that make it significantly different than the desktop version.

For starters - the HTML <input type="file"/> element doesn't work. It renders as a disabled input. So if you were hoping to send pictures or MP3's by attaching them to an email in GMail or Hotmail etc. you are out of luck.

Since the iPad doesn't really expose an operating system and files to the user - this does kind of make sense - though I'm sure it will confuse some users at first.

Safari on the iPad - The new king of mobile tablet browsers 25 Jun 2010 7:19 AM (14 years ago)

Safari on the iPad

The new king?!, says who?! - well the reality is that this is essentially a new market. Oh sure you could get bulky tablet displays that run Windows and IE but that is nothing like the iPad or the soon to be released devices by HP, Google, Microsoft and others.

The trick here is that Apple absolutely "Crushed It!" (thanks Gary Vaynerchuk ;-) when they released their iPad. If you haven't got your hands on one of these devices yet - be sure to stop by your local Apple store and check it out.

This device is so sexy, so portable, yet so simple to use that it changes the game for tablet devices.



It doesn't run a full blown bloated OS, it comes ready to install one of thousands of apps from the AppStore and users are already totally familiar with the interface due to the massive success of the iPhone.

bug 511 - checkbox double click fail in IE 24 Jun 2010 6:43 PM (14 years ago)

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

On the web almost all interaction is based on the single-click concept. You click once to follow a link, you click once to press a button, once to open a dropdown select list, select a radio button or checkbox element etc.

So if you were to double click an element that toggles (e.g. like a checkbox) you would expect the first click to change it from state A to state B... and the second to change it from state B back to state A. (e.g. unchecked - checked - unchecked)

This works as expected in all browsers except IE. In IE double-clicking a checkbox will only switch the state once from A to B.

Example:

Try Double Clicking these options:

Apple
Linux
Microsoft
HP
Dell
Cisco


Realistically this isn't a major issue as most users are unlikely to double click a checkbox... however based on the number of post on web forums and newsgroups about how to stop users from double clicking and re-submitting data - it certainly does happen.

bug 419 - fieldset legends broken again in IE9 PP3 24 Jun 2010 6:31 PM (14 years ago)

Issue: #419
Affects: IE9 PP3, Opera 11
Fixed In: IE9 Platform Preview 6

Update: Opera latest release (version 11) is also showing broken fieldset legends.

It appears that the latest IE9 Platform Preview #3 (PP3) has re-broken (bug 190) the fieldset element to cause rendering glitches with the legend element.

Example:

bug 358 - saving web pages is incredibly slow in IE 10 Mar 2010 8:14 AM (15 years ago)

Issue: #358
Affects: IE6, IE7, IE8

Rendering content in the browser is obviously the main goal of day to day web surfing and web application usage.

There's form interaction, games, Facebook, Mashups & Twitter updates just to name a few.

However when you get a bunch of info/data you care about you likely want to do something with it. Typically you'll want to print, save or export your content so that you have a hard copy or backup.

However exporting is only an option if the web application you are using supports that feature... and printing is a great way to waste trees... but a 500 "page" report is something better suited to be saved to a digital file. Besides maybe you want to manipulate that data in your spreadsheet program before printing it or making a PDF to share.

Alright, easy as pie... just render the page you want and choose Save as from the right click menu file menu.

Should take about a fraction of a second to save the page you are viewing (already downloaded) to an HTML file.

Well not quite! Although Firefox, Chrome, Opera & Safari all do this in milliseconds IE does not. Internet Explorer re-requests the ENTIRE file from scratch. Yes, that's right, re-downloads an EXACT DUPLICATE of your (example) 500 page report!

Needless to say this is a massive waste of bandwidth and user time as they wait for the page to be re-fetched... while staring at the already rendered copy they already have!

bug 209 - prompt() rendering glitch in Opera 19 Jan 2010 7:17 AM (15 years ago)

Issue: #209
Affects: Opera 10.10, 10.20, 10.50, 10.60

Unlike the problems with the prompt dialog in IE (bug 109) (bug 139), and the features of the Safari prompt dialog (feature 266), the Opera JavaScript dialogs have typically been excellent and even lead the pack in terms of features like adding the hostname to help prevent XSS (Cross Site Scripting) and a checkbox to escape endless loops that crop up mostly during development of course! ;-)

However during some dialog testing we noticed that Opera has a rendering glitch with the prompt() dialog.



Example:

<script type="text/javascript">
  var data = [];
  var count = 50;
  for(var i=0;i<count;i++){
    data.push('For your information, this is item # ' + (i+1));
  }
  prompt(data.join('\n'),'a default value');
</script>

bug 396 - more style tag limits in IE 5 Jan 2010 7:45 AM (15 years ago)

Issue: #396
Affects: IE6, IE7, IE8

Microsoft Support KB: 262161

You may already be aware that Internet Explorer has some limitations with the amount of CSS it can handle (bug 327) so that you can only load a CSS file up to ~288kb in size and the total number of CSS selectors/style rules can't exceed 4096 but there's more!

IE will also only allow you to have a maximum of 30 style tags on a page! So if you have a site that injects a lot of style tags on the fly for components/widgets you may want to think twice about this approach.

Run this code in IE and note that IE caps out at 30 and doesn't create the addition 70 stylesheet tags.


Example:
(note: this is IE specific code)

<html>
<head>
<script type="text/javascript">
function createStyleSheets(){
  for(i=0;i<100;i++){
    document.createStyleSheet();
    var msg = 'Total Style Sheets = [<b>' + i + '</b>] of 100.';
    document.getElementById('ssCount').innerHTML = msg;
  }
}
</script>
</head>
<body onload="createStyleSheets();">
  <div id="ssCount"></div>
</body>
</html>

bug 225 - no support for TBody CSS height or overflow in IE in Quirks or Standards mode 9 Nov 2009 8:49 AM (15 years ago)

Issue: #225
Affects: IE6, IE7, IE8

The beauty of CSS is that you can take a simple design and enhance it with a style sheet for aesthetics and usability.

A classic enhancement is to wrap table rows in a tbody element that will allow for vertical scrolling when they exceed a certain height.

All you need to do is set 2 or 3 CSS properties.

Example:

<style type="text/css">
  tbody{
    height:100px;
    overflow-x:hidden;
    overflow-y:auto;
  }
</style>

bug 361 - Anchors collection in IE contains invalid members 29 Oct 2009 6:07 AM (15 years ago)

Issue: #361
Affects: IE6, IE7, IE8

In the days before the DOM Methods we have today we only had access to a few special collections for things like forms, anchors, links, images, etc.

They may not be as sexy as document.getElementById(), but they worked, and still do to this day... and depending what you are trying to access may actually be much quicker and easier.

So to the point, the document.anchors collection contains an array of all the anchors defined in the page.

Anchors by definition are <a> tags with a name attribute specified.

Now for the bug.

As disclosed in (bug 152) IE has notoriously had issues with differentiating between id and name attributes, polluting IDs with NAMEs and vica versa.

Thus, if you have hyperlinks with an id attribute set in IE... you will now have a new member in the document.anchors collection even though there is no name attribute specified! Have lots of links with id attributes set? Then you have lots of extra items in your document.anchors collection.

Of course the interesting twist on this is that in modern browsers, any element (div, table, span, img) with an id attribute set can act "like" an anchor in that you can add it as a hash tag in the URL to auto-scroll to a specific spot however keep in mind that by definition only an <a> tag with a name attribute set is a valid element in the document.anchors collection.