I'm running this code in Firefox 11 on Windows 7. (See http://jsfiddle.net/QStkd/).
$('<div><input type="text" value="val" /></div>').dialog();
The value in the input isn't selected, which is does do in Chrome and IE, it also doesn't work if I manually call the select() method.
Is this a known problem? Is there any way to select it? Timers work but if I click run on jsfiddle after it loads it doesn't work anymore.
It looks like calling focus() (which jquery-ui does by default to the first tabbable element) on Chrome (can't test IE -- on OS X) focuses the box and selects the text within the box.
Taken from jquery.dialog.ui.js:
// set focus to the first tabbable element in the content area or the first button
// if there are no tabbable elements, set focus on the dialog itself
$(self.element.find(':tabbable').get().concat(
uiDialog.find('.ui-dialog-buttonpane :tabbable').get().concat(
uiDialog.get()))).eq(0).focus();
Firefox, on the other hand, seems to only place the cursor within the box when calling focus. Therefore, you must call implicitly call select after the dialog has been created in order to achieve what you're looking to do.
If you reload your timers fiddle (as opposed to clicking run), you'll notice the example works every time. I think that jsFiddle is actually the culprit here (possibly the hashchange event, or some focus event on one of the panes after you press 'run' -- I haven't dug that deeply).
EDIT: (sorry, it's late) Looks like the root cause of the "problem" is Firefox. Not sure if this is designed behavior or not, but from what I can see, it looks like Firefox will not allow text to be selected in two different input elements within different content panes at the same time on the same page. This doesn't seem to affect Chrome (and, assumingly, IE9).
I made a quick example locally that has two iframes side by side (let's call them left and right). Left contains a textarea, and right contains your jquery-ui dialog -- similar to the fiddle you posted. right has the following code:
<script type="text/javascript">
$('<div><input type="text" value="val" /></div>').dialog();
$('input').select();
</script>
left has the following code:
<script type="text/javascript">
setTimeout( function() {
$('textarea').focus();
}, 1000);
</script>
If you piece these together and check out the result in Firefox, you'll notice that the input is focused and selected until the textarea in left is focused. I suspect something akin to this is happening in jsFiddle.
Try to use open event of ui dialog.
This event is triggered when dialog is opened.
$('<div><input id="yourInput" type="text" value="val" /></div>').dialog({
open:function(){
$("#yourInput").focus().select();
}
}
)
http://jsfiddle.net/sergeir82/A6Wah/8/
http://jsbin.com/etivej/4/
This is a FF issue in the dom determining if you have set the DOCTYPE. There is not a great way to fix it, a timer to focus tends to be the "hack around". However there is another step, if your Doctype is set to w3 xhtml standards you can use this to get it selected on focus. Add onfocus="this.select();" as a property of your input, so that when it is focused, it is immediately selected.
Related
This one is IE specific (not anymore, apparently). We have very simple code:
<div draggable="true">
<p>Text</p>
<input type="text"/>
</div>
On Chrome it works fine, you can select all text inside <input>, eg. double-click it or click-and-drag. On IE10 you cannot do both of these actions (not sure about IE in other versions). Any ideas?
Fiddle: http://jsfiddle.net/s5g4gr8g/
This was reported as a bug a few months back and is currently being considered for a future release.
One of the hold-ups is that we are unable to determine the impact of the issue. I recall searching online and on GitHub for sites that relied on this pattern, but largely came up empty-handed. If you happen to know of any sites that use this, and are therefore broken in Internet Explorer 10 and 11, I would be happy to update the internal issue and request immediate action.
That being said, it does appear you can select text if you tab focus to the element itself, and then utilize the arrow and shift keys to perform your selection. You can also right-click the input control, which also places a cursor that you can then manipulate with your keyboard. It's not ideal, but it may suffice until we can resolve this from the browser-end.
One possible workaround to this solution is to remove the draggable attribute from the parent element in situations where you expect the text to be highlighted.
For instance in an application I'm working on, we show text in a span by default, then reveal an input when the user clicks on it to edit. At that point we remove the draggable attribute until the user is done editing, and then readd it.
That particular flow may or may not work for you, but if you can anticipate when the user might highlight, you can minimize the effect of the undesirable browser behavior. At minimum you can toggle draggable on focus and blur so that the user can highlight with the mouse if he's already editing the text.
The way Ben McCormick mentioned works good for me on the major browsers (tested with Internet Explorer 11, Firefox and Chrome).
For my solution you need to have an criteria to determine the parent with the draggable attribute (in my case I use a class name for that).
function fixSelectable(oElement, bGotFocus)
{
var oParent = oElement.parentNode;
while(oParent !== null && !/\bdraggable\b/.test(oParent.className))
oParent = oParent.parentNode;
if(oParent !== null)
oParent.draggable = !bGotFocus;
}
<div class="draggable" draggable="true">
<p>Text</p>
<input type="text" onfocus="fixSelectable(this, true)" onblur="fixSelectable(this, false)"/>
</div>
What we observed, if we blur out and focus again the issue is resolved. However moving cursor position is still not accomplished. But at least does the trick for single click.
$(document).on('mouseup', '#id input:text, textarea', function (event) {
$(this).blur();
$(this).focus();
});
I have a scrollbox similar to:
http://www.quackit.com/html/codes/html_scroll_box.cfm
Right now, you have to click inside it after the page loads in order to use arrow keys to go up and down. I'd like it to be so that on page load, the focus is inside it already so you don't have to click inside it to use arrow keys. Is there any way to do this?
Thanks!
the div is not focusable element so the focus function will not work probably, add tabindex attribute to your div to make focus function work fine.
<div id="yourDivID" tabindex="-1"></div
Depending on the value given to tabindex, it will behave differently:
0 will allow you to focus the element with the keyboard arrows and tab key
-1 will disable tabbing, but it will still be focusable
Anything greater then 0 will allow you prioratize tab focusing, where 1 has the highest priority
now you can use focus in the div
if you want to use Jquery
$("#yourDivID").focus();
if you want to use JavaScript
document.getElementById("yourDivID").focus();
Here is what you need exactly. Note that there are a few key things playing here. First the body of the document needs to have the "onload" property calling your small simple script for "Focus". And the only change that I made to your code is the addition of an "id" property to the div. You can change this to suit your needs.
Enjoy!
<body onload="Focus()">
<div id="myDiv" style="height:120px;width:120px;border:1px solid #ccc;font:16px/26px Georgia, Garamond, Serif;overflow:auto;">
As you can see, once there's enough text in this box, the box will grow scroll bars... that's why we call it a scroll box! You could also place an image into the scroll box.
</div>
<script type="text/javascript">
function Focus()
{
document.getElementById("myDiv").focus();
}
</script>
</body>
You can see this working by simply copying this code onto a brand new text file and save it with an .html extension. Then double click on it and it should open up in any of your browsers. Provided you have scripting enabled then it should scroll just fine.
On DOM ready, simply set the focus:
$("#yourTextboxID").focus();
Given the following code:
<html>
<head>
<script>
function updateTabIndex() {
setTimeout(function() {
var elem = document.getElementById("id1")
elem.setAttribute("tabIndex", 2)
elem.setAttribute("value", "now: tabindex 2")
}, 100)
}
</script>
</head>
<body>
<h1>Weird Behaviour When Changing the tabindex in onchange Handler in Internet
Explorer</h1>
<p><input id="id1" tabindex="-1" value="tabindex: (-1)"/></p>
<p><select tabindex="1" size="1" onchange="updateTabIndex()" onpropertychange="updateTabIndex()">
<option>tabindex 1 - an option</option>
<option>tabindex 1 - another option</option>
</select></p>
<p><input tabIndex="3" value="tabindex 3"/></p>
<h2>Instructions</h2>
<ol>
<li>Open this page in IE. To be precise, the problem is reproducible in
(at least):
<ul>
<li>IE 8, Version 8.0.6001.18702CO on Windows XP and</li>
<li>IE 9, Version 9.0.8112.16421 on Windows 7 Professional, 64 bit</li>
</ul>
<li>Use the <em>mouse</em> to change the value of the select box.</li>
<li>As you can see, the onchange handler is called and changes the tabindex
of the first input element.</li>
<li>If you now tab out of the select box, you can see that the tab order is
adhered to correctly: you go from the select box to the first input element
and then to the last element on the page.</li>
<li>Close the page and open it again.</li>
<li>Click on the third input element and press Shift + Tab to enter the select
box.</li>
<li>Use the down arrow key on the keyboard to change the selected value in the
select box.</li>
<li>Now tab out of the select box.</li>
<li>As you can see, the onchange handler is called, as before (the text in
the first input field has changed).</li>
<li>However, if you tab around now, you will see that the tabindex attribute
is ignored. Instead the order of the elements in the document source is used
as the tab order.</li>
<li>Even if you change the select box value with the mouse now, the tab
order remains broken. To test again, you need to close the page and open
it again or reload it by entering the url bar and pressing enter. Hitting
F5 will not be enough.</li>
</ol>
</body>
</html>
IE ignores the changed tab order when the select box value (which triggers the change to the tabindex attribute) is changed by some keyboard action (arrow keys) but does not ignore the tabindex change when the select box value is changed with the mouse (see more detailed explanation
about the expected and perceived behaviour in html above).
Why does IE behaves like that? In particular, why is the behaviour different when using the mouse and when using the keys. Is it a bug in IE? Right now, I'm pretty sure it is a bug in IE here, but of course there is also the chance that I'm doing something wrong which just happens to work as expected in FF.
I already googled quite a bit, but as far as I can see, this bug (if it is one) has not been reported or discussed anywhere until now.
Some remarks
First of all, Firefox does not exhibit this weird behaviour.
Just to avoid being misunderstood, it is clear that, when I tab out from the
select box, I'll get to the to the input with tabindex 3, because the
asynchronous code in the onchange handler might not have been executed yet.
But after that (when the text in the first input has changed), I expect the
new tab order to be established. This is how FF behaves.
It seems that IE already fires the onchange event each time I use the up/down
arrow key and not when I leave the select box (as FF does). I'm not sure if
that is related to the problem.
Added Bonus: If you open the IE developer tools you will see that the tabIndex
attribute is set correctly in the DOM, also when changing the select box value
without the mouse. But the tabindex is ignored when tabbing around.
My (naive) guess is that IE keeps an internal representation of the taborder
and that this internal representation is not recalculated correctly in this
case.
More weirdness: You can delete lines 5 and 9 of this file (setTimeout call and
closing curly brace), so that the tabindex change is no longer called
asynchronously. It then works correctly if you enter the select with the mouse
and leave it by tabbing out. It still breaks if you tab into the select change
the value with the arrow key and tab out.
In the JSFiddle, changing your code to set the JavaScript property instead of the attribute seems to help...
elem.tabIndex = 2;
// elem.setAttribute("tabIndex", 2);
A colleague of mine found an interesting workaround: Just add
elem.parentNode.replaceChild(elem, elem)
after setting the tabindex makes it work. Seems this DOM manipulation triggers a recalculation of IE's internal tab order which is missing otherwise.
While this is better than no solution, it's quite an ugly hack. :-(
If anybody knows a different, less brute force solution, I'd be still interested.
I encountered a similar issue when dealing with hidden radio buttons in IE 9. I set the tabIndex to -1, but you could still tab to the radio group. My workaround was to alter the CSS visibility property, which forced IE to ignore the group.
To conceal radio buttons from IE 9's strange tabbing behavior:
$radioBtns.attr('tabIndex', -1).css('visibility', 'hidden');
To reveal radio buttons and resume standard tabbing behavior:
$radioBtns.removeAttr('tabIndex').css('visibility', '');
Problem:
I have many drop downs with dynamic changes going on at all times. The problem is I am having to use the blur() method to disable focus so that the class depending on the selected value can be applied.
Is there a way I can set the focus onto the next drop down element.
Tried:
Instead of blur(), I have tried this but it did not work.
this.next(".Element").focus();
Current code:
$('.Element').change(function () {
var colour = $(this).find('option:selected').attr('class');
$(this).removeClass().addClass(colour);
this.blur();
}).change
JS Fiddle:
jsfiddle of my code
try to make this a jQuery object to focus another element
$(this).next(".keyTechElement").focus();
EDIT 1:
Seeing your DOM, changes is needed. The .next() function selects siblings in the DOM and inside <td> there is no .Element sibling.
$(this).blur();
$(this).closest('td').next("td").find(".Element").focus();
http://jsfiddle.net/UXJZ7/2/
I think manipulating focus with focus() or blur() is terrible for keyboard users.
Users also detest auto-tabbing on forms they rarely use.
Onchange doesn't mean a selection has been made, a user could be stepping through the options with the keyboard (or with assistive technology that simulates the keyboard like speech recognition software), you get an onchange event for every step in their selection.
You can get quite elaborate to work around this, but it's rarely worth the effort.
For your example, I'd just leave things like this: http://jsfiddle.net/KWvMZ/ It looks like the only reason you have a focus state in your style is to display the text with sufficient contrast, so I just set the yellow background to have black text when focussed and left it like that.
.
I am trying to add javascript to set Focus on a button, and hope to make the button look just the way it does when a user 'tabs' thru the HTML Form to reach the button.
The page that I am working on has an button element:
<input type="Submit" id="myBtn" class="myBtnClass >
In javascript function, I set focus to it using:
$("#myBtn").focus() When this function is invoked, I can see change of button image. Also, when I click 'Enter', the form does get submitted. However, in this case, when the image changes, I don't see the "Dotted inline" that generally appears on buttons.
but the dotted line Does appear when a user "tabs" to that button.
Am I expected to do anything other than $("#myBtn").focus()" ?
you can use css property:
`outline`
Could be running in IE7 compatibility mode, or using the wrong doctype.
See this similar question for more info and possible solutions: CSS 'outline' property in IE, and jQuery errors