We Keep Coding

Understanding focus on divs

I feel like I understand focus():
When trying to focus on a form element, like input, it "just works", so long as the document is ready.
When trying to focus on a non-form element, like div, you must add a tabindex attribute.
tabindex adds the ability to tab to an element in precedence order (higher number the better), 0 and up. However, there's a special value, -1, that explicitly removes the element from the tab order.
When calling focus programmatically, do so within a setTimeout.
Be sure to make a setTimeout value large enough that it waits for display animations to finish, but not so late that the user has time to do other things, like click or type elsewhere.
Pretty simple, really, right? But no. It just doesn't work for me.
My specific use-case is that I have a key-nav-enabled widget that, if you hit the right key, opens a pop-over modal widget. It works great. But I can't get that modal widget to take focus. That modal widget that has no form inputs (just some text and a close link). I've added keydown/up/press events to the modal widget, I've added tabindex to various nodes and tried to focus them, but the original widget still gets the keyboard events.
DOM-wise, the modal widget, despite being new'd up within the keynav widget, is attached to the DOM at the body level, so it's not like the keyboard events are bubbling up through my modal dialog and should be stopPropagation'd, it's never getting those events.
What this means is that if you hit another key before you click in the modal widget, it opens a different modal dialog underneath the first modal dialog!
I really hope I'm missing something about focusing divs, because I have several pieces of functionality I'd like to implement that just aren't working due to (I believe) focus requests simply being ignored.
Help! What am I missing?

In the specific case I was sleuthing out, I effectively had a typo.
I was doing this, which wasn't working:
setTimeout(lang.hitch(this, this.domNode.focus), 100);
But this worked:
setTimeout(function() { this.domNode.focus() }, 100);
That said, I've had a number of issues with focus that regularly make me dread ever having to use it programmatically.
Hopefully though, the list of tips in the question will be helpful to someone.

Give focus to browser

I'm working on keyboard accessibility. I have a flash object which sits inside a page, and to stop the focus getting trapped inside it, I've added tab listeners which talk through ExternalInterface to some JavaScript functions.
The JavaScript looks for the next available element with a tabIndex and calls focus() on it. So far so good. But if the plugin is the last tabbable item on the page (or first when reverse-tabbing), there is no element to switch to. Normally this would set focus to the browser window, so I'd like to keep that behaviour.
Hence my question: Is it possible to programatically give focus to the browser's chrome? Even better if I can mimic both forward and backward tabbing. Also I'd like to avoid adding extra tabbable components before/after the flash if possible, unless I can make them effectively invisible to both the mouse and keyboard.

Came across this in my own search for a similar answer. If you want to release the focus on the currently focused element, use document.activeElement; If you want a fallback in the off chance its not supported, use focus on the parent element of the document. This should support all known browsers, as far as I know:
var activeElement = document.activeElement;
if (activeElement) {
activeElement.blur();
} else if (document.parentElement) {
document.parentElement.focus();
} else {
window.focus();
}

Setting the focus to a dummy anchor with no text content, at the top of the document, seems to work:
document.getElementsByTagName('a')[0].focus();
http://jsfiddle.net/4NA5u/1/.

Using JavaScript, how can you tell if a user is tabbing backwards?

I've got an HTML link, and I want to take some action when the user tabs away from it - but only if the user is tabbing forwards through the document, as opposed to backwards.
Is there a reliable cross-browser way to detect which way the user is tabbing through the document, or indeed if they're tabbing through the document at all? I'm binding to the blur event, but that doesn't necessarily mean that the user is tabbing.
I've had a look at inspecting the value of document.activeElement, or the hasFocus attribute of the previous focusable element in the source, but:
those seem like relatively recent additions, and thus might not be widely supported, and
I'm not sure they'll be inspectable when the blur event fires, as even if the user is tabbing, I don't think the next element will be focused yet.

You will have to handle keydown event on the link itself.
$("your link selector").keydown(function(evt){
if (evt.which === 9)
{
if(evt.shiftKey === true)
{
// user is tabbing backward
}
else
{
// User is tabbing forward
}
}
});
Check this JSFiddle example that detects forward and backward tabbing on a particular link.
Sidenote: You didn't specify jQuery tag on your question al though I provided jQuery code in my answer. Since you hold Javascript as well as jQuery badges I suppose it's going to be trivial for you to convert my code to pure Javascript.

