Site Navigation

Monday, March 23, 2009

bug 191 - stack overflow at line: 18 in IE

Issue: #191
Affects: IE6, IE7, IE8

Calling this a "bug" is a bit of a stretch but I wanted to post this so that users encountering this error message have an idea what to look for to fix it.

stack overflow at line: 18, stack overflow at line: 25, stack overflow at line: 41, stack overflow at line:67


It occurs only in IE, when you attempt to run code that runs in an infinite loop. Other browsers seem to pick up the recursion and simply ignore/skip over it without any errors.

It happens most commonly when you attempt to redefine the same method twice, which often happens as a side-issue of overwriting broken IE method implementations.

The actual line number in the message will change, but should be a fairly accurate indicator of where the call is that is causing the infinite loop.

Example:

<script type="text/javascript">
function fixGetElementsByNameInIE(){
//save ref to original method
document._getElementsByName = document.getElementsByName;
//now redefine it
document.getElementsByName = function(name){
var origResults = document._getElementsByName(name);
//... code to fix it...
return correctResults;
};
}
</script>


If you called fixGetElementsByNameInIE() more than once in IE when you try to actually run document.getElementsByName(name) IE will complain about a stack overflow as it ends up in an endless loop.


Known Workarounds: One. Never re-define a method in IE that points back to itself.



Related Issues: None.


Bug/Site Feedback |
Submit a bug

Friday, March 20, 2009

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

Monday, March 16, 2009

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

Wednesday, March 4, 2009

Bug or Feature? - Round Four

Round Four - Please Don't Stop The Music?

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

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:
The (now deprecated) embed element (use object instead) allows you to embed content in your page like audio and video. Adding audio on demand in your site can be an ideal way to add some multimedia interaction without having to resort to a full blown flash or silverlight plugin.

We can dynamically insert the embed element, and even start it by setting the autostart attribute to true.

If we remove the element, the audio stops, since it is no longer in the DOM... well it stops in Firefox, Safari, Opera, etc. but in IE it keeps on playing and there is no way to stop it. Since there is also a loop attribute that we can set to true, this opens up a very interesting behavior.

So the Question is...

Is this a Bug? Or a Feature?

Vote "Bug" or "Feature", and add your thoughts.

Monday, March 2, 2009

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 271 - strpos() function in PHP returns unexpected results

Issue: #271
Affects: PHP4, PHP5

PHP is by far one of the most popular server side programming languages available today (55% market share in our poll) however it has its own fair share of quirks.

For reasons unknown to us, PHP decided that the return value from the strpos() function will return an integer index... or maybe a boolean FALSE!

Huh say what?!

Almost every programming language has a method or two to find the position of a substring in a string.

JavaScript Example:

<script type="text/javascript">
var idx = 'Hello World'.indexOf('Wo');
alert('Found: "Wo" at index ' + idx);
</script>


They all return a positive index if the substring is found, or -1 if not.

Unfortunately PHP can sometimes return FALSE, or 0 (zero), or "" when it doesn't find the substring, which makes programming logic to handle this extremely difficult.


Known Workarounds: Several. Many developers have written new extensions to the String Class, standalone functions and more. Rather than claim to have the best solution ourselves, please send in your workaround using the comments below and we'll try to pick and highlight the best solutions from the submissions.

Example Workaround Code:

[Coming soon...]



Related Issues: None.


Bug/Site Feedback |
Submit a bug