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/.
Related
I am making a chrome extension to edit properties of images that are clicked on. I am using a package called element picker to select the images (this is triggered through an html button in a popup). The code works and I can change the properties of the image. However the package does not stop whatever action is linked to the image, which can often lead to the user being taken to a new page. How can I stop any of the actions of the users click between the time they press the button in the popup and they have selected an image?
Thank you in advance.
var elementPicker = require('element-picker')
function onClick(elt) {
[.....]
}
elementPicker.init({ onClick })
I don't usually recommend using this but CSS pointer-events can solve this problem. The idea is that any element with pointer-events:none will ignore any interactions. This works to block default HTML interactions like <a> or <button> as well as any javascript actions attached to the element.
This is the technique frequently used with a modal window to prevent clicks from going "through" the area around a modal. It should also work for what you described.
You could either set that style on the image element or on All Elements by using the * {styles...} selector. If you go the "all" route, you'll need to explicitly re-enable pointer-events on any elements in your extension interface that you still need actionable by using the 'auto' property.
Remember to reset pointer events when your extension is finished * {pointer-events: initial;} or you'll leave the page completely in-actionable.
If there is an Event object being passes through to the function then you could use the Event.preventDefault() function.
This function stops any default behavior and allows you to handle the event in your own manner.
Reference: https://developer.mozilla.org/en-US/docs/Web/API/Event/preventDefault
I'm using an onclick event to make an entire div a navigable link. This works well, until you use ctrl+click or middle-mouse click in order to open the target in a new tab. I find that a new tab does indeed open, but so does the current tab.
See what I mean by ctrl+clicking on one of the boxes here: http://mw.modhistory.com/download-1
I don't want to interrupt the ability to browse normally by always forcing it into a new tab...the user should have the option here. But I'd like to be able to quickly open a dozen of those links in new tabs without having to go "back" repeatedly.
I had what I thought was a brilliant idea to use preventDefault(), but that ended up doing the opposite of what I had in mind and entirely prevented the ability to open a new tab (which makes sense once I really thought about what it is meant to do.)
Any ideas? Thanks!
--Fligg
I'm assuming that either your event listener is sending events off to a routing/assigning function, or there aren't a whole lot of click events that you're looking to implement that AREN'T for this feature.
Either way, you can do something like:
// Assuming we already know what the purpose of the click was, and its target
function (e) {
if (!!e.ctrlKey) { /* CTRL was held during mouse-click */ }
else { /* not held */ }
}
As for mouse-buttons, they're pretty messed.
You should be fine using either:
e.which /* 1-based: middle-button is #2 */
or
e.button /* 0-based: middle-button is #1 */
Keep in mind that past support for figuring out which buttons were which was REALLY bad over the years.
If you've got a library that does the abstracting, use that.
Otherwise, other than offering this functionality to people with newer browsers, or compiling the previous values of which and button, it ends up at parsing browser versions, which is never, ever good.
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.
Forcing focus() on an element is easy, but after having debug issues, I realize trying to determine where is my focus gone is a lot harder.
The thing is I'm generating a modal window using jq.UI, and from time to time, while focus is supposed to be set on first input of the form included in the modal, cursor just disappears, to never show again unless I reload the page.
Is there a straightforward way to detect where my focus/cursor is?
You can see which element it's on by checking document.activeElement, for example:
alert(document.activeElement.innerHTML); //see the content to aid in IDing it
I'm not sure if the focus event bubbles, but if it does, you could try this:
jQuery('body').focus(function(e){ console.log(e.target); })
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.