I have a form with multiple iframes embedded as fields alongside standard form fields. Each iframe hosts a single text input, and is intended to behave as if it were part of the form. This works relatively seamlessly on chrome and edge, but there are a few issues related to tab order and navigation on other browsers / on mobile. The iframes are required for the integration, so I can't replace them with an alternative.
For instance, in safari and firefox, it takes 2 tab presses to get from one iframe field to the next. On Mobile, the 'Go' button is present in the fields but doesn't do anything (because the iframe is not hosting a form itself). On Android sometimes it shows 'Next' instead of 'Go', and it does put focus on the next frame.
There are effectively two questions here:
Is there a consistent way to navigate between the iframes with a single tab press?
Is there a way to influence the presence of the 'Go'/'Next' buttons (or their equivalents) on mobile?
I suspect tab order may have something to do with both.
How can I prevent formula touch event in MathJax? e.g. when I touch or click a formula rendered by MathJax It is gone to surround by a blue border as a response that it is touched.
This is an Example form MathJax test folder.
I have already set showMathMenu: false but I am unable to prevent this.
The outline is part of the standard browser interface for focusable items on the page. In version 2.6, MathJax added support for users using assistive technology, and that included making the MathJax menu accessible to keyboard users and those with screen readers. In order for that to work, the math expressions need to be able to accept the browser focus (so that keystrokes will be targeted to them, so the menu can be opened).
The outlines you are seeing are the focus highlighting that is the default styling for focused items in the browser (the actual effect differs between browsers, but all browsers should provide some form of visual indication for the focused item). Without that, keyboard users will not be able to know when and which math expressions are selected for keyboard focus. Removing that would make it harder (or impossible) for those users to properly interact with MathJax and its menus.
While you certainly could add CSS to your page to remove the outlines, it would be a mistake to do so, unless you have no concern for those users who require assistive technology to support their reading of your pages. You should note that all focusable elements should get these outlines (buttons, menus, input areas, etc.) when you click on them. For example, the editor I'm typing into right now has a blue outline indicating that it currently has the keyboard focus. This is part of the standard interface for focusable items, and is not something you should try to disable.
I've come across some strange functionality on chrome, mobile.
When I try to focus on an element on chrome, it doesn't work when you try to just load the input, getItById and do .focus(). However, if you wrap it in an event listener attached to a button, and click the button with your mouse, it works fine.
So, I tried to trick it by seeing if you could call btn.click(), but that doesn't activate the .focus()
Have a go below: On mobile, chrome (at least for iOS), load the page. You should get an alert 'Clicked', but it won't focus on the input. Then, try clicking on the button. You will get both the alert AND the focus works.
I found this interesting and wanted to see if people knew of a workaround.
Link here - jsfiddle
const btn = document.getElementById('button')
btn.addEventListener('click', () => {
alert('clicked')
const input = document.getElementById('input')
input.focus()
})
btn.click()
<input id="input" type="text">
<button id="button">Button</button>
Edit
Another thing I've noticed, is that if you put your phone go to sleep, and open it again, the focus() works without the click.
Edit 2 - added link for mobile
Why does this happen?
Because mobile devices usually need to change the screen dimensions when a keyboard is shown, they come with some restrictions on when a focus event can be triggered. This is intentionally limited browser behavior on touch devices to guarantee a good UX and avoid performance issues of resizing the browser window ( = potentially very expensive style recalculation).
There's some cross browser differences in how far these restrictions go, and some browsers have bugs on top of that.
But in general they all require an actual user interaction to have happened not too long before the focus is programmatically triggered. Using btn.click() is not the same as an actual touch event, and so the browser will ignore it seeing there was no recent touch event.
On a tracking issue on this behavior for Webkit, Apple provides a motivation:
We (Apple) like the current behavior and do not want programmatic focus to bring up the keyboard when you do not have a hardware keyboard attached and the programmatic focus was not invoked in response to a user gesture. Why you may ask...because auto bringing up the software keyboard can be seen as annoying and a distraction to a user (not for your customers, but for everyone not using your app) given that:
We bring up the keyboard, which takes up valuable real estate on screen.
When we intent to bring up the software keyboard we zoom and scroll the page to give a pleasing input experience (or at least we hope it is pleasing; file bugs if not).
This similar issue with the autoplay attribute, which also requires a gesture (or page load) to have happened recently enough, could be helpful in understanding the kind of problem.
How to work around these limitations?
Most of the time
Likely you don't need to, as most code that would trigger focus is running as a response to a user action and will be allowed to trigger focus. I didn't find data yet on how big the window of time is, but I guess it's big enough that in regular cases it's not a problem (unless you set timeouts of course).
A possible problem for those cases is the script would run so long that the event is already considered too long ago. In fact that's what happened in the related autoplay issue, where the code would request some network resource, and only after the response would trigger the video to play. Depending on the speed of the network/device the video would sometimes auto play, and sometimes not.
Technically the same could happen with an input that is only focused after a network delay making it not show the keyboard. As long as your code doesn't do any network requests you won't have this kind of problem.
On page load
This is definitely not a "fix" for the problem, but you can do a best effort to manage focus on page load by using the attribute specifically made for it. This still won't make a keyboard appear when it otherwise wouldn't.
The autofocus attribute is at least partially supported on all browsers.
Perhaps just calling focus() directly in a script on page load works, but again there's a chance that this code runs too long after the page started being displayed, especially on slower devices. This probably also happens when adding HTML with the autofocus attribute programmatically (e.g. React). If the initial HTML contains the autofocus attribute on the right element that shouldn't occur.
There is deinfitely something weird happening here.
It seems "part" of the DOM thinks that the input element is in focus initially, but chrome does not complete the focusing. For exmaple, if the background is set with:
document.activeElement.style.backgroundColor = "pink";
Then the input element's background is pink. So, some part of chrome's DOM thinks the input element is in focus.
Initially, in my case, the input element is rendered by chrome in its default non-focus styling.
The alert() seems to be interfering with the process. In my case, taking the alert out had the effect of changing the styling of the input element from non-focus styling to in-focus styling, but the cursor did not appear in the input element, nor did the pop up keyboard appear.
By:
removing the alert
wrapping the click inside a function
calling that function on load
fixed the problem in my case. Initially now the element is in-focus styled, the cursor appears in the element's box, and the keyboard pops up.
The solution to the posting by #HJo, January 2019, is to replace:
btn.click();
with:
function load() { btn.click(); }
remove the alert(),
and make the body tag as:
<body onload="load()">
#Peter. If this does not fix your problem too, can you please provide minimal code for your context.
const event = new Event('tap');
const btn = document.getElementById('button')
const input = document.getElementById('input')
btn.addEventListener('click', () => {
prompt('clicked')
input.focus();
})
window.onload = function(){
btn.dispatchEvent(event);
}
}
The code above works when the website tab is just opened, but not on reload for some reason. I tested it on an Ipad and Iphone so hopefully it works well on your end too.
Here's a link to a repl:
https://r.hackinggo306.repl.co
Edit: This seems to be the closest I can get, but also acknowledge the fact that mobile devices might be deliberately preventing this. (It would be annoying if a website looped this.)
On the mobile, you will need to use touchstart event instead of click event.
You can find it here. Hope this helps.
I think, this problem can occur, because of the your JavaScript script is executed before the DOM is Mounted.
so you can do different things,
One Thing
add defer keyword to script tag. Basically it does is, that script is only run after the DOM is mounted. See
Second Thing
Wrap window.onload event with your input focus functionality.
<script type="text/javascript">
window.onload = function () {
const btn = document.getElementById('button');
const input = document.getElementById('input')
input.focus()
}
</script>
window.onload event is only fired when the DOM is finishing mounting.so that may be your JavaScript script run before the input element is mounting.so add onload event to your code.see this
On my site, I have a div container, which contains a <input>, and a <a onclick="DoSomeStuff();" href="#" target="_blank"> element, which acts as a button. Now, DoSomeStuff(); modifies the href attribute based on the value of the input element.
I need to emulate click on this anchor tag after user pressed enter on an input element. I know how to detect this enter, but I don't know how to click this anchor. jQuery's .click() is not working in here, it only fires onclick() of the anchor tag, but does not actually click the anchor.
Edit: Here is an example on what I want to do: http://jsfiddle.net/JZYWZ/. It triggers the onclick event of the anchor tag, but does not follow the link in new tab.
Browsers are very strict about opening links in new tabs/windows through javascript.
If they allowed you to have javascript click and open a new tab when the user presses enter (for what you know to be legitimate reasons), that feature could be abused by spammers to have javascript click ads and spam links when the user does anything. Sadly there's no way the browser can tell your linked page is legitimate and not spam or monetised clickbait.
Pretty much the only option to open the url in new tab using javascript is window.open which you've already tried: the browser will always look to the user's settings on popup blocking and on whether to open in tabs or windows - and the default settings are strict, particularly in Firefox and Internet Explorer (less so in Chrome and Safari).
A possible alternate approach where you won't be fighting the browser's anti-spam defences is to open the content in a modal overlay (iframe-based if you need multiple pages). Here's one example library.
It'll be similar from a UI point of view - giving the user related content in a form where they can just close it and return to the main page when they're done with it.
Modal overlays are widely used and likely to be familiar with users. For example, they're now pretty standard for sharing pages, logins and other pieces of simple interaction or side content. Example:
EDIT
After some additional testing....
$('input[type="text"]').on('keyup', function(event){
if(event.keyCode === 13){
DoSomeStuff();
window.open($('a').attr('href'));
}
});
I have an input box inside and iframe. If i type and press the back key to erase the text, the back key event is taken as browser back and goes to the previous page. What could be the cause.?
please tell which browser you have tested with.
My guess would be that you have focus outside the field? is there a script putting focus on the document containing ths input box in the iframe?
i even cann't raise same event. I press BackSpace in iframe, I press BackSpace in input, I press BackSpace in main page.
Which browser do you work with?
Is there any javascript code in the page?
This is such an old browser behaviour. Update your browsers. In worst case scenario you can block the default events for the input element, using a jS library to get a unified response en browser events.