We have a requirement whereby a page can consist of a form with several sections. Sections can be added or removed. After the user chooses to add a section the form is submitted and a new page returned with the new section added. The browser should scroll to the top of the new section. This is fine and I have a generic jquery "scroll to anchor" solution working. However, in addition to simply setting window.location(), I also need to ensure that for keyboard users, hitting tab will take them to the next field after the anchor point. I'm using the solution to this question to do this.
This works fine in IE 8/9 but in firefox(15), I'm seeing a little focus square being rendered where the anchor tag is. I would like to suppress this, I tried setting display:none but of course this stops the scroll working. I tried to create a fiddle but jsFiddle doesn't demonstrate the problem as the fddle site itself is interfering with the focus setting - but the same code in the same browser running locally does.
here's a reduced version of my code that demonstrates the problem.
<html>
<head>
<title>test scroll</title>
</head>
<body>
<form>
<div>Blah</div>
<div>
<label for="a">Section 1: <input id="a" type="text" /></label>
</div>
<a id="scrollToAnchorSection2"></a>
<div>
<label for="b">Section 2: <input id="b" type="text" /></label>
</div>
</form>
</body>
</html>
and my jquery
$(document).ready(function() {
/* Find any "scroll to anchors" that have been set */
var anchors = $('[id*=scrollToAnchor]:first');
if (anchors.length == 1) {
window.location = "#" + anchors.attr("id");
// Set tab position
anchors.attr("tabindex", -1).focus();
}
});
and css
div {
margin-left:5em;
}
As requested...
the Blur function takes care of the input lost focus.
$('input').blur(function (){...})? isn't this what you need?
The jquery documentation has this interesting comment.
"The blur event is sent to an element when it loses focus. Originally, this event was only applicable to form elements, such as . In recent browsers, the domain of the event has been extended to include all element types."
Related
I have a webpage with an "edit" form that appears in a modal dialog using Bootstrap.
When the form appears, I would like one of the input fields to be disabled at first, and to be enabled if the user clicks a checkbox.
The problem is, my browser (Chrome) is not reflecting the disabled attribute for any form element within the modal dialog. Any form element outside the modal works fine.
This also works fine on another webpage I have with the exact same logic. It is only misbehaving on this page.
I have run the entire page source through the W3 Validator for HTML5 and get no errors back.
Code for the input element:
<form role="form" id="frmEdit" action="group_edit.php" method="post">
<!-- ... -->
<input type="text" id="txtEditAlternate" class="form-control" name="alternate" disabled />
<!-- ... -->
</form>
I even tried to brute force disable it with jQuery on document ready; this does not work:
$(document).ready(function() {
$("#txtEditAlternate").attr("disabled", true);
// ...
});
The only thing that does work when it comes to disabling the text field is when the checkbox is checked and then unchecked:
$("#chkbox").click(function() {
$("#txtEditAlternate").attr("disabled", !$(this).prop("checked"));
});
Although that kind of defeats the purpose, since the text field is supposed to be disabled until the checkbox is checked.
I have read that simply including disabled with no value is valid HTML5 (the validator did not even warn about this), and it works elsewhere.
I have tried everything I can think of, and can only speculate that it has something to do with the Bootstrap modal functionality. But like I said, the same logic works perfectly on another webpage I have.
And yes, I know Chrome likes to cache things. I have "hard-refreshed" many times, does not change anything.
Any suggestions?
try to use disabled="disabled":
<input type="text" id="txtEditAlternate" class="form-control" name="alternate" disabled="disabled" />
Use readonly attribute instead of disabled.
use prop instead of attr
$("#txtEditAlternate").prop("disabled", true);
The scenario:
I have a page with form that loads more than 4 iframe. i have no control in this iframe as this is generated by other website(API);
The Iframe has a form and input in it.
in my code
<form>
<div class="fields">
<!--onload iframe will populate this area-->
</div>
<div class="fields">
<!--onload iframe will populate this area-->
</div>
<div class="fields">
<!--onload iframe will populate this area-->
</div> </form>
upon page load this happens
<form>
<div class="fields">
<iframe src="" frameborder="0">
<html>
<body>
<form action="">
<input type="text">
</form>
</body>
</html>
</iframe>
</div>
<div class="fields">
<iframe src="" frameborder="0">
<html>
<body>
<form action="">
<input type="text">
</form>
</body>
</html>
</iframe>
</div>
<div class="fields">
<iframe src="" frameborder="0">
<html>
<body>
<form action="">
<input type="text">
</form>
</body>
</html>
</iframe>
</div></form>
in chrome:
when filling up the form, tabbing in chrome does not have any problem.
e.g click on the first input, then press tab key for next input until you complete the whole form filling up.
but in firefox mozilla:
click on the first input, then tab twice to get the next input. it does not select directly the input fields, it seems it goes to every element.
is there a script to prevent this? like the normal behaviour in chrome?
i have check this Tabindex to skip iframe but not content inside
but my case is different
**Update - It's important to note that this is a special accessibility feature of Firefox & Safari, i.e. it was implemented like this on purpose. Your question is in fact linked to this one - How to remove dotted outline from iframe in Firefox when tabbed
** Ideas on how to work around this..
I ran into this exact same issue today and I found a solution. However, there's two important caveats:
The code below shows only a partial solution - i.e. what you asked for - going forward. When the user presses SHIFT + TAB (to go back), they will see the border once again. So, in order to support this fully, you'd need to listen for these keyboard events, send a message
to the targeted Iframe, and within that controller focus the input. Also, bear in mind that you'd need to consider different browsers' implementations of this and gracefully handle the differences.
You need to be the provider/have full control of the iframe contents, in order to access the contents of the Iframe, attach listeners, get input and focus.
Hence, in your JavaScript controller you can do the following to implement the TAB (go forward) functionality:
constructor() {
...
this.input = document.getElementById("yourInputId");
window.addEventListener("focus", event => {
event.preventDefault();
this.input.focus();
});
}
What happens in the snippet above is:
Register an event listener on the whole window (meaning the whole iframe in this case)
Intercept the body focus event (as far as I understand, Firefox focuses the body of a cross-origin Iframe first. Perhaps to indicate it's a different context).
Prevent the default - so not focus
Focusing the input directly instead.
I've made a web application That starts from a specific amount and every time a donation is made it counts down and shows how much is needed. And at one time I might have about 10-20 of these counting down and I am always creating new ones. Now when I am doing that it would be nice that when I click the button it automatically focuses on the text field for ease of use. however I can't quite get that to work.
The window to set the countdown is shown using angularjs dialogs/modals. This means that when I click the a button it writes code onto the page that shows the dialog/modal and when I submit it it is removed from the page completely.
The first time around when I click the button it focuses on the text box and I can type the number and press enter and it's submitted, now I want to create a new one. I click the button, up comes the modal but now I have to grab the mouse, move it to the input and click it. Waste of time and not user friendly.
What I'm asking is for a way to have it focus on the text field when using modals every time I click the button.
here's the window:
<form name="formCountdown" novalidate class="css-form">
<div modal="showCountdownModal" close="showCountdownModal = false" options="opts" ng-cloak>
<div class="modal-header">
<h4>Enter Countdown Amount</h4>
</div>
<div class="modal-body">
<input id="focusbox" type="number" min="1" autofocus required ng-model="countDownAmount" name="countDownAmount" ui-keypress="{13:'setCountdown()'}" select-on-focus />
</div>
<div class="modal-footer">
<button type="submit" class="btn btn-primary cancel" ng-disabled="formCountdown.$invalid" ng-click="setCountdown()">Set</button>
</div>
</div>
</form>
I've tried using autofocus, and that works fine the first time you press the button after loading the page. but the second and up it does not.
I've also tried using this jquery code with no luck:
<script>
$("#focusbtn").click(function() {
$("#focusbox").focus();
});
</script>
And now I am completely lost and would really love it if someone could help me out here.
Edit: forgot to put in the timeout, to make sure the browser is ready!
add the following line to your setCountDown() function:
$timeout(function (){
document.querySelector('#focusbox').focus();
},0)
You need to inject the $timeout in your controller
That will probably do the trick!
However, this will work, but dom manipulation should be done in a directive!
I copied your posted code together with the script and it works just fine. I'm not sure if I understood the problem but the autofocus works well in my end. Autofocus is present after the page has loaded or refreshed and even after the button has been clicked. Of course the autofocus will be removed if a click outside the input text has been triggered.
Morever, I think Autofocus is an attribute by HTML5. You might want to include in your HTML or maybe it is just a browser compatibility issue.
You can test or check if autofocus is supported by your browser at http://html5test.com/.
Hope this help somehow.
EDIT:
Try this on your script.
$(document).ready(function() {
$(".modalName").on('shown', function() {
$(this).find("[autofocus]:first").focus();
});
});
I have a page (demo):
<!DOCTYPE html>
<html>
<head>
<title></title>
<script type="text/javascript" src="http://codeorigin.jquery.com/jquery-1.10.2.min.js"></script>
<script type="text/javascript">
$(function() {
$("#id_button").click(function(e) {
$("#id_file").click();
});
});
</script>
</head>
<body>
<form method="post" enctype="multipart/form-data" action="http://www.google.com/">
<input type="file" name="file" id="id_file" />
<input type="button" id="id_button" value="fake button" />
<input type="submit">
</form>
</body>
</html>
if
I open browse dialog via clicking "fake button", select file (I see it in input[type="file"]), than click submit button and no post happens, the input[type="file"] is cleared.
What should I changed to get it work?
I get this problem in IE8 and IE10.
PS: file input will be hidden, so user will work only with fake button.
All of the browsers have different behavior when it comes to what they allow you to do from javascript with regards to programmatically clicking the input button for file inputs.
The best solution I have found that seems to work cross browser is to set the opacity to 0 (do not use display:none) and put the button underneath the input, so the user clicks through the 0 opacity input to your button, thus firing the input select dialog.
A good writeup on styling the file input can be found here: http://www.quirksmode.org/dom/inputfile.html
http://jsfiddle.net/j38Wj Works fine in Google Chrome but does not work in IE 10.
As I think IE does not allow select file by external 'click' event.
Only one way to "customize" input[type=file] is usage of opacity style to hide it and relative positioning of custom button control below it.
Working example: http://blueimp.github.io/jQuery-File-Upload/
[...]
I think all browser does that behaviour for security reason. When you submit a form, you are redirected to a different page(or the same page) and if you are directed to the same page, the form is re-initialized.
In this case, you simply can NOT set the value of file for security reason.
From example, How to set a value to a file input in HTML?, you don't want this happen
<form name="foo" method="post" enctype="multipart/form-data">
<input type="file" value="c:\passwords.txt">
</form>
<script>document.foo.submit();</script>
Add a label tag along with the input file element. Set the 'for' attribute of the label to the id of the input file element.
Then when you click on the label the input file element will 'click' and the file dialog will open.
Then simply style the label however you like. Have tried on various IE versions.
I'm using a customized <img> element as a button on my site (with onclick for the form submit). The reason being I want the element to display one image when the button is up and another for when the button is down. I'm using onmousedown and onmouseup for that.
This is an AJAX-based site, and the submit is also AJAX-y. It is safe to assume that javascript is on.
Forms are being submitted by AJAX (via Prototype), so the regular <input type=button> is out of the question as it would cause a submit + page refresh (also, to my best understanding, it cannot be fully customized using images).
My question is: Should I expect any difficulties with the approach, and is there a better/easier way of generating customized buttons?
I am interested in usability and compatability issues: e.g. Accessability features (such as tab index) vs. support on all browsers (such as IE6).
Use a <button> or <input type="submit"/> with CSS background styles applied.
<html>
<head>
<style type="text/css">
.hoverable {
background: #FFFFFF url(path/to/background.png) top left no-repeat;
height: 32px; /* height and width match your background.png dimensions */
width: 64px;
}
.hoverable:hover {
background-image: url(path/to/background-hover.png);
}
</style>
</head>
<body>
<form>
...
<button type="submit" class="hoverable"></button>
<!-- or <input type="submit" class="hoverable"/> -->
<!-- or <button type="button" class="hoverable"></button> if you don't want submit behavior -->
</form>
</body>
</html>
Using a form input makes the most sense semantically, especially with your concerns about accessibility. People using accessibility tools probably aren't expecting to encounter a <div> or <img> and be expected to perform an input event on it (I could be wrong, I'm not entirely familiar with how such tools work).
The fact that the application is dynamic/ajaxy/etc. shouldn't be a barrier to you using the appropriate markup elements and using CSS to style it appropriately.
Edit:
Regarding the <input> not working: if you return false from whatever gets invoked when the button is clicked, it won't continue execution (i.e. submit the form). Example:
<button type="submit" onclick="handleClick();"></button>
...
function handleClick() {
// ajax call
return false;
}
On top of that, using a <button type="button"></button> shouldn't even submit the form at all. Some browsers default the type to "submit", so you'd want to explicitly define type="button" to make sure it's not treated as a submit.
Obviously, this will be different than your prototype code, but you get the picture; the gist of it is that the event handler needs to return false. And <button>/<input> can be styled just as well as an <img> or <div>.
You can improve these with CSS sprites, here's a good article explaining it: http://www.jaisenmathai.com/blog/2008/04/03/extremely-efficient-image-rollovers-using-css-sprites-and-no-javascript/
It's a css-only solution that uses 1 image for both the up & down states.