Scrolling stuck after interacting with iframe - javascript

I have a site in which I'm implementing parallax using skrollr.js.
In that site I'm also integrating Flash objects created by Storyline, in iframes.
My problems is that after the user interacts with the Storyline in the iframe, when he tries to continue scrolling to the rest of the content, sometimes the page gets stuck and stops scrolling.
This happens only in Firefox (it doesn't happen in Chrome, and surprisingly enough - not in IE11 either).
The only way to "unstick" the scroll is by the user clicking the browser window again. Of course, that's not intuitive to the user, so I'm trying to find a way to emulate that click programmatically.
I thought that maybe the focus gets lost and the mouse click returns it, so I tried returning the focus to the body programmatically, but that doesn't help:
setInterval( function () {
if ( document.activeElement.tagName.toLowerCase() === "iframe" ) {
document.activeElement.blur();
}
}, 1000 );

In the end, this problem got solved by changing the wmode parameter from window to transparent.
The way to do that is as follows:
I can't find where to change wmode to transparent in Storyline, but I found how to change it in the generated files :
In the root of the generated directory, find the story.html file.
Go to line 134, where the g_strWMode parameter is defined.
Change its value from window to transparent.
That's it!

Related

Can't focus elements on load in Chrome - very weird bug (in Chrome?)

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

use jQuery to disable all clicking actions except scrollbar

I am trying to make a page COMPLETELY UNCLICKABLE (both right click and left click) and to display a message when someone clicks. Since I know that this will raise lots of questions such as
"why would anyone ever want to do this...this is stupid...then nobody
can navigate the site...and it doesn't protect your content
anyway...etc"
here is the explanation of my purpose. I have a page that is at the moment only a graphic mockup of what the finished website will eventually look like. No matter how many times I explain that the mockup is ONLY AN IMAGE and not a real navigable website, they still email me to say that they cannot click on the menus and links. Since it is a single page mockup, I want to pop up an alert() message (can't use a modal because you can't click to dismiss it if clicking is disabled) to let them know that they have clicked something non-functional. I am trying to do this in as few lines of code as possible, and have the following working at the moment:
<script>
$('html').mousedown(function(event) {
event.preventDefault();//To prevent following the link
alert('Demo Graphic Only...clicking on stuff will NOT work at this point.');
});
</script>
The issue is that when using .mousedown I capture the user trying to click on the browser scroll-bar to scroll down. I was surprised by this since it is not part of the actual PAGE CONTENT but rather a part of the BROWSER...but it is catching it nonetheless. I tried using .click in place of .mousedown however only seem to catch a normal (left) click in that case... Does anyone know how to easily (minimal lines of code if possible) capture the left AND right click event, but allow user interaction with the browser scrollbar?
Try this :
$(document).click(function(event) {
event.preventDefault();//To prevent following the link
console.log('Demo Graphic Only...clicking on stuff will NOT work at this point.');
});
This Function will be called when click is made on the page , not on the Scrollbars
Try to use
event.stopPropagation();
or
event.stopImmediatePropagation()
For people who come across this question, an alternative approach, good especially if you need to prevent mousedown specifically:
Put the scrolling content in a wrapper element and prevent mousedown only on the inner element. Set the wrapper element to overflow: auto; height: 100%;

Completely disable focus of elements in a parent

Suppose I have a link, which would fade out the entire page when link is clicked. The reason I fade out the page is because a next page is about to load, but it is not loaded yet. I can use pointer-events: none which will disable any mouse events until the next page is loaded.
Suppose it was done with the keyboard, I could use the following to prevent double-enter, or to cleanly disable all elements within, for example tab-enter would be disabled this way as well.
parent.onkeydown = fals
parent.onkeyup = fals
parent.onkeypress = fals
function fals() {return false}
This works well for short loads, but if it takes a long time to load, the user may notice the following difficulties.
Cannot tab away from the a tag.
Cannot use several of the keyboard shortcuts which would control the browser.
Able to tab into the disabled area from the address bar.
Is there a modern and slick way to prevent these 3 problems, other than setting an onfocus=blur for all of the child elements? I do not care about IE today.
I think the commonly accepted way of dealing with things like what you're talking about is to use Modal's, which is to say when they click that link, you pop up a box that says 'Processing' or something like that, and you create a fullscreen div with a z-index above everything else so the user can't click / interact with anything else on the screen until you're done doing whatever it is you are doing.
See http://twitter.github.com/bootstrap/javascript.html#modals for an example of what i'm talking about.

Chrome and IE focus on Iframe

I got an iframe on my page, and a menu that the user can select from to see the gallery he wants inside the iframe.
The gallery in the iframe have the abilty to be controled by the keyboard.
My problem is that I want to change the focus to the iframe so the gallery can be control, immediately afther the user choose the gallery.
I tried a few things and every code worked on Firefox without any problem, but with Chrome, and IE nothing really worked, in IE, and Chrome I have to manually press on the iframe to be able to control it.
(I'm pretty new in JavaScript and I'm using jQuery)
This code I toke from another thread for IE problem and its still didn't work (its only workin in Firefox).
$("#LinkTest li a").focusin(function () {
setTimeout(function () {
$('#iframeBoxID').focus();
}, 100);
});
Any ideas?
I think this might solve your problem, by focusing on the content window instead of the iframe element.
$('#iframeBoxID').get(0).contentWindow.focus();

Javascript/Flash focus issue on different browsers

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

Categories