Question

For the last hour and a half I’ve trace Javascript calls in a Magento shop I’m building, because I have the strange effect that, when checking out, I can not leave page 2 (shipping address) of the onepage checkout, unless I switch from “send to this address” to “send to another address”.

I’ve traced it down to this piece of javascript code in form.js, residing in Regionupdater.setMarkDisplay (line 254 ff.)

Since I’m a jquery man myself I’m not really in the loop with prototype functionality but I’m assuming .up and .down are practically what jquery does with .parent(s) and .children()?!

elem = $(elem);
var labelElement = elem.up(0).down('label > span.required') ||
                   elem.up(1).down('label > span.required') ||
                   elem.up(0).down('label.required > em') ||
                   elem.up(1).down('label.required > em'); 

elem is the region select field in the form.
I’m assuming it’s trying to find the label for this field (which exists). But both the “elem.up(0)” fragments apparently throw an

[Exception... "An invalid or illegal string was specified" code: "12" nsresult: "0x8053000c (NS_ERROR_DOM_SYNTAX_ERR)"]

I’ve no idea what triggers this.

Answer 1

You’re basically right about what up and down do. That line of code is picking the first matching element:

elem = $(elem);
var labelElement = elem.up(0).down('label > span.required') || // Up to parent, down to first span.required inside a label
                   elem.up(1).down('label > span.required') || // Up to grandparent, down to first span.required inside a label
                   elem.up(0).down('label.required > em') ||   // up to parent, down to first em inside a label.required
                   elem.up(1).down('label.required > em');     // up to grandparent, down to em within a label.required

…where in each case it stops with the first one it finds.

The error looks like it’s being thrown from a selector engine or something being passed a selector it doesn’t understand. None of those selectors is particularly cutting-edge, so that’s a bit strange. Are you using Prototype 1.7 RC2? Because the current released Prototype still only uses its own built-in selector engine (whereas 1.7 adds pluggable ones).

Ah! That’s it — look at the ids of the elements in that area. Do any of them have spaces or ‘#’ or ‘:’ in them, that sort of thing? I seem to recall a bug in the Prototype selector engine where it assumes fairly boring IDs… (Why are IDs relevant? Under the covers, the selector engine may use them when processing descendant or child selectors — for instance, when processing down calls…)

Update This (fixed) bug may relate to this, if you’re using an older version of Prototype you may still be running into it. Definitely worth looking at the IDs.