Don't Blame The Browser

Monks, I must repent. I blamed the browser, but the fault was my own. QA reported to me that after accessing a particular page in Krang a few times IE would get really slow and then crash. This page has a lot of Javascript on it, so I figured it was probably another IE Javascript bug. I played with it a little in IE and confirmed the crash, but I didn't know what else to do.

My theory lasted until QA told me it happened in Safari on the Mac too. Then I tried it in FireFox on Linux. Same deal. After simply submitting the form 3 times the browser became unusable and eventually crashed. So much for the IE sucks theory.

In this form, if the user doesn't make any edits then submitting the form should return them the exact same HTML. I decided that I wanted to make sure that was really the case. My co-worker, Peter Leonard, suggested I use HTTP::Proxy to monitor the connection between the browser and the server. I did and was able to log each successive response to a separate file. I then ran a diff of each response. The results showed the problem clearly. Where there should be a single hidden field I saw around 50 hidden fields concatenated together. On each request the list of hidden fields grew longer. The name on the hidden input tags was "name".

Eventually I found the problem code:

  return scalar $query->hidden(name     => $param,
                               default  => ($element->data() || ""),
                               override => 1);
[download]

It looks like a call to the CGI::hidden method using named parameters, doesn't it? But CGI.pm requires named params to start with '-'! This call was being interpreted as a request to setup a hidden input called "name" and without the "-override" option that will pull in whatever CGI::param() has for "name"! Thus, each time the form is submitted the list of hidden fields grows. Eventually it grows so large that the browser can't handle it.

Three dashes later and the code was working again:

  return scalar $query->hidden(-name     => $param,
                               -default  => ($element->data() || ""),
                               -override => 1);
[download]

-sam

Comment on Don't Blame The Browser Select or Download Code

Replies are listed 'Best First'.
Re: Don't Blame The Browser by FoxtrotUniform (Prior) on Jun 11, 2004 at 03:17 UTC
Monks, I must repent. I blamed the browser, but the fault was my own. QA reported to me that after accessing a particular page in Krang a few times IE would get really slow and then crash. This page has a lot of Javascript on it, so I figured it was probably another IE Javascript bug. Hunt and Thomas' book The Pragmatic Programmer has a section on the general case of this tendency, which they call "`select` isn't broken". The gist of it is: if there's a bug, it's probably in your code, not the browser, window manager, operating system, or what have you. Not always true, of course, but good to keep in mind. Excellent book, btw. `-- F o x t r o t U n i f o r m Found a typo in this node? /msg me % man 3 strfry`	[reply] [d/l]
Re^2: Don't Blame The Browser by drewbie (Chaplain) on Jun 11, 2004 at 04:44 UTC
You reminded me that I need to get that book off my wishlist and onto my bookshelf! Perhaps there will be a copy at YAPC... I've only read good things about what they have to say. I recently read their new version control book, and it's a good introduction to the concepts behind version control, branching, etc. Not quite a meaty as I had hoped about branching & merging, but adequate nonetheless.	[reply]
Re^2: Don't Blame The Browser by water (Deacon) on Jun 12, 2004 at 23:19 UTC
The bug is never in MY code. Nope. Never. Hasn't happened once. I just wish they'd get around to fixing `select` and IE which are messing everything up -- those slackers. `<g>`	[reply] [d/l] [select]
Re: Don't Blame The Browser by exussum0 (Vicar) on Jun 11, 2004 at 00:59 UTC
I use HTTP::Proxy to monitor the connection between the browser and the server. For doing web development that's not browser specific, I like using mozilla (or firefox). You can inspect the form specifically, by second clicking. left click for you lefties. Also, using liveheaders to get the parts you can't see is always helpful. Bart: God, Schmod. I want my monkey-man.	[reply]
Re^2: Don't Blame The Browser by drewbie (Chaplain) on Jun 11, 2004 at 02:55 UTC
And related to this, later versions of Mozilla (1.6+?) allow you to reload the View Source window w/o closing it, refreshing the browser, and viewing the source again. Quite handy when you're tweaking things and want a fast way to see your changes.	[reply]
Re^3: Don't Blame The Browser by samtregar (Abbot) on Jun 11, 2004 at 03:00 UTC
I tried to View Source after the browser was half-way baked. It nearly took down my entire machine. Memory usage shot past 600MB! -sam	[reply]
Re^4: Don't Blame The Browser by drewbie (Chaplain) on Jun 11, 2004 at 03:08 UTC
Re^5: Don't Blame The Browser by samtregar (Abbot) on Jun 11, 2004 at 05:22 UTC
Re^2: Don't Blame The Browser by samtregar (Abbot) on Jun 11, 2004 at 02:58 UTC
It's hard to use FireFox to inspect the form when FireFox is using 400MB of memory and won't respond to mouse input! -sam	[reply]
Re: Don't Blame The Browser by etcshadow (Priest) on Jun 10, 2004 at 23:01 UTC
Been there, done that. Well not the same specific bug in my server code... but I've blamed IE for my bad server output in the past. Of course... I'd be less inclined to do that if IE weren't so generally busted. `------------ :Wq Not an editor command: Wq` [download]	[reply] [d/l]
Re: Don't Blame The Browser by Anonymous Monk on Jun 11, 2004 at 01:25 UTC
I _always_ use a hash ref when calling CGI methods: $query->hidden ({name => $param, default => ($element->data() \|\| ""), override => 1, }); No nasty '-'s for me. Ron Savage	[reply]
Re: Don't Blame The Browser by swngnmonk (Pilgrim) on Jun 11, 2004 at 16:07 UTC
As the guy who recommended HTTP::Proxy to Sam, I feel I need to put in another plug here. Yes, "View Source" is useful, but it's not always enough. "View Source" won't tell you about redirects, it won't tell you if your headers are hosed (on either end), it won't tell you exactly what you're submitting (correct or not). A proxy server will do just that, and it's completely transparent. Besides, it won't crash when your pages get huge. Sam's proxy server was about 15 lines long, and that's only because he made it more complex than he actually needed in this case. It took him 15 minutes tops, and I doubt he'll need to make any changes the next time he uses it. It's a good tool to have in the toolbox, folks - you can't always depend on your browser to tell you what you need to know.	[reply]
Re: Don't Blame The Browser by cosimo (Hermit) on Jun 11, 2004 at 11:42 UTC
Your post is very interesting and highlights a very common behaviour among programmers (me too :-). But, honestly, can you name only one web developer that didn't have to fight hard against IE bugs? (Broken HTTP redirection in IE5 is my favourite...)	[reply]
Sometimes You Should Blame The Browser by tilly (Archbishop) on Jun 11, 2004 at 20:39 UTC
First of all I wouldn't hit that bug because I don't like the CGI form-field methods. I'm not alone. But let me give an example of one of those "IE JavaScript bugs" that you mention. And how to work around it. I was doing some moderately sophisticated JavaScript stuff (couple of form elements interacting with each other) and created closures that referred the page form, and then assigned them as actions on form elements. IE would run slowly, take tons of memory, and then crash. I could not reproduce the problem on Mozilla. The problem turned out to be that both IE and JavaScript use true memory managers, but different ones. So when cleaning up JavaScript, anything that is referred to by native widgets is not cleaned up. And when cleaning up native widgets, anything that is referred to by JavaScript is not cleaned up. I, of course, had a cycle with native widgets referring to JavaScript that referred back to the form that those widgets were on. Neither memory manager would clean that up, so the page would leak. After some active use, well you see the problem. The work-around is to never have a variable referred to within a function refer directly to a native form widget. Instead remember widgets by name, and dynamically look them up in the form each and every time. That or convince people to not use Internet Explorer. :-/	[reply]
Re: Don't Blame The Browser by drewbie (Chaplain) on Jun 11, 2004 at 03:00 UTC
I HATE it when I do that! I have the view source window open half the time to help me avoid major bang-head-on-wall time when I'm doing buckets of hidden fields. As someone else mentioned, livehttpheaders on mozilla is a wonderful thing if you need to debug exactly what's going on between the browser and server. Not that it's much help on IE...	[reply]