Theme by nostrich, altered by Tyches.
Text
Today I had a weird bug. In a web app, I have a form which contains a generated table of children items of a given item. This table has some dynamicity in that you can add and delete rows dynamically via DOM and JavaScript, then you submit the form and Castle ActiveRecord/MonoRail does its magic. It worked well with IE and FF on my Windows work machine, but deleting a row failed in a weird way with Safari on my home Mac.
First I supposed there was some peculiarity with the database, as I use MSSQL at work and SQLite3 at home (thanks NHibernate). Then I tried Camino, and it worked. Therefore it’s that freaking browser, not the C# backend. Observing the DOM status with Safari’s Web Inspector, I noticed that the rows were properly deleted by JS (before even validationg the form). Huh.
Then I noticed that there were some elements that persisted although the tr were deleted. Those elements then were passed to POST and the “deleted” rows persisted to the database. As I deleted the rows, the content disappeared, leaving me with an empty, but existing row in place of the old, filled one which should have been deleted.
Now here’s the cause. In the form I placed a hidden input field for the form to pass the id of a given row. As it was not supposed to be shown, I placed it in between the tr and the first td, thus in a row, but not in a cell. This is where the difference lies between the browsers: while IE and FF+Camino’s Gecko happily leave it there and have the whole tr deleted, including the hidden input, Safari’s WebKit (in an supposed effort to make the page somehow compliant with something) actually moves the hidden input field out of the table tag, in fact right before it, thus the only content deleted is the one inside td, because everything else gets thrown out of the tr.
So I put the field in a td. Fixed. Damn, yet I’m happy to have some tools like FireBug and Safari’s Web Inspector.
