I have a lightbox-like div which appears over pages to present scrollable content. In FF, IE, and Chrome, allowing the user to scroll the lightbox with the arrow and pagedown/up keys is as simple as assigning it a tabindex and calling .focus().
In Opera, .focus() does nothing and tab/arrow/page keys will continue acting on whatever tabstop elements are in the background page.
Here's a fiddle to illustrate the problem: http://jsfiddle.net/9W943/5/
I have seen many examples of how to focus a div, but none seem to acknowledge that the tabindex approach doesn't work in Opera. Is there any way I can force Opera to focus the lightbox? Failing that, what's the best workaround - listen for key events and then "manually" scroll the lightbox? (Or can I redirect the events?)
I have tried calling .click() on the lightbox, and creating+dispatching a fake click event - since keyboard scrolling works correctly after you click it - but neither worked.
Also I am very curious why it's not standard for non-input elements to be focusable, since they can and do receive keyboard events! How do you define a focused element, if not as the element which can be interacted with via the keyboard?
This is a known bug (internally DSK-269802) - unfortunately there is no nice workarounds that I know of :-/
I ran into this problem yesterday myself and will give the bug a "bump" - perhaps we can fit it into some on-going development work. I'd recommend that you ignore the bug and just code as if it worked in Opera, because some day it will.
Related
When typing into a text box with the on-screen keyboard and then tapping on a clickable element while the keyboard is still open
the on-screen keyboard disappears as expected
the tap is ignored, I see in the debugger that the click event handler isn't even reached
tapping on the clickable element again, it now works as designed.
Tapping on other elements on the page with a click event handler while the keyboard is open works fine. One difference is that the unclickable button comes up only while typing, as it is in an autocomplete dropdown, a <ul> element switched visible by removing display: none after the third character is typed.
This happens on Firefox for Android, recent versions. It works in Chrome. Safari on iPad works, but only since the recent 16.x upgrade.
This looks like a weird browser vs platform quirk. Does anyone happen to know a workaround or can even explain some background
EDIT after further experimentation I have a fairly minimal jsfiddle to demonstrate the problem. It seems that Firefox on Android ignores click handlers which are attached to HTML elements created while the on-screen keyboard is open. Wouldn't mind if someone could confirm in a comment that I am not alone with my FF while waiting on an answer from someone in the know.
I would like to display a nice page transition when navigating between pages on a site.
I've tried using these events: beforeunload unload pagehide and also visibilitychange.
There was a webkit bug described as
visibilitychange:hidden doesn't fire during page navigations
And a workaround is listed:
using the pagehide event is the workaround
I am adding a class to the html element on these events. On Chrome and Firefox this activates my loading indicator class and the animation is displayed until the page is replaced. I get a nice loading transition between page navigation. So, in Chrome and Firefox, everything works great.
Unfortunately, I am not having any luck with Safari on iOS (iPhone or iPad) and also failing on macOS Big Sur Safari. I found a related question here: Safari change dom on before unload page however, it only discusses the beforeunload event. I am hoping that by being less specific here that a viable alternative pops up.
I have tested the css works on Safari by manually applying it and also verified my listeners are called on Safari via the javascript console. However the css change doesn't seem to be rendered. There is no transition shown on the page being unloaded before getting the new page response from the server. I've also verified it isn't related to the CSS in use by setting a simple background color without any transition or similar effects.
So far, the only way that I have been able to get Safari to render the dom change is by returning a truthy string on unload - but this prompts the user if they want to leave or not which is not my intention.
I want to avoid browser detection - however the last viable alternative I can come up with is scanning the dom for anchors, buttons, forms, etc when Safari is detected to enable the loading indicator before navigating.
Are there any other options to consider?
For whatever reason, natively in Chrome, mousemove events that immediately follow a mousedown event are not firing or are simply ignored altogether for a small period of time (500-1000ms?) following the mousedown event.
Strange thing is that this issue is nonexistent on codepen (on Chrome too) and the code is the exact same... There's also no issues with Firefox, Edge, etc, only natively on Chrome.
Here is a codepen nonetheless. Test it for yourself.
Copy and paste this code into actual .html, .css, and .js files, and then run it in the browser directly, you'll notice that paper.onmousemove does not fire or register immediately after a window.resize event for a very small period of time.
None of this makes any sense!
Anybody have any idea what's going on? Why would it work fine in codepen (and every other browser), yet not directly in the browser?!
I have found one issue with the codepen version, which produces a very similar bug (but involves a couple extra steps in the beginning).
Create an element by dragging your mouse on the white area
Select that element by clicking it
Drag that element anywhere on the page
Resize the browser and immediately try to create another element by dragging
However, on codepen mousedown isn't firing in this case, whereas mousemove is not firing if viewed directly in the browser. Again, there is a discrepancy, which incredibly bizarre.
Update
It turns out it only happens when the developer console is open, which is why it was not happening in codepen.
This seems to be some weirdness with Chrome DevTools. The bug you describe seems to only occur when DevTools is open. It goes away when you close DevTools. It may just be a weird coincidence, but it starts logging out mousemove events immediately when the resolution label in the top right goes away.
That being said, you have a combination of onmousemove and addEventListener going on. For instance you have both
paper.addEventListener('mouseup', checkMouseUp)
and
paper.onmouseup = function(event) {}
I'm not sure if it's the cause of the DevTools issue, but this can lead to unintended consequences since paper now has two separately assigned mouseup functions. In your case, I'd just stick with addEventListener.
This is a tricky one to describe but here goes.
A select control with a size > 1 is positioned in the browser down the bottom of the screen such that there is a scrollbar present in the body and only the first item in the select control is visible (the other items are there but you need to scroll the page down to see them). There is an onclick event in the select box or any parent above it but such does not fire when the select is clicked the first time. What happens is that chrome automagically scrolls the page to show all the items in the select, but apparently forgets to pass the click event to the handler.
This behavior only seems to occur in chrome. (works fine in FF and IE)
Chrome developers are notoriously slow to fix bugs and especially given the obscure nature in this case, I suspect it will never be fixed.
Using setTimeout in the onfocus event (in addition to the onclick event) solves the problem as the onfocus doesnt seem to be inhibited. However I would like to find a less hacky solution if there is one.
Ideas?
I'm writing an iPhone web app, and I want to automatically focus a text field when the page is loaded, bringing up the keyboard. The usual Javascript:
input.focus();
doesn't seem to be working. Any ideas?
It will only show the keyboard if you fire focus from a click event, so put a button on the page with a onclick that does the focus and it will show the keyboard. Completely useless except for validation (on click of submit validation code focuses on invalid element)
Edit: The following no longer works on iOS - UIWebView did allow autofocus and home screen links used to autofocus but they disabled that many versions ago.
The autofocus (see below) property doesn't work from a url in Mobile Safari but does work if you are:
using a UIWebView
using a home screen link
The fontsize of the input needs to be large enough to avoid the iOS10 zoom on double-tap (now that viewport is always zoomable) and to design the page to be sized so that it fits the screen (otherwise on page loading you get strange timing/race bugs in zoom, or if scrollable the field sometimes doesn't center to the screen properly).
autofocus: The HTML5 spec for doing this is the autofocus property of the input tag. But iOS ignores that, presumably for a cleaner UI that doesn't pop up the touch keyboard when navigating to a page. Here is a page that demonstrates the autofocus property. Before HTML5 you would call element.focus() in the window.onload event. However focus() calls are not supported on iOS except during the handler of an onclick event.
Note: this answer is old and may not be relevant to newer versions out there...
It comes as no help to you but the last poster in this thread wrote that its a bug of the webkit engine.
I can't tell if its a verified bug or not...
Last post from way back machine (as original seems to not work):
I am developing my app in pure XHTML MP / Ecmascript MP / WCSS. So
using native platform browser control api is really not an option for
me. Yes the behaviour u mention is the same as mine. I searched his
topic in the bugzilla at webkit.org and found that this indeed is a
reported bug. focus() to a text box does highlight the element but
does not provide a carat in it for the user to start entering text.
Using a timer as mentioned by "peppe#peppe.net" does not help either.
This behaviour is common across platforms (s60,iphone,android) which
use the webkit engine.
So as of now i dont see a solution to this problem.
Hope this helps
I have a similar issue, only my issue is that the focus will not occur on a 'touchend' event.
http://jsfiddle.net/milosdakic/FNVm5/
The following code will work in Chrome/Safari etc. but will fail on Mobile Safari. The only way to get it to work is to make the event on 'click', but seeing as the code is made for an iOS device, it would benefit for it to work with touch events.
It seems to be a bug with the Webkit engine.
If you are setting focus with from a click event, you need to preventDefault otherwise the click events default action will set focus on the clicked item.
A bit late maybe but for future person maybe. In our webapp running on iOS iPad (6 and more recent), we do it with a set interval:
startFocusOnTextField: function() {
this.intervalIDForTextFieldFocus = window.setInterval(function() {
document.getElementById(page.textInputFieldObj.id).focus();
}, 150);
},
Which is called on page load (jQuery mobile environment)
This is a workround:
setTimeout(function(){
input.focus();
},500);//milliseconds