Personal Website of Yakov Shafranovich

Browser Differences in window.opener Behavior

Among the more persistent bugs I have been chasing recently involves a set of interrelated windows. The case in point was a parent window (A) that opened a child window (B) via JavaScript. The child window (B) was set to check whether the parent window (A) is still open before doing any operations on it. Much to my chagrin on Internet Explorer the parent window (A) was reported as open even though it has already been closed, while other browsers said it was closed. After some interesting digging, I am going to share what I found with you.

To start off, the way I was checking whether the parent window was still open is via a simple JavaScript:

if(window.opener)

My logic was that if a parent window does not exist, then there should be no “opener” object for it. For non-Microsoft browsers that logic held up, but not for Internet Explorer. It seems that in IE the “window.opener” property stays valid EVEN after the window has been closed. Why? So you can use the “window.opener.closed” property to see if the parent window has been closed!

However, much to my suprise the Mozilla documentation also includes the window.closed property with a nice example which of course doesn’t work in Mozilla. Furthermore, the old Netscape documentation has this as well:

The closed property is a boolean value that specifies whether a window has been closed. When a window closes, the window object that represents it continues to exist, and its closed property is set to true.

Of course given that this is a DOM 0 property and as I mentioned before there is no formal specification for it. However, in this case both Mozilla/Netscape AND Microsoft define this object. The question is why in the world does the window object then disappear?

The answer unfortunatly is that it is a bug - namely Mozilla bug # 165418, opened over three years ago and still not fixed (why Opera never took care of this bug, I am not sure). HOWEVER, what makes it even more frustrating is that on Mozilla browsers the “window.closed” property does work for a split second after the window is closed. If you wait longer than that, then it stops working. And in case you are relying on IE - keep in mind that there is a rather nasty Microsoft bug # 241109 that returns ‘false’ instead of ‘true’ for the ‘window.closed’ property.

The solution for this problem is the following JavaScript snippet:

if(!window.opener || window.opener.closed)

For Mozilla/Netscape/Opera, the first part of the if statement will trigger (until they fix their bugs). For IE 6 the first part will not trigger but the second one will. Unfortunatly, for IE v5 there is no easy solution and I will leave that exercise to the readers (there is “>one suggested by Microsoft but I personally don’t like that one).

In any case, I created a small test page that tests different browsers. The page loads a second child window, which loads a third window and closes the second. The third window tests prints out the “window.opener” object and the “window.opener.closed” property. The test is run a second time exactly 1 second later. Results are as follows (I will be adding more results as I get around to testing them):

(In case you are wondering why Mozilla and IE say “object” when Opera says “null”, that is explained in the Mozilla bug report: “typeof(null) is “object” in ECMAScript”).

Posted in Programming | No Comments »

Another Day, Another JVM Bug

I am not 100% sure if it is a bug, but the consensus within my company seems to indicate that it is. Here is a copy of the bug report filed with Sun:

synopsis: DecimalFormat with a Lot of “#” Returns Incorrect Results for Floats

FULL PRODUCT VERSION :

java version “1.5.0″

Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64)

Java HotSpot(TM) Client VM (build 1.5.0-b64, mixed mode)

ADDITIONAL OS VERSION INFORMATION :

Redhat Fedora Core 2 / Linux 2.6.10-1.9_FC2 #1 i686 athlon i386 GNU/Linux

A DESCRIPTION OF THE PROBLEM :

When using DecimalFormat with a lot of “#”, putting too many “#” causes conversion problems with floats. For example, using “############0.0#######” on “0.3f” will produce “0.30000001″ instead of “0.3″. Converting the float to string first via “String test = “” + 0.3f” doesn’t have this problem. Doesn’t happen with doubles.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :

DecimalFormat df = new DecimalFormat(”############0.0#######”);

System.out.println(df.format(0.3f));

ACTUAL -

0.30000001

REPRODUCIBILITY :

This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.text.DecimalFormat;
public class DecimalFormatTester {
public static void main(String[] args) {
	DecimalFormat df1 = new DecimalFormat("#0.0#");
	DecimalFormat df2 =
		new DecimalFormat("############0.#######");
	float test_value = 0.3f;
	System.out.println("Short: " + df1.format(test_value));
	System.out.println("Long: " + df2.format(test_value));
}
}
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :

Use “#0.0#” instead.

Posted in Programming | No Comments »

Outlook and Norton AntiVirus 2002

In the past two weeks, three different computers I have worked on for clients displayed the same problem: Outlook would stopped working completely with some weird error message. Doing a quick check with telnet to my own mail servers and running tests on other computers with clients’ mail servers quickly narrowed down the problem to the actual three computers. After going through several different programs that were running, I decided to disable Norton AntiVirus 2002. To my suprise things started working again. So I decided to do a little digging.

The first gem that I found is Microsoft’s Knowledge Base Article # 813514 which includes the following snippet:

If your antivirus solution includes an e-mail scanning feature, you may have to do additional configuration to use Outlook or Outlook Express with the antivirus e-mail scanning feature. Antivirus software that has been known to cause this problem includes products by the following vendors:
• Symantec (Norton)
• McAfee
• Trend Micro (PC-cillin)
• Panda

After checking Norton’s site I came up a recommendation to update their software via LiveUpdate. The problem is that it did not help. The article on Symantec’s website ended off with the following:

If you are using Outlook 2002 and updating NAV does not fix the problem, then we have had reports that updating to Outlook 2002, Service Pack 2 has fixed the problem.

In other words Microsoft is blaming Symantec while Symantec is blaming Microsoft. To make this even more bizarre another Microsoft KB article (#309676) has the following recommendation:

WORKAROUND:
To work around this issue, disable the e-mail scan portion of Norton System Works.

And then you start wondering why so many viruses get through on Windows when it is recommended to shut it off.

In the end I recommended to the clients to disable the email scan portion and rely on the auto-protect functionality. One client had an option to disable “Worm Protection” without disabling the rest of the email scanning options which helped instead. However, I still came away thinking about the bad state of security software on Windows when the OS manufacturer and the anti-virus vendors can’t even get their stuff to interoperate.

P.S. After this entire episode took place, someone working at the IT department of a major US bank informed me that this issue was why his company switched to a different anti-virus vendor.

Posted in Technology | Comments Off

Proper Bug Hunting

Joel has a great piece which mentions the right approach to bug fighting:

For example, if I assign a bug to a developer I expect them to:
1. reproduce the bug
2. if it’s not immediately reproducible, make a good faith effort to figure out why it’s happening to me instead of just assuming that I’m doped up on anti-allergy medication and hallucinating it
3. find the root cause
4. do some searches to see if the same errors were made elsewhere in the code
5. fix them all
6. test the fix
7. think about whether this bug might be causing serious implications for a customer who needs to be told about the fix etc.

That’s the Rosh Gadol behavior. Possible Rosh Katan behaviors would be
1. resolved-not-repro. You can always get away with this once without even trying to repro the bug, because later you can pretend you didn’t understand the bug report.
2. without even reproing the bug, make a change to the source code that seems like it would fix it and resolve it as fixed. If it wasn’t, I’ll catch it when I close the bug, right? And if it’s really still broken, surely another tester will find it.

Rosh Gadol of course is quite the opposite: taking initiative and doing what is desired, not what is requested.

Posted in Programming | Comments Off

My First FireFox Bug

I filed my first bug with FireFox today: when running self.resizeTo() function in Javascript twice the toolbars on top strech a bit too far. You can try it for yourself below:

Posted in Programming | 1 Comment »

The JVM bug is back - in Sun’s database

One of the bugs we reported to Sun before got posted to Sun’s bug database under # 4987749 (although it might take a day or two to propogate). Use this link:

http://developer.java.sun.com/developer/bugParade/bugs/4987749.html

Posted in Programming | Comments Off

A copy of the String bug we found

A copy of the bug report we submitted to Sun is included here for the curious: (its long and nasty)
Read the rest of this entry »

Posted in Programming | Comments Off

The bug hunt has finished!

After some digging in the JVM source code, our CTO came out with the exact source of the problem and a possible workaround. Of course this is all at your risk, so don’t blame us or Sun if you have problems. A copy of the message we submited to Sun appears here:

SOURCE CODE TRACEWe took a look at the source code of the JVM. The problem stems from the fact that float values are used to indicate the maximum value of bytes per characters in java.nio.charset.CharsetEncoder.maxBytesPerChar.

The issue is that floats cannot accuratly hold more than 2^24 integer values which is equals to 16,777,216. After that value is reached, the encoding operation in the character set classes incorrectly rounds down the amount of memory needed for the buffer. The correct solution would be to use doubles instead, or account for the round off problem by increasing the buffer size.

SUGGESTED WORKAROUND

The workaround that we are using, is to use to .getBytes() on a substring that is smaller than 16MB, and combined the results by either using a ByteArrayOutputStream or a ByteBuffer.

NOTE: If you are planning on using more than one-byte characters sets, than you have to make sure that your buffer is set accordingly.

Posted in Programming | Comments Off

Huntin down a String bug in Java VM

We have been hunting out a nasty bug in our code involving processing of large XML files via Java String, StringBuffer and byte[]. We finally narrowed it down to the following line:

byte[] byteArray = largeString.getBytes();

which fails with:

java.nio.BufferOverflowException
 at java.nio.charset.CoderResult.throwException(CoderResult.java:259)
 at java.lang.StringCoding$CharsetSE.encode(StringCoding.java:340)
 at java.lang.StringCoding.encode(StringCoding.java:374)
 at java.lang.StringCoding.encode(StringCoding.java:380)
 at java.lang.String.getBytes(String.java:590)

and guess what, it fails, and its now our code either After doing some head scratching and checking around Sun’s site, this came out to be a JVM bug # 4949631.P.S. As I was searching through the Sun’s bug site, it was really sad to see the same bug being mentioned over and over, and being closed because the submitters could not provide normal code to reproduce it. Good thing to keep in mind when submitting bug reports.

Posted in Programming | 1 Comment »