Sometimes it helps to speak Norwegian in New Zealand

Here's one of today's most puzzling problems: if you load http://www.dicksmith.co.nz/product/XC9017/samsung-23-quot-led-s23b350h.jsp and click the 'Check Store Stock' button, an empty box will appear. Only in Opera, though. Here's a small screenshot, Firefox in front to show what's supposed to happen:

So why's that happening? Well, the server sends us an empty page from the storelocator/include/inc_find_in_store.jsp script, that's why.

Our first steps are obviously to test all the usual suspects –

  • UA sniffing? No.
  • Script chokes on some other HTTP header? No.

Colleague Jeremy discovered that the only part of the request that made a difference was the value of the session cookie. If one takes the session cookie from a competing browser and sends it with Opera's request, it all works!


Taking over the investigation, I could confirm that with Fiddler's request composer – cloning one of Opera's requests and replacing only the highlighted value in this screenshot with a JSESSIONID cookie value from Firefox makes the script send the content we want.

So, was Opera's session cookie somehow wrong? No, the session cookie Opera sends by default is exactly what the site sent us in the first place. And there are no weird characters whose encoding might differ and make the server misinterpret Opera's cookie..

Now, if nothing about that request is wrong, there must be a problem with the session data stored on the server. That means Opera may have done something wrong earlier..

Looking very closely at the Fiddler session list shows a curious difference. When clicking the button, the first request is a POST to http://www.dicksmith.co.nz/product/XC9017/samsung-23-quot-led-s23b350h.jsp. This request is listed as 187 982 bytes for Opera but 189 208 bytes for Firefox's session..?

One rather nice feature of Fiddler is that you can send sessions to a diff program. Highlighting both sessions, right-click, compare and there you go – wonder what causes this difference in the form data?
How odd that there is a Norwegian phrase in Firefox's form data, but not in Opera's:

findSkuInStoreSubmit=Send+inn

Is that it?

Back to Fiddler, to set a breakpoint before requests are sent. I want to add those two words to Opera's form post to see if it works:

Disabled the breakpoint again, clicked "run to completion" and – success! Opera shows the store locator!

I know from the "Store locator" button's tooltip that it calls the setSkuId() method in a javascript: URL. The last part of our debugging is investigating that method, which is a pretty quick job in Dragonfly's console:

That's a pretty simple method, just sets a couple of form values, finds a hidden button in a hidden form and clicks it. In these AJAXY days you might have expected something fancier than re-loading the whole page with a form submit to show an overlay (one might also legitimately ask why they couldn't use the solid pre-AJAX technique to submit the form data straight to the IFRAME in the first place), but apparently many web developers were raised to ask themselves "why make your life simple when you can make it complicated?".

So, what happens when a script calls .click() on an invisible submit INPUT with a name but no value? Apparently, the browser should add the value that had been shown, had the button been visible. Nobody told Opera yet, but we'll teach it to behave – due to the curious fact that a site in New Zealand only worked for me when I sent it Norwegian words.

Advertisements

5 thoughts on “Sometimes it helps to speak Norwegian in New Zealand

  1. The successful value should be some localized string, yes. We do that when the button is visible, just noone thought of the display:none corner case..

  2. So it sounds like value for input type=submit should simply not be empty when not specifically defined. Because the Norwegian thing is just a locale, right?

  3. It's certainly not the first time layout affects form submits. It's not the worst such bug I've seen by far..Anne, you might want to nag Hixie&co because apparently (according to our dev), the spec fails to cover this in sufficient detail – seems there is nothing in the spec that covers the successful value of an input type=submit without a value attribute. Web compat requires that a value is sent.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s