Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?
 
PerlMonks  

Don't Blame The Browser

by samtregar (Abbot)
on Jun 10, 2004 at 21:34 UTC ( #363214=perlmeditation: print w/ replies, xml ) Need Help??

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);

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);

-sam

Comment on Don't Blame The Browser
Select or Download Code
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
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.

      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.
        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

      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

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
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...
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

      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.
      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>

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...)
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.

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. :-/

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://363214]
Approved by bart
Front-paged by diotalevi
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others studying the Monastery: (8)
As of 2014-11-28 18:07 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My preferred Perl binaries come from:














    Results (199 votes), past polls