As an alternative to a good solution from Robert, maybe you can leverage tabindex attribute? Set it for your html links and other “tabbable” items. Then check it in javascript.
Solution with tabindex: jsfiddle
Side effect: Elements will also react on mouse clicks. They will behave correctly. So this might be a good side effect or bad side effect depending on your needs.

Javascript context menu click event/detection - filter paste content

Scenario: I'm trying to intercept paste events inside a textarea/input text, and filter the content being pasted.
Webkit/IE are handled rather well, as I can attach code to the onpaste event, and then read from the clipboard what is being pasted. Plenty of examples around.
Gecko is trickier, because as far as I know it isn't possible to read the clipboard content on Firefox (unless somebody knows a workaround for that?)
I just use the input swap trick for that.
Opera is being annoying tho. I can trap CTRL+V and SHIFT+INS, but there's no onpaste event.
Not to mention any sort of clipboard interaction, apparently.
So, my question is:
Can I detect if the user clicked on paste in the context menu on Opera? Is there any other way to detect the event?
EDIT:
Thanks everybody for the answers - they all add a good input, even if there's no definitive solution.
Having to choose, I'll pick the only one that tried to address the original question, and that would probably work if it wasn't too much of an hack to even try.
Notes for those that have my same problem (input filtering):
it is possible to capture content being dragged: mouseup + setTimeout does the trick everywhere almost perfectly.
without flash, there is probably no solution bar polling. Even with flash, it's not a completely solid solution either. Too much effort to support 100% of the cases.

I ran into this last year. In short, no.
I ended up using an onchange handler and filtering the content after it's already been pasted into the text box.

You can intercept the paste with jQuery using the bind('paste', function() {});, compare string before and after pasting and apply your formatting.
The following was tested in IE7/FF3.6/Chrome/Safari 5
$("#textarea").bind('paste', function(e){
// Do whatever you needed to do with the code here.
});
Live Example http://jsfiddle.net/VSrTg/2/
Edit An approach would be something like this:
$("#textarea").bind('paste', function(e){
var oldText = this.value;
setTimeout(function() {
// Compare oldText to $("#textarea").val() and format accordingly.
}, 1000);
});
​Edit 2 Given your revisions to your original post, if you're worried about the giant market share that is Opera, you're going to have to monitor the value of your textbox with a setInterval() and compare it against itself for changes.
Ultimately there will always be a way around your script, even the above example is susceptible to simply dragging text from another text box (or the address bar) into it without triggering the paste event defined above.

I would like to point out DOJO menu widget that is creating context menus perfectly in different browsers. http://www.dojotoolkit.org/reference-guide/dijit/Menu.html#dijit-menu
What you can do is that detect paste event in browsers that are supporting it and override context menu in browsers that are not supporting this event like opera.
Once you create your own context menu then you can add copy paste menu item or create context menu similar to the default using css.
Edited
Some browsers might not allow us to fetch clipboard content, in this case we can always revert back to flash for borrowing some of its features that are cross browser. See couple of links I posted in comments.
Its complete implementation might have more issues than anticipated but it is possible and we can always give it a try (I will for sure).

The answer to the question is a simple no. The main browsers that have no paste event are recent versions of Opera and Firefox 2. Given that there is no paste event, you need to find an alternative event or set of events to detect a paste from the context menu as it actually happens. You can add handlers for every event there is (I've done this) and you simply get nothing in the relevant browsers when a paste is triggered from the context menu by the user.
This only leaves polling the text input's value regularly, which is not the same thing. You could keep track of keypresses and observe in your polling code that the text input's value has changed by some means other than keyboard input and do a diff, but that's hacky and unreliable.

I use the setTimeout for paste events. But for context menu select nothing seems to work(as stated above). I bind a mousemove to the input's form which fires the update function. Then unbind/bind so they don't stack up.
This handles the context menu select and dragging value to input field.
If your form is small, say with only one input field and the mouse will not land on it after selecting from context menu, bind to the form's parent or document. Sure, it has to wait until the mouse moves but that is the general user action after selecting from context menu.
Works fine.

jquery desktop blocking input and textarea

I'm trying to modify this: jquery desktop
by adding a input field inside one of the windows. However, I can't type anything into the input. I opened firebug and the classes are flashing when I click the text input so I'm guessing that's what's blocking it. But I don't know how to fix this. Any help is appreciated.

In his very long article, do a page search for 'Cancel mousedown'. You'll see he's canceled any mousedown event that's not a link. That's what you'll have to alter to make it usable. You could either delete the whole thing (the point was to bind a context menu, which he ended up not doing) or add input as an exception like a is.