Interesting Quirk
Just ran into an interesting quirk with Inman positioning.
I was using it with Safari 3, and noticed the same bug in Firefox 2.0.0.11 while testing. I loaded the javascript file in the document head and when the document started to load,, apparently it loaded a document and triggered the script before the body had loaded. The script failed, claiming document.body was null.
After ripping out handfuls of hair (”Whaddya mean null? I can see the tag right there! Open your eyes you stupid machine!”) I realized the timing issue and moved the script deeper into the document, so it would be triggered after the body tag was loaded.
Success.
Hmmm, my reading of this makes me think you had
foo.html:
foo.js:
document.body.innerHTML = “blarghy”; // or whatever
In which case firefox and safari are both correct. A script element with a src attribute basically inlines the src in the document, producing:
document.body.innerHTML = “blarghy”; // or whatever
Which is spec’d to execute the JS at parse time — eg. before the head has been closed, or the body element started/created. A much more sane/correct approach is to have such logic registered as an onload handler for the body.
Comment by Oliver — 1/21/2008 @ 4:32 pm
*sigh* it would appear wordpress decided to just clear any and all html content rather than escaping it, or providing a preview.
Comment by oliver — 1/21/2008 @ 4:40 pm
Probably my settings are doing it. I’m tired of this site getting targeted by folks wanting to play spam games, so I tightened down the hatches a bit more, perhaps, than necessary. But considering how much time I’ve spent lately cleaning out pollution from some West African incursions, I think the question is not whether I’m paranoid, but whether I’m paranoid enough.
There are limited HTML tags available in the comments, but I don’t have anything set up to auto-escape the code. If posting code here becomes more popular, I’ll do something about it.
To the point: Yes, I think you’re right; registering it as an onload() handler is more correct. In my defense, the task at hand was the first build of a new design, and I was just trying to stack the blocks and go, leaving the mortar and trim until I had a basic design structure I liked. So I popped the IP js into the CMS, told it where to include the file, and moved on.
What made this a bit more complicated was I had been working with a Beta of Safari 3 for a while, and a couple of the beta builds calculated the height of the boxes incorrectly (in javascript, on the browser display they were the right size — CSS took the font size down to 85% but JS calculated the box height as if the font were 100%) thus making a complete mockery of the positioning code. I spent some time at the beginning of this trying to prove/disprove I was seeing a recurrence of this beta bug in 3.0.4. So I let myself get caught up in debugging both the browser and the javascript, and wasn’t thinking in production terms.
I think the most proper approach from me would have been to ignore the problem as it presented itself, and just kept stacking blocks until there was something worth making a decision about, and only then gone back to fix the code. But I love debugging, and sometimes the temptation is too much to resist.
Comment by arlen — 1/22/2008 @ 1:32 pm
And of course if you do find bugs you can always file them at http://bugs.webkit.org
Comment by Oliver — 1/24/2008 @ 12:35 am
Not a bug, in this case. It’s allowed behavior to load a script before the body element is complete. I believe I did file the bug under the beta version when I discovered it. (Incidentally, it is fixed. I confirmed that when I first thought it had returned.)
Comment by arlen — 1/24/2008 @ 2:04 pm
[...] Oliver there is a bug in Safari3. It’s a javascript issue, to be precise. And it’s [...]
Pingback by Theodicius » Bughunting Safari 3 — 2/11/2008 @ 2:53 pm