I'm making a large and complex application and I need to set tabindexes to help user navigate through the pages. This is a private application so I don't have restriction about (ab)using javascript (jquery).
I currently have these questions.
1) How do you force with javascript (jquery) the browser to move the cursor inside a specific textbox as soon as a page has loaded? I noticed that often browsers don't automatically put the cursor inside the first tabindexed input. I want a surefire way that forces it there no matter what.
2) Some fields that activate ui enanchement (namely jquery ui datepicker) have problems with tabbing (like having to push tab two time to go away from it), is there any way to avoid this?
3) How do you read and set tabindex with jquery? I have some fields that get hidden/shown based on user action and they should be able to "give" their tabindex to other fields if they get hidden, is this a problem, does the browser still consider a tabindex after the page has loaded?
Thank you very muchh
To put focus on a specific textbox, do this (assuming textbox id is #firstBox): $('#firstBox').focus(); See more examples here: How do you automatically set the focus...
Not particularly because the DatePicker is also its own UI, so it has various objects within it that can be focused on (which is what tabbing picks up on).
Actually, now that I've thought about it, if you hide a field (AKA, "hidden") it will not have a tabindex and the other tabs will fall in line with what is defined for the browser (typically top to bottom, left to right order). You shouldn't have to worry about setting the tabindex manually.
Related
I'm writing this to document a current (apparent) bug.
Situation:
Given a webapp where users can view and sort tabular data (it is loaded from DOM, and sortable via javascript). They can use checkboxes and a buttons to take action on what is viewed.
If you use the back button to go back to the tabular data page, then the browser fills in the states of the checkboxes. This is expected behaviour.
Complication:
If you sort the table first (an in-DOM sort using javascript) and then fill in the checkboxes and go to another page, and then use the back button to go back then browsers behave differently.
Currently Chrome (58) and Safari (10.1) reloads the form and tabular data in the original (not the js-sorted) order, but restore the inputs in the order they were clicked (ie ignoring any ids for the inputs -- just their order in the DOM at the time) -- this results in very surprising behaviour (the form at first glance seems to be what you expect, but different form elements have been restored with different data)
However Firefox (v50.0) reload the form and tabular data in the js-sorted order, and the restored inputs are correct.
I've documented this more fully at https://timdiggins.github.io/back-button-restore-sorted-inputs/
Ideally the browsers would store their input data against the input's id rather than its order in the DOM, or would cached the DOM order too.
I'll answer this myself with a workaround, but I'm hoping someone will come up with a better suggestion.
Or alternatively point out anywhere in HTML5 specs that say that form's DOM shouldn't be sortable? (ie. is it possible that Chrome and Webkit are behaving to spec here).
I've found three ways of working around this. Two which are very reliable, but each lose functionality, and one which I am in two minds about
1) Disable dynamic sorting in the initial form (obviously).
2) Disable saving form state for all of the form elements with autocomplete="off" (on every input, see https://stackoverflow.com/a/2458153/109175). Optionally could skip this for browsers (like Firefox) that have unproblematic behaviour (in my use case Firefox never used).
3) An option that occurred to me is to make sure that the order is reset to the original DOM order when form state is saved. This might mean adding a before submit handler on the form (easy enough) but in order to ensure the form is restored correctly when navigating away with a simple link <a>, this might mean adding a callback before executing links -- this wouldn't cover javascript based navigation.
4) Another option which occurs to me, is to focus on the reordering process -- either to convert it from js to a page reload or to use pushState or replaceState from the History API
Both 3 and 4 seem clever, but (for my use cases) I'm inclined to go with one of 1 or 2 and deal with the reduced functionality.
I asked this a while back with absolutely no luck (or answers).
I do not wish for this to happen. I can initialize the entire dialog but the second that I call
theDialog.dialog("open");
All previously selected text on the screen is deselected. Technically, speaking, either the selection object is trashed or the range objects boundaries is collapsed - the effect is the same.
I wish for the dialog to be as unobtrusive as possible. Is it possible to have the dialog not effect the user's selection at all?
Is this possibly an issue with events? Is there a way to have the dialog bypass whatever step it is taking that collapses the selection?
My issue is that when the page is refreshed, I want the 'select' to be scrolled all the way to the top. However, if the user has scrolled the select box down to view the options (without necessarily even clicking on any of them) prior to the refresh, the 'select' box doesn't return to the top.
I've seen answers where people say to simply use selectedIndex to select the first option in the list, and thus it will automatically scroll to the top, but this is NOT an option. When the page is refreshed, nothing must be selected and thus, the only code I have at the moment is:
document.form1.componentselect.selectedIndex = -1;
Which is effective at clearing out any selections in the 'componentselect', but does not reset the scroll position.
FYI, I am using straight HTML and JS, no JQuery or anything like that. Thanks.
All you need to do is first select the top item (as you said you don't want to do), but then set it to -1!
document.form1.foo.selectedIndex=0;
document.form1.foo.selectedIndex=-1;
While I was looking at this, I also figured out how to have it remember what was selected, in case that becomes an issue:
http://jsfiddle.net/ryleyb/qPJ4S/
I think it's impossible to change the scroll position in traditional selects (select from the tag, no box generated by javascript plugins) because this box is controlled directly by the user's browser and theme, without direct interference by javascript.
I believe the only way to "reset" the display is to force the user to click on the field again, hiding and redisplaying the select tag. But you will need to click to open the box again and it hinders more than helps the user.
This is a 2 part question:
1)
click on one of the demo dropdowns on this page. when you tab over to the next input, the text is selected/highlighted in firefox. how can i prevent this from happening?
2) bonus: can you review my code that is hosted on google and tell me what i can improve?
Well, that is just default behavior on Firefox. A possible workaround is to have the input fields execute a JavaScript or jQuery function on select, have the function blur the field (which would deselect the text) and then refocus on the field. Very basic and I'm sure it'd need a couple extra hacks. Unfortunately without scripting, no there is nothing you can do to prevent that.
I honestly recommend that you leave it alone. That functionality was put in place so you wouldn't have to use your mouse when typing into forms, hitting tab would select all the text so you can easily retype it or hit the right arrow key to go to the end of the field. Removing the functionality will only irritate some of your visitors. If they're using the tab key to get to the next field, they probably want that functionality.
I am currently working on a Javascript program for my company (Leader Technologies) that is used to register products for Logitech. The URL for that is :
http://wwwtest.onlineregister.com/logitechreg/
My program looks totally fine on everything single web browser (including IE 6) that I have tried except Safari 4. On Safari 4, after a location, language and product category have been selected, when the actual product menu is clicked (id=WHPR), the div responsible for displaying the product is shown, but the drop-down selections are still visible. On all other browsers, the drop-down and the possible selections inside it in hidden (which is the intended behavior.)
Directly, my question is can I hid this drop-down successfully in Safari 4 WITHOUT completely emptying out the drop down and then repopulating it with only the selected value? I would rather not do this if at all possible, but if it's the only way to accomplish my goal then I can change the site additionally.
I believe the problem is where I set the listeners on the <select>:
<select id="WHPR" class="ui-formulate-ignore" style="width: 280px; visibility: visible;" onchange="whprChanged(this);" onfocus="displaySelector(form, document.getElementById('WHPR')); document.getElementById('imageHolder').focus(); this.blur();" name="WHPR">
Thank you all very much for taking the time to help me. I really appreciate all the help available on this site.
-Brian J. Stinar-
Not to pick on your style, but attaching listeners inline like you're doing is not very clean. Why not take advantage of jQuery's ability to deal with any browser discrepancies? The page you refer to is already loading it.
See http://docs.jquery.com/Events/bind
I think it's some kind of a bug in Safari - for example if you do .focus() nof for the DIV but for another input element like a textfield, then after clicking the selectbox both would have the focus (or actually, the focus would stay in the selectbox and the textbox would only seem to have the focus by having thicker border than usual).
Anyhow quick and dirty methot to achieve the goal would be removing the selectbox from the page (display: none) and then bringing it back (display:inline).
replace the this.blur() with the following command
this.style.cssText='display:none';var select = this; window.setTimeout(function(){select.style.cssText='display:inline';},1);
If you don't use a delay then it doesn't work - the removal and retrieval of the element need to be in different scopes.