Tech Blog

Don’t set the value of window.location.href at least not with a pointer!

March 10th, 2011

I had the weirdest JS bug yesterday. Check this out:

So, I’ve got a method that reads like this:

  function showLocation(){
    var _html = "index.html";
    if (someBoolean) {
        _html = "index_modified.html";
    }
    globalVariable.location.href = "/somepath/" + _html;
  }

That’s *basically* how it went.  So, this worked fine in Chrome (latest), and IE 8 (I didn’t test anywhere else… didn’t think I needed to).  Our QA guy is testing in FF 3.5 and says it’s broken.  I’m like, “f-you, IT WORKS!”  We start talking and it becomes apparent it’s FireFox specific.

What is happening is this:

The browser is redirected to /somepath/index_modified.html (as it is supposed to be), but then all of a sudden forwards to /somepath/index.html  (where it is NOT supposed to be since that “someBoolean” is currently true).  It’s like the method is called TWICE, but the second time doesn’t have the correct variable state.

?!

2 hours later, after suspecting 3rd party vendor code on the target pages, apache’s mod-spelling plugin, and a host of other things… I find the problem to be in that “globalVariable” (I think!  More on this below).

That “globalVariable” is JUST a pointer to window.parent.  The reason the variable is used has to do with forward maintenance, anticipating a time in the future when the app is not loaded in an iframe.  No biggie.

But after a shit ton of debug statements, and confirming that it IS the code in this method that is causing the issue, I’m trying ANYTHING (this is of course an urgent-has-to-go-out-yesterday issue for The Client).

I finally try this modification to the line (mostly out of desperation):

globalVariable.location.href = "/somepath/” + _html;

… I change it to:

window.parent.location.href = "/somepath/” + _html;

And suddenly EVERYTHING WORKS JUST FINE.

The QA guy and I curse the gods of web-design, shake our heads and ship it.

Of course, I can’t let it go…
and figured it out after some extensive digging on the internets last night.

So, the *real* problem with my code was this:  “location.href = …”  Apparently, the “href” is unnecessary AND in older versions of FF would cause the exact error I was seeing.  The typical JS left-to-right resolution was being put in place and [window]location.href was being set first (which would update the browser location) AND THEN [window]location was being set.  People who experienced this bug in the past, just saw it as a double page load in FF.  I was seeing such weird behavior because my “someBoolean” above was determined in part by querystring parameters in the URL… since those had changed… it was now false.

So why did my fix (”window.parent.location.href = …”) work?  Since it should have the same problem, right? I’m betting they put in some sort of wrapper/parsing to filter out this behavior in current versions, but since I was using the pointer to window.parent how ever they’re masking their bug failed and I brought back what is apparently an old issue for FF.  I just confirmed that my original code with the “href” removed works as expected.

Thought I’d share, because

a. Holy wow that was weird

b. Hope you never encounter it, but if you do, now you know.

A few thoughts on CSS/HTML Layout here and now in July of 2008

July 13th, 2008

So, here I am going into my twelvth year of web design. Things have changed so much since I started and for the most part things have been slowly and steadily getting better: image slicing is a dream, infinitely nested tables are a thing of the past, and so much interactive candy is available now we’ve all got cavities. Some things are still hurting or are hurting in all new ways: we still have to work with designers who only understand print insisting on fixed width layouts or image fonts, banner ads eat up a quarter of your screen real-estate, and clients still expect your site to look *exactly* the same in every browser ever invented.

It is this last item that continues to drive me insane. And the main reason, is that Nirvana is so close I can almost taste it. What is it keeping us from the land of milk and honey? A land where we can develop one set of css for every major browser?

Internet Explorer 6.

As of last month, IE6 still holds ~25% of the market. Why don’t these people upgrade to IE7 at least? I wish I knew.

Here is a little story of development and how IE6 played the villian.

About 2 weeks ago, I sat down to design a new layout and focus for my site. I spent a little time on the graphics (I knew I was going to use .pngs for alpha transparency) and sat down to do the layout. Like most developers these days, I start in Firefox. Starting in Firefox isn’t necessarily the smartest move based on past experience in attaining cross-browser compatability, but when I weigh the time spent getting a Firefox ready page to work in IE vs. the time I save on layout with tools like Firebug available, Firefox is the place to be.

After finishing up, I steeled myself for launching the site in IE. Now, as mentioned above, I’ve been doing this for a while, so I wasn’t too scared of stepping into IE. I just was preparing for the let-down, the heartache of watching my clean html and tight css get bloated and convoluted. And, to be honest, there’s always a little fear that you’ll discover your idea isn’t possible in that other browser. Imagine my surprise, when I opened up IE and saw my layout almost identical to that shown in Firefox. What the heck? Oooh, this is IE7. Wow. I knew 7 was better than 6, but I had not realized how much better. On a large project I’d worked on that when begun, had to support IE 5.5 and 6 (as well as Firefox 1&2, and Safari 1 with PIXEL IDENTICAL LAYOUT) we had some crazy amount of IE hacks in place. When IE7 released we’d had to add in an IE7 hack as well, and I’d always suspected that most of the IE7 specific hacks were just undoing much of the code that was in place for the other IEs, but this proved it.

I had already known that IE6 was going to be an issue, since, as mentioned above, I was using alpha-transparency .pngs. However, my success with IE7 got my hopes up when it came to layout.

When I opened up IE6, I was immediately struck by the overwhelming amount of ugly on the page. My layout was pretty much completely destroyed. I saw hours and hours (at least) of work ahead of me to get things working right. As this was a side project, I didn’t have a lot of time to work on it, so I had a few days to mull it over.

For half that time, I was pretty much of the opinion I just wasn’t going to support IE6. Why support those folks that won’t upgrade? I’m cutting edge! I don’t need them!

But that did not sit well with me. I have always been of the opinion that your site should degrade as gracefully as possible. And I couldn’t ignore that as of today, 25 out of 100 people that might visit the site, would be using IE6. And greeting them with a slap in the face, was probably not going to be good for repeat traffic.

A few more days and I finally had the epiphany that I was not working on big project for a client. There was no one telling me the site had to look and function the same on every browser. And I already knew how to put in IE hacks for specific versions of IE. Alright, I can do this.

In the end it only took me about 30 lines of IE6 specific css to get something that looks and works ok there. Was that because it is normally “just that easy”? Honestly, I doubt it. I suspect that there were many things I took into consideration when doing my layout based on years of getting burned by cross-browser hell.

It is mostly about the box model. The box model between IE7 and Firefox 2 (or 3) isn’t so different as to make you want to throw your computer out of a window. The box model in IE6 is extremely different. Padding is your enemy (every knows that now, right?): IE6 add padding to the overall width of your element (counter to the W3C standard I believe). I also just discovered that IE6 doesn’t support fixed position elements (other than backgrounds). This was the first time I tried to use fixed position items (I’m guessing I never tried before, since I *couldn’t*). The only other item(s) I had to deal with were all the alpha-trans png backgrounds I had. I absolutely refused to muddy up my html by including them all as images to run through the IE AlphaImageLoader, so I ended up just removing any of the transparency images from the IE6 layout entirely.

The one caveat I made in changing my design was modifying my main background image: it became a transparent gif instead of png. I know I’ll regret it at some point when I want to change the background color and have to go re-matt the image, but hopefully by then IE6 will have died a merciful death and I can have my alpha transparency back.

Even though Safari and Opera have a collective ~5% of the market, I still took the time to review layout/function in them both. They both look great. There’s a little functional weirdness in Opera, but I think that might have more to do with their JavaScript engine than rendering engine (further research is required). And frankly, the weirdness is small enough, I probably won’t bother. I’m sure if a client were paying me to, I would, but I don’t believe a client has *ever* paid me to “make it work in Opera”. It would be kind of novel to have a client actually care about Opera.

So, to wrap up: yeah, the horrible days of the late 90’s are behind us. We don’t have to spend months and months getting our site to WORK in both browsers (let alone LOOK the same). And someday soon, IE6’s market share will drop low enough as to drop off our development radar. Of course, then I will probably have to listen to up-and-comer developers complaining about the difference in sub-pixel rounding between browsers like it’s the end of the world.

©Copyright 2008 - B. Ernesto Johnson
sitemap