I've noticed navigating in websites like Dell or Google, that typing in their search text box with iPhone, in the keyboard appears a blue button 'Search' instead of the standard 'Go' button that appears on any normal form.
What should you do to display the search button?
having type="search" is usually all you need to make software Search keyboard appear however in iOS8 it is mandatory to have a wrapping form with action attribute.
So the following code would have a software keyboard with “Return” button
<form>
<input type="search" />
</form>
But this code should have blue “Search” button instead
<form action=".">
<input type="search" />
</form>
You can influence this behaviour with:
<input type="search" />
JS Bin demo
Ignore the submit button's text being 'kettle,' I just wanted to be sure that it wasn't the submit button influencing the text of the iOS keyboard...
This is, of course, backwards compatible since a browser that doesn't understand type="search" will default to type="text", which is useful for creating forward-planning html5 forms.
I was not able to get the search button with
<input type="search" />
However, I did get it to appear with
<form>
<input name="search" />
</form>
On iOS 8 you can enable the blue "Search"-button on the keyboard by doing one of:
add input name=search
add input type=search
add id to input with the case sensitive word "search" in the ID, for
example the-search or thesearchgod
In HTML5 standard, adding enterkeyhint attribute on the input is the proper way to change the label on the virtual keyboard
<input enterkeyhint="search" />
If no enterkeyhint attribute is provided, the user agent might use contextual information from the inputmode, type, or pattern attributes to display a suitable enter key label (or icon).
See MDN Docs about enterkeyhint
When using #Anton Bielousov suggested solution, this also changes the styling of Android Devices. To counter this I had to:
Add form around input.
Add type="search"
Add name containing search
Add styling to counter the unwanted android styling
Android styling:
input[type=search] { -webkit-appearance: none; }
/* clears the ‘X’ from Internet Explorer */
input[type=search]::-ms-clear { display: none; width : 0; height: 0; }
input[type=search]::-ms-reveal { display: none; width : 0; height: 0; }
/* clears the ‘X’ from Chrome */
input[type="search"]::-webkit-search-decoration,
input[type="search"]::-webkit-search-cancel-button,
input[type="search"]::-webkit-search-results-button,
input[type="search"]::-webkit-search-results-decoration { display: none; }
<form action="" class="search-bar__form-form">
<input
class="search-bar__input"
name="search-bar"
type="search"
/>
</form>
The keyboard is handled by the operating system (iOS) and cannot be directly altered. The type of input required determines the type of keyboard to display.
If the website in question is HTML5, then #David's answer is valid.
Related
<div class="form-group">
<!-- Password-->
<label class="control-label" for="password">Password</label> <input type="password" id="password" name="password" class="form-control">
</div>
Consider following snippet. It complies with tb3. The problem is whenever I try to type anything into this field in safari - nothing gets written inside. Blinking cursor becomes active on field input during typing but no characters/black dots appear inside the field.
ff, chrome and even ie work ok. Basically on the picture I type but cursor stays at the same place no input at all.
I turned off all my scripts and problem still persists. If I change type to text it starts to work or if I remove form-control it works. But both are required...
Safari version 5.1.7 - version for windows
Thanks,
The solution that I implemented in my case is adding this line of CSS to element
.SafariFix{
-webkit-user-select:auto;
}
here is HTML of button
<input type="text" placeholder="Search by name" class="btn btn-default SafariFix" id="friendsearchinput">
note (this will work for safari 6 but I am not sure for previous version )
I had the problem that I used
padding: 20px 13px;
which caused issues on the input element. The input text and the placeholder weren't visible in Safari, but worked in any other browser.
I fixed it by using
padding: 0 13px;
height: 45px;
which looks the same but works in Safari.
I had the same problem: You could try to change the font-family of the password input field, for example:
style="font-family:Arial"
and then it should work as expected :-)
I have a mobile webpage that is just a simple form with a submit button.
I have just tried to make the submit button bigger in the css file and also inline on the submit button itself and it doesn't show.
If I use the Ripple extension for Chrome it shows in there (but Ripple doesn't have the exact look of the iPhone form elements yet).
I was wondering if this is a known issue - i.e. incase the browser removes styling from submit buttons etc. or if it is something that I am doing wrong.
The line in question is simply:
<input type="submit" value="Submit" class="submit" style="text-align: center; width:30%; height:50px; "/>
The height rule won't apply to the button unless you specify "border: 0". However, you'll lose the default styling of the button, but you can get the styling back with your own CSS.
Not sure if you're trying to get the submit button centered in the form - but if you are, you should set the button to "display: block" and then add "margin: 0 auto". The text-align rule isn't necessary.
This should help you
-webkit-appearance: none;
add it to the input button you're styling
Hello
I got similar to that code
<form method="post" action="/" name="form" autocomplete="off">
<input type="text" name="title" />
<textarea name="body"></textarea>
<input type="text" name="tags" />
<input type="submit" name="submit" value="Send" />
</form>
Where the "textarea" is tinyMCE... problem comes when I try to move selection through input and textarea items.
When the page is loaded it focus input[name=text] but when I press Tab key it select input[name=tags] instead textarea[name=body] (which is next)
Can you assist me with that issue ?
This is impossible with conventional tab indexes as TinyMCE actually hides the <textarea> and creates an <iframe> with the editor in it. You could make a work around by forcing focus on the editor in the blur event of the previous element in javascript, here is ajQuery snipped of the top of my head:
$('#prev-input').blur(function(){
tinyMCE.get('textarea').focus();
});
Then as soon as the user leaves the previous input focus would jump to the TinyMCE editor, you could possibly add a blur() method as well to got to the next element.
I resolved this with adding 'tabfocus' to plugins and then add tabfocus_elements : ":prev,:next"
http://tinymce.moxiecode.com/wiki.php/Plugin:tabfocus
http://tinymce.moxiecode.com/wiki.php/tabfocus_elements
There is a plugin solved it
http://sourceforge.net/tracker/index.php?func=detail&aid=1657397&group_id=103281&atid=738747
I known it from TinyMCE forum
http://tinymce.moxiecode.com/forum/viewtopic.php?id=813
I needed a custom tabbing order from another element on the page. The code I used to resolve this in IE11 was
var button = $('#btn-id');
button.on('keydown', function (e) {
if ((e.which === 9 && !e.shiftKey)) {
e.preventDefault();
$(tinyMCE.get()[0].contentWindow).focus();
}
});
Be aware that the above code will only work if you've only got one editor on the page. Otherwise you'll have to cycle through the array returned by tinyMCE.get() to find the correct editor to set focus to.
I found out that the focus event is being triggered but focussing in the element (container) didn't work all the time.
In my case I tabbed from editor 1 - 4 and when I shift+tab I lost focus on the instance.
To fix this I added the following to the setup event of tinyMCE
setup: function(editor) {
editor.on("focus", function(e) {
e.target.editorContainer.scrollIntoView();
});
}
In a html page I am making, I tried to make div's clickable using html and css. This has worked perfectly in some major browsers I have tested it in (Chrome, Firefox, Opera, Safari), as well as an HTC phone, but when I tried to test it on Iphone I noticed it just didn't work. The checkboxes themselves weren't even selectable.
This is my (working apart from on Iphone) code:
HTML:
<div class="" style="height: 30px;">
<div style="display: table; width: 100%;">
<div style="display: table-row; width: 100%;">
<div style="display: table-cell;">
<label for="3171">Text....</label>
</div>
<div style="display: table-cell; text-align: right;">
<input type="checkbox" id="3171" name="3171">
</div>
</div>
</div>
<label for="3171">
<span class="blocklink">Invisible text</span>
</label>
</div>
CSS:
.blocklink {
display: block;
height: 100%;
left: 0;
overflow: hidden;
position: absolute;
text-indent: -999em;
top: 0;
width: 100%;
}
So as you can see the technique I'm using is basicly just having a <label> spread all over the parent div so anywhere you click, it will tick/untick the linked checkbox.
Unfortunately, this doesn't work on IPhone. Would it be possible to somehow keep using this technique but also provide IPhone support? (Preferrably without javascript, because I'm really going out of my way to only use HTML & CSS)
Thanks in advance,
Arne
Adding an empty onclick="" to the label makes the element clickable again on IOS4. It seems that by default the action is blocked or overtaken by the press and hold copy and paste text mechanics.
<label for="elementid" onclick="">Label</label>
The problem seems to persists in iOS9 if any html elements are contained inside a label. At least happens with span elements inside it. 'pointer-events: none' fixes it.
<label for="target">
<span>Some text</span>
</label>
The code above would not be trigger a change of the target input, when the user taps 'Some Text', unless you add the following css:
label span {
pointer-events: none;
}
I solved it by placing an empty onclick="" on a parent element:
<form onclick="">
<input type="radio" name="option1" value="1">
<label for="option1">Option 1</label>
<input type="radio" name="option2" value="2">
<label for="option2">Option 2</label>
<input type="radio" name="option3" value="3" checked="checked">
<label for="option3">Option 3</label>
</form>
For some obscure reason, using CSS, if you apply:
label { cursor: pointer; }
Is going to work both on iPhone and iPad.
Another solution — albeit more hacky, but bulletproof — would be to absolutely position the checkbox over the label, z-index it, increase the width/height to encompass the underlying label and then 0 the opacity. This, of course would be tedious if there are multiple labels on the page... You naturally would also only implement the absolute positioning for that media size; no need to hack the whole app environment.
I ran into a somewhat unique situation. We were already using pointer-events: none on all spans in labels. However, we then needed to add in a <a> as clickable within one of those labels.
<label>
<span>Label text here. With a link text here.</span>
</label>
So, we explicitly set pointer-events: all on those <a>.
label > span { pointer-events: none; }
label > span > a { pointer-events: all; }
This is working in latest Chrome, Firefox, IE 11, and iOS 9 Safari.
If you change DOM on event handler (example in onMouseEnter) this cause skip all next handlers include onClick.
SetTimeout don't fix this.
Example:
1. in onMouseEnter use setTimeout with function injected new div in DOM
2. any onClick handler don't called.
Solution: avoid change DOM in events handler.
Remark: it problem found for label tag, but still persist for span inside label. May be this problem present on any type tags.
This behavuor found only for mobile iOS. In desktop Safari and in Mac OS Safari - all ok.
I narrowed down my problem to use of the Fastclick library; when I removed it from my codebase my issues went away, which indicates to me there isn't a native iOS/FF problem as suggested by other answers here.
Without knowing the libraries other folks are using, but knowing that Fastclick is exceptionally common, can I suggest that the root cause of this bug is in fact a library issue - not one which has managed to persist through years of Apple releases! It seems more likely. Maybe the others here can shed some light on whether they are using Fastclick?
More info
Some browsers prevent file inputs from being triggered by client code as a security measure. Try triggering a click event from the console with document.querySelector('input[type=file]').click() and it'll work, do the same from your code and it will mysteriously fail.
I imagine the reason this bug exists is because an ontouchstart handler is being applied to the <label /> by Fastclick. When it is triggered on a touch device, the library will proxy that event to the onclick handler, or in this case the native <label /> functionality. Unfortunately, this means that client code is triggering the file input opening, and it's being blocked by the browser.
I have a problem that in IE8 the enter does not work to submit a form. I have generated a test page to expose this problem. It seems that displaying the form in the onLoad function disables results that the enter button does not trigger a submit anymore. Is this a bug in IE8 or is it some security issue?
The code to reproduce this is:
onload = function() {
document.getElementById('test').style.display = 'block';
}
#test {
display: none;
}
<form id="test" method="get" action="javascript:alert('woei!')">
<input type="text" name="user" value="">
<input type="password" name="pw" value="">
<input type="submit" value="submit" id="submit">
</form>
I have found a proper solution and wanted it to share with u guys.
Instead of using <input type="submit...>, use <button type="submit"...>.
This will do exactly the same in the other browsers (IE6-7, FF3) AND works in IE8. :)
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<style type="text/css">
#test {
display: none;
}
</style>
<script type="text/javascript">
onload = function() {
document.getElementById('test').style.display = 'block';
};
</script>
</head>
<body>
<form id="test" method="get" action="javascript:alert('woei!')">
<input type="text" name="user" value="" />
<input type="password" name="pw" value="" />
<button type="submit" value="submit" id="submit"></button>
</form>
</body>
</html>
$("form input").keypress(function (e) {
if(e.which === 13) {
$("form").submit();
}
});
Above is a proper fix. Ref: IE Not submitting my form on enter press of enter key?
I think everthing is much more complicated than you think...
when a form's display value is set to none with a css class or just with a style attribute on page inital, hitting the enter key in a text field does not work only if you have more than one input field with text type... if you have one text field it works fine.. if you have more than one, it does not fire form submission...
Here i made a demo...
Works Fine (Normal Form)
http://yasinergul.com/stackoverflow/ie8-enter-key-bug/one.html
Works Fine (Form hidden & set back visible but it's with one text input)
http://yasinergul.com/stackoverflow/ie8-enter-key-bug/two.html
Does Not Work (Form hidden & set back visible but it's with two text input)
http://yasinergul.com/stackoverflow/ie8-enter-key-bug/three.html
i think the best approach is to give a .hidden class to the object but not setting display:none for this css selector. you can make it hidden with jquery like
$(".hidden").hide();
as the page loads the form is shown for miliseconds but gets hidden after jquery works...
I can't say if it is a bug exactly, but I can confirm that the behavior you report has changed in IE 8... and I imagine it is probably a bug, not an deliberate change.
If the form is set with CSS display:none the default submit button behavior doesn't work.
Other browsers, including IE 7 (or even IE 8 using IE 7 standard compatibility mode) do not have problems.
I've worked around the problem myself by just using height:0px; in the CSS, then having javascript set the appropriate height when I want to show the form. Using height instead, the default enter key submit behavior seems to work normally.
Old ticket, but I'd like to add what I think is the explanation:
IE8 does the following peculiar thing: the Enter key will submit the form, but any
<input type="submit" name="MySubmitButton" value="I hope I detect THIS VALUE in POST" />
won't be sent in the POST.
IE9 changes the behavior and sends the value. Chrome has always sent the value, as far as my tests have shown.
I hope this helps...
For any future users stumbling upon this question:
What worked for me was adding a DOCTYPE:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
A fix to what #Jitendra Pancholi suggested- now it submits only the form we want, not all of them
$("form input").keypress(function (e) {
if(e.which === 13) {
$(this.form).submit();
}
});
I tried it in IE8 and it works for me. You have to make sure that part of the form has focus though.
Javascript has a focus function that you can use to set the focus if that's what you need.
var textbox = document.getElementById("whatever name input box's id will be");
if(textbox) textbox.focus();
You may want to add a onkeyup event to your input boxes so that if you hit an enter in the input box then it will also submit.
As CodePartizan mentioned, you need the focus on the button otherwise, so if you tab over to the button, or click on it, it seems to work for me also.
I believe Yasin has got the point.
I just had the same problem: multiple text fields within a form whose visibility is "hidden".
My workaround (to prevent the form from flashing) is to set the form opacity to 0 in the css, and then customise its style settings with jQuery on document ready.
I believe this is not something to fix with JS.
Yeah, I was bitten by this bug too today. I found this workaround, though (diff from the OP):
<script type="text/javascript">
onload = function() {
document.getElementById('test').style.display = 'block';
+ document.getElementById('test').innerHTML =
+ document.getElementById('test').innerHTML;
}
</script>
</head>
Simply recreate the contents of the form from the contents of itself. Yikes. But it works. (Famous last words...)
This works for me in IE8. I had this problem when using only one input field.
Read more: http://www.rachaelarnold.com/dev/archive/enter-key-form-submission-bug#ixzz2Y5Zwgj2k
I had the same issue with ie and none of the solutions helped until I read this:
http://www.rachaelarnold.com/dev/archive/enter-key-form-submission-bug#ixzz2Y5Zwgj2k
my form only had one input field....duh! :)
Found a working solution.
Make the submit button invisible instead of using display:none;
input#submit {
color: transparent;
background: transparent;
border: 0px;
}