We Keep Coding

Error using built version of Dojo (but not the uncompressed source)

I noticed something weird when using the uncompressed source of Dojo our code runs normally without error. I tried these two from the archives so far
dojo-release-1.10.6-src and dojo-release-1.10.8-src
However when I switch to the built versions, either
dojo-release-1.10.6 or dojo-release-1.10.8
There is an error that occurs when using dojo.query
TypeError: root.getElementsByTagName is not a function
My function call looks like this
var dom_frag = domConstruct.toDom(response);
var title = dojo.query(".accordion_title", dom_frag)[0];
where response contains HTML string. (too long to post here)
EDIT: Image of debugger showing contents of 'dom_frag'

Ok, have you checked to see if the dom_frag variable is a single dom node? If the dom fragment is multiple nodes, then the dojo.query won't work, because it needs to search the children of a single dom node.
To solve this, try wrapping the toDom contents with a single node... like so:
var dom_frag = domConstruct.toDom("<div>"+response+"</div>");
var title = dojo.query(".accordion_title", dom_frag)[0];
This is, of course, a bit of a hack... but if you can't guarantee that the response will end up a single node, then you need to do it.

Make sure your root is actually a DOM element as:
the Element.getElementsByTagName() method returns a live
HTMLCollection of elements with the given tag name. The subtree
underneath the specified element is searched, excluding the element
itself. Ref.

Is using THIS more efficent than using the selector?

I have a simple form so user send his vote.
There I need to know what radio button user select.
The version I found to solve it was this. How can I get which radio is selected via jQuery?
value = $('input[name=vote]:checked', '#frmSurvey').val();
This work ok. Even when I dont understand how that work, because in Jquery selector documentation there is only 2 example with item separated by coma. And neither match my example where each element is inside a quote and then a coma
.class , .class ---> $(".intro,.demo") All elements with the class "intro" or "demo"
el1 , el2 , el3 ---> $("h1,div,p") All < h1>, < div> and < p> elements
Both looks like OR selector instead of find A and then find B inside A.
So if anyone can tell me what kind of selector is that I would love to take a look into the documentation
Now the optimization I was thinking. If I already inside a function for #frmSurvey won't be faster if I use the this element
$('#frmSurvey').ajaxForm(function () {
value = $('input[name=vote]:checked', '#frmSurvey').val();
console.log('working way ' + value);
value = $(this).find('input[name=vote]:checked').val();
console.log('testing way ' + value);
But I couldn't make the second version to work. Second value get me undefined.
So how I fix second version?
And would be second version better than first one as my instinct suggest or I'm worrying too much?

Your first example shows a selector operating from a context selector, whereas the documentation you've shown shows a "multiple selectors" selector.
You seem to have partially grasped this as
value = $('input[name=vote]:checked', '#frmSurvey').val();
is essentially the same as
value = $('#frmSurvey').find('input[name=vote]:checked').val();
However, the context of "this" inside your function is not clear as it depends upon how the ajaxForm plugin is coded. It isn't necessarily the result of your initial selector. After a short play with the plugin, it would appear that this in the context of ajaxForm is the jQuery ajax request object.

jQuery: window.opener makes a difference

I'm working on localhost (so would expect to not have any domain-related probs as here).
On a page I'm using a bit of JS to modify the content of a span in the opening-window. It does not work.
When checking my code to find the control, it works (using FF dev-tools calling my Increment-function or checking the console.log-output): $('#uploads_Count')returns an object of type HTMLSpanElement. However, trying to access the same control from an opened window's console with window.opener.$('#uploads_Count'), this returns an HTML-Document, seemingly the entire page. Why is this not working, what am I missing here?
Here is function that is supposed to increment the counter contained in the span whose id is given as argument:
function Increment(ctrl)
{
var gef = $("#" + ctrl);
if (!gef) // did not find control, maybe on opener?
{
gef = window.opener.$("#" + ctrl);
}
console.log(gef);
cnt = parseInt(gef.text() , 10);
cnt++;
gef.text(cnt);
}
The HTML is trivial:
<span id="uploads_Count">0</span>

If $(selector) returns an element (such as HTMLSpanElement), rather than a collection of elements (would look like [<span id="uploads_Count"></span>] in most dev tools), then you're not calling jQuery.
Dev tools in A-grade browsers tend to introduce $ as a selector function. It is available in the developer console only.
If window.jQuery exists, then it's likely that jQuery.noConflict() was called, in which case you should use window.opener.jQuery.

Found it!
The way I checked if the control was found, was wrong. Instead of if (!gef)I should have used if (!gef.length). Found the explanation here.

Why creating the elements with custom tags adds the xml namespace in the outerHTML in IE9 or 10 until the .find() method is called?

I have a jsfiddle that demonstrates the question:
http://jsfiddle.net/H6gML/8/
$(document).ready(function() {
// this seems fine in IE9 and 10
var $div = $("<div>");
console.log("In IE, this <div> is just fine: " + $div[0].outerHTML);
// this is weird in IE
var $test = $("<test>");
console.log("However, this <test> has an xml tag prepended: \n"
+ $test[0].outerHTML);
$test.find("test");
console.log("Now, it does not: \n" + $test[0].outerHTML);
console.log("Why does this behave this way?");
});
Why does this happen? It doesn't happen in Chrome or Firefox. Is there a better way to fix this than to call .find("test") on the object?
Edit
To clarify, I'm not asking why the xml tag is added, rather, I'm wondering why the .find() call get's rid of it. It doesn't make sense to me.

Why does this happen? It doesn't happen in Chrome or Firefox. Is there a better way to fix this than to call .find("test") on the object
It is the IE causing the issue while doing document.createElement on an unknown html element type. It thinks it is an XML node and adds the xml namespace prefixed <?XML:NAMESPACE PREFIX = PUBLIC NS = "URN:COMPONENT" />. Instead if you try to make it explicit to mention that it is an html element, this issue doesn't happen.
Try:
var $test = $("<html><test/></html>");
The issue no longer occurs.
To clarify, I'm not asking why the xml tag is added, rather, I'm wondering why the .find() call get's rid of it. It doesn't make sense to me.
Now, when you do a find, jquery internally uses context.getElementsByTagName or (similar based on the type whether it is a class or a tag or id etc..) which means it does this operation on the element test. So in IE when you do that it probably internally resolves the fact that you are trying to perform the operation on an html element and not an xml element and it changes the document type for the underlying context(But i don't know why it changes the parent context though rather than just returning a match). You can check this out by this simple example as well.
var $test = document.createElement("test");
console.log("However, this <test> has an xml tag prepended: \n"
+ $test.outerHTML);
$test.getElementsByTagName("test");
console.log("Now, it does not: \n" + $test.outerHTML);
Demo
Update
Here is a documented way of defining the custom elements
The custom element type identifies a custom element interface and is a sequence of characters that must match the NCName production and contain a U+002D HYPHEN-MINUS character. The custom element type must not be one of the following values:
annotation-xml,
color-profile,
font-face,
font-face-src,
font-face-uri,
font-face-format,
font-face-name,
missing-glyph
So according to this had your tag name been somename-test ex:- custom-test IE recognizes it and it works as expected.
Demo

Why does this Prototype Code in Magento crash?

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.

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.

I have the same error, on IE8, but in my case it's not because of unescaped colon. I have the error because I'm using a custom theme that modified the DOM so elem.up(0) is pointing to other element.
You should look at skin/frontend/your_template/js/opcheckout.js at lines 420 and 428
functions setSameAsBilling and syncWithBilling or change your template file - shipping.phtml.
Also on default skin this error does not apear.