I have been looking into how you could use Javascript to direct focus to a Flash movie. I've seen it discussed on Stack Overflow and other sites and it seems you cannot do this reliably except in Internet Explorer. I am just calling the .focus() method on a Flash object via Javascript.
It does in fact work in Internet Explorer, but I don't like its behavior on Firefox or other browsers. Basically, I have a username/password login field INSIDE my Flash movie, and I want to give it focus when the Flash movie loads, so you can start typing your username immediately, without having to first click the field.
The problem with Firefox is that not only does it not set the focus, you can SEE a blinking cursor inside the field in Flash, which really indicates that the field has focus. However, you still have to click.
This is counterproductive on Firefox. I would rather not even attempt to set the focus if this is the behavior. I could of course check what browser is in use and determine whether to even call .focus(), but this functionality may change in later versions of Firefox. I'd love to have a better solution, that would:
Remember the current focus before the Flash movie is dynamically added to the page (this is how I do it, I cannot display the movie as part of the initial page load).
Attempt to set focus to the Flash movie.
Check if the focus WAS properly set, so I can expect that the Flash movie is actually receiving keystrokes without an additional click.
If focus was not set, revert to whatever was focused before the Flash movie was loaded.
I am not sure how (or if) this can be done but I'd love to find out. I think document.activeElement may be useful, but I was not able to get very far with that. Thanks for any help!
This may help. It's a kind of workaround using javascript to avoid having to focus on the actual Flash object at all...
https://github.com/englandrp/Cross-browser-Flash-tabbing-and-focus-solution
Try something like this:
private function setInitialFocus():void {
myInput.setFocus();
ExternalInterface.call("function() { var app = document.getElementById('myApp'); app.tabIndex = 0; app.focus(); }");
}
You will also want to set the tabIndex to 0 on your input control.
http://kb2.adobe.com/cps/155/tn_15586.html
Firefox Focus and Actual Links
and this one too
Related
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
I have a very, very weird issue that only seems to be an issue in Chrome.
When a user comes on the website, the user cannot focus any element (via mouse click, if they focus it via tabbing, the elements don't get the 'focused' state either) and that's only an issue in Chrome. That is, until the user resizes the window, minimizes the window, opens a new tab, opens developer tools, etc. Reloading the page does nothing. However, as soon as focus is "enabled", the user can navigate/refresh with purging cache, etc., close the browser and open it again, and everything works normally - the elements get the 'focused' state normally.
This behaviour can only be reproduced in Chrome and not on localhost.
The difference between localhost and beta environment is:
beta env requires authentication (basic http auth)
files in development env are concated in a single JS and single CSS file and both are minimized
beta env includes hotjar, while there's no hotjar on localhost
There are no custom event listeners that would listen for the 'resize' event. There are no errors in console and all javascript that doesn't depend on focused element state gets executed correctly. Hover events and all CSS styling that depends on hovered state all work correctly.
The main issue is, that a form which has to be filled out and includes a datepicker, cannot be filled out and thus the users can't really interact with the page. Datepicker doesn't open and, as the input elements don't get the focused state, they don't visually change (CSS :focused selector isn't working either) and thus give the impression to the user that they cannot type in the normal text inputs (which works, after clicking on the input, it is possible to type in the input).
I have tried removing hotjar and the problem persisted. The only thing that made the problem go away was removing the basic auth, however, that is not an option in this stage (it's a closed beta test, so we need to limit the access only to the users with password).
I also find it extremely odd that basic auth would interfere with the focused state of elements, especially as the error persists after you refresh and only goes away as soon as you interact with browser itself (minimize, open new tab, do anything that resizes your browser window or document), after that it works correctly and there are no errors whatsoever.
The problem only started to appear recently, but I do not believe it's an issue with the app itself, as I tried rolling back to a couple months old build and the problem persists. All of that makes me believe it's a bug in Chrome, but what can be done to fix it?
EDIT: I also tried to add autofocus property to an input element and, in beta environment, it doesn't get focused.
So it seems it indeed is a Chrome bug that's present both on mobile (Android and iOS) Chrome browsers, as well as desktop Chrome browser (tested both on a Windows and a Mac). I submitted an official bug report. In the bug report, a fellow user made a website that's accessible only through basic auth and only has 2 basic inputs, the input should get a red border on focus. As expected, after opening the webpage in Chrome (for ease of use - incognito mode), the input doesn't get focus and the border doesn't change.
For those who are also affected by this bug in Chrome, you can track the bug progress here: https://bugs.chromium.org/p/chromium/issues/detail?id=740652
Meanwhile, here's a hacky solution for those interested:
$(document).on("ready", function() {
var $inputs = $("input");
$inputs.off("click.trick");
if (!sessionStorage.fixedChromeFocus) {
sessionStorage.fixedChromeFocus = "true";
$inputs.on("click.trick", function() {
var win = window.open("/", "_blank");
setTimeout(function() {win.close()}, 1);
$inputs.off("click.trick");
});
}
});
The goal is to, somehow, interact with the browser outside of the current page, to make it somehow lose focus. You cannot use JS to minimize browser, cannot resize it, cannot open dev tools. What you can do, though, is open a new window. Of course, if you open a new window immediately, a pop-up blocker (as most people have it) will block it and the window itself (or rather your current tab) won't lose focus. Opening a new window can only be done as a reaction to a user event (without triggering potential pop-up blocker).
I also use some browser detection so the code will only be executed for Chrome and, using server-side conditioning, only for builds that include basic auth.
What the code does, quite self evidently, is that as soon as a user clicks on an input, it opens a new tab and quickly closes it, 1ms later. To prevent this from happening all the time, on every page load, sessionStorage, which gets cleared automatically after tabs from that domain are closed, is used (and we've already established that once focus starts working correctly, it will work as long as you keep your browser open).
The effect of this code is that the user will see a quick white flash the first time he clicks on the input, but everything will work correctly
Am using the confirm message when delete the record from the table.When I click and delete the records got "prevent this page from creating additional dialogs chrome".How to disable the prevent this page from creating additional dialogs in Chrome alert?
What are the chrome settings changes are required to disable the messages?I googled lot but no luck.
Thanks in Advance..
As others have said, this is a built-in safety net on Chrome (and other browsers, Firefox for example) that you can't work around (nor should you try). Its purpose is to prevent websites "locking" the page by repeatedly throwing alerts; for every alert you dismiss, a new one surfaces. It used to be the case that the whole browsers was "locked" until the alert was dismissed (try it in IE6).
At the risk of going Off Topic, I would be inclined to re-consider your approach: instead of asking the user to confirm an action, give them a means to undo it instead. More often than not, the "delete" action was intentional, so adding the extra interaction is likely to be a PITA for power users. Similarly, it's entirely likely people will become blind to the alerts and dismiss them without even reading them, such that they serve no purpose at all.
See: http://patternry.com/p=undo/ and Never use a warning when mean Undo
You can't. It's a behavior of the browser. It doesn't depend on JavaScript.
Its the default behaviour of Chrome. If you are showing frequent alert/confirm then it will show this, and the worst thing is if the user check h check box, no alert and confirm will be shown afterwards.
You can use Jquery Poup to show any message or get any data from users
There are some video streaming sites that pop up an ad anytime you click anywhere on the page. The problem is, you have to click on the page to press play! So I was thinking of making a UserScript that disables the script that does this. The only problem is, I already disable all the scripts on the site and when I do it still pops up. Is there a way that I can disable them ? I'm also using jQuery, so if I can do it through their interface, that would be great.
edit: Two perfect examples of such sites are daclips.in and gorrilavid.in
I have Adblocker Plus, and it seems like it is not recognizing "on Click" events as pop-ups, rather normal clicked links. And the logic is simple, no Adblocker will block you from clicking something intentionally and it (the link) opening in another window/tab.
The problem is the new window contains your clicked Url, while the original window/tab "Refreshes" (i.e. redirects) to another url.
Advertising companies seem to use this trick to bypass adblocking software.
Just ditch Chrome and use Firefox. Firefox already have built-in mouse-click popups. I think all addons like Adguard or Adblock can not disable mouse-click popups. If you use Firefox, these are the steps:
Type about:config in the browser's address bar and hit the enter key.
First time users need to confirm that they be careful on the next page.
Type or paste dom.popup_allowed_events into the search field.
The value of the preference highlights all events that are allowed to spawn popups.
Edit the value to remove some or all of the items here.
Why not just use a browser extension such as AdBlock?
https://chrome.google.com/webstore/detail/adblock/gighmmpiobklfepjocnamgkkbiglidom?hl=en
My go-to is right click and open in new tab. onClick events only happen with a left click. It's cumbersome but it still ends up being less work than closing the pop-up and whatever annoying prompts it may have.
I do not there's a practical solution for this.
Moreover, I think some of the answers here are missing the specific case in OP, where clicking anywhere on the page will cause the pop up to happen, not just clicking on links. According to this, neither right-clicking then choosing "open", nor noticing and blocking the target URL will help. I do not know of an add blocker that helps here either, because it's not trivial to meaningfully filter a click event that is taking place on the whole page object.
Only the solution provided by #Monkey would work, at the drawback of possibly breaking other things.
I have a web page where users can play flash games. We are now making some changes to the page which requires the games to be embedded with wmode=transparent or wmode=opaque so that we can show HTML elements on-top of the flash games. The problem is that in Internet Explorer (on all versions) the whole page scrolls if a user presses the up/down arrow keys. I've tried everything I can think of and I've spent a whole day searching for a solution without success.
So far I've tried putting the game inside a iframe and I tried disabling the up/down keys with JS, none of which solves my problem.
The requirements are: wmode has to be transparent or opaque and I can't modify the flash games.
The only way to prevent scrolling when using wmode=transparent in Flash is to prevent scrolling using the arrow keys for the whole page. This page summarizes it best.
Basically, when transparent mode is active, the keyboard events in IE are propagated through to the browser; I don't know how to prevent scrolling (haven't tested), but you'd basically have to prevent keyboard scrolling globally.
This discussion highlights a possible workaround for IE8, and an example of the implementation using jQuery here. I don't have a copy of IE on me right now, but it might be worth a try.
AFAIK, though, games in Flash usually don't work very well with wmode=transparent, since focus can be stolen without user interaction. Your best bet would be reworking the page so as not to require Flash to have HTML overlays (even YouTube avoids having transparent set on their page, and they own the whole content).
The user needs to focus the flash movie first before any key actions are intercepted. This is actually a good behaviour, and shouldn’t be changed.
It would be a good idea to somehow ask the user to focus the movie voluntarily, maybe by putting a bit start button on it which they need to click first. Then all key actions should be sent to Flash.
How about some JS magic, if it works.
http://api.jquery.com/keypress/
http://api.jquery.com/event.preventDefault/
Register a KeyPress event handler on the object/embed tags. Let's say you have flash object with id #flashobj
$('#flashobj').keypress( function(event) { event.preventDefault(); } );
Or, more tricky, if the binding on flash object/embed wouldn't work, you can bind the keypress on the whole window, and check something along the lines of:
if (event.target.tagName.toLower() == "object") ...
Mileage may vary, as I remember it event.target is not very reliable...
Hopefully, flash will catch the keyboard event, and the page will ignore it. I know you said you tried it, but your approach might have been different (I suggested two distinctly different ways to do it, one might work)
It seems that there is simply no way around this. We will just have to accept the fact that HTML stuff (FB like chat in our case) will hide behind flash games.
But I still hope somebody proves me wrong :)