Chrome HTML5 Video - Blurs webpage on resize - javascript

I'm using the BigVideo.js plugin (http://dfcb.github.io/BigVideo.js/) in a website of mine. I am also using the following Javascript to scale the site up or down as the user resizes their browser.
$(document).ready(function() {
scaleSite();
});
$( window ).resize(function() {
scaleSite();
});
// Scale Site to Fit Window
function scaleSite() {
var windowWidth = $( window ).width();
var defaultWidth = 1200;
var scaleWidth = 1;
var isMobile = false;
if( /Android|webOS|iPhone|iPad|iPod|BlackBerry|IEMobile|Opera Mini/i.test(navigator.userAgent) ) {
// MOBILE ACTIONS
} else {
// STANDARD ACTIONS
if(windowWidth >= defaultWidth) {
scaleWidth = windowWidth/defaultWidth;
var scaleWidthRounded = Math.round( scaleWidth * 10 ) / 10;
} else {
scaleWidth = windowWidth/defaultWidth;
var scaleWidthRounded = Math.round( scaleWidth * 10 ) / 10;
}
$("#mainDiv").css("-webkit-transform", "scale("+scaleWidth+")");
$("#mainDiv").css("-moz-transform", "scale("+scaleWidth+")");
$("#mainDiv").css("-o-transform", "scale("+scaleWidth+")");
$("#mainDiv").css("msTransform", "scale("+scaleWidth+")");
$("#fixedHeader").css("-webkit-transform", "scale("+scaleWidth+")");
$("#fixedHeader").css("-moz-transform", "scale("+scaleWidth+")");
$("#fixedHeader").css("-o-transform", "scale("+scaleWidth+")");
$("#fixedHeader").css("msTransform", "scale("+scaleWidth+")");
// RESET BODY HEIGHT
var mainDivHeight = ($("#mainDiv").height()*scaleWidthRounded);
$("body").css("height", mainDivHeight);
$("html").css("height", mainDivHeight);
}
}
Strangely enough, when I load a page that has a video playing on it, and I try to resize the browser, the scaling works correctly but everything BUT the video gets a little blurred.
I had trouble with this same issue when using the Jssor Slider plugin, it also caused my pages to blur after resizing the browser window. I resolved that issue by adding the $HWA : false to the options for the Jssor Slider, which disabled the plugins ability to use Hardware Acceleration.
Is there something in the BigVideo.js or the underlying Video.js file that I can adjust to prevent hardware acceleration there as well? As it seems to be the same cause.
UPDATE
I just noticed the blur issue ONLY happens in Chrome. Firefox and Internet Explorer both work fine with no problem, but in Chrome, all content on the page OTHER than the BigVideo itself gets slightly blurred.
UPDATE 2
Okay, so I just noticed that if I inspect element on the div containing the HTML5 <video> tag and I delete it from the DOM, my text "snaps" back into focus. I went through the div item by item and unchecked CSS styles thinking that would lead me to the one that is causing problems but still no luck.
Why would deleting the element from the DOM in the Chrome DEV tools snap the rest of the page back into focus and remove the blur?
Below is a screen shot showing an example of the text on my page BEFORE I resize the browser window, and the result AFTER I resize. Again, if I resize, the page gets a bit blurry, and if I delete the element containing the <video> using the Chrome DEV tools, the blur goes away.
UPDATE 3
So I removed the BigVideo plugin and replaced it with a generic HTML5 <video> tag, the video still plays and the blur issue is still present when resizing the browser. So it's something with the way chrome is handling the HTML5 video along with my scale site script.
JSFIDDLE
https://jsfiddle.net/h5vu7La7/3/
Not sure if this will help or not, but if you resize the window on this jsFiddle you can see the text (in Chrome) is blurred a bit. If you remove the <video> from the HTML and re-run and resize it does not blur.
Also noticed if you run the fiddle, and inspect element on the video and delete it from the DOM, the text snaps back into focus.

If you are applying transform scale CSS rule to a HTML element that has child elements (I'm guessing those visible in the pictures are inside one of the divs you are scaling), they will get somewhat blurry due the layer moving to 3D plane.
Open inspector and apply transform: scale(1.01); to the blue button below here on SO and you'll realize what I mean.
Instead of scale, you should just resize the width and height of the video element.

Related

JQuery/CSS/Chrome scrolling bug (viewport drops to end of element when height changes)

On some of our pages, we've got some legacy JQuery that detects when a page is scrolling and then sets the height of the main element, to position the footer correctly on both mobile and desktop:
function scrollPage(event){
base.keepMainMarginOverFooter();
// other functions
}
$(window).on('scroll',scrollPage);
This is the offending function:
keepMainMarginOverFooter:function() {
// Adjusts container height so footer is clickable but can also be revealed on mobile
var h = 0;
$('.fp-section.visible').children().each(function() {
h+= $(this).outerHeight()
});
$('#main').css({ height: h });
}
And it seems that there's a bug in Chrome (Version 61.0.3163.100) that seems to trigger if you're actively scrolling during any event which triggers the above code (we also have some JQuery functions that , which automatically takes you to the end of the #main section, ie the bottom of the page. Or at least I guess it's a bug - this doesn't seem to happen in Safari (Version 11.0 12604.1.38.1.7), and it doesn't happen if you wait a couple of seconds after page load before scrolling.
It's tempting to remove this function for something simpler, but it's in the middle of enough dependencies that that wouldn't be trivial.
Is this a known issue with a decent workaround?

Particles js not displaying properly until the resize event is triggered

As stated above, I am using the particles.js library to add a background to a div on a site that I am designing.
When the page loads, the correct div has the animation as a background, but it always starts way too "zoomed in". It appears to be using too large a default screen size, however whenever the screen area is changed either by directly changing the window size or opening the developer console it triggers the "resize" event and then everything is displayed correctly.
The resize event code is as follows:
if(pJS && pJS.interactivity.events.resize){
window.addEventListener('resize', function(){
pJS.canvas.w = pJS.canvas.el.offsetWidth;
pJS.canvas.h = pJS.canvas.el.offsetHeight;
/* resize canvas */
if(pJS.tmp.retina){
pJS.canvas.w *= pJS.canvas.pxratio;
pJS.canvas.h *= pJS.canvas.pxratio;
}
pJS.canvas.el.width = pJS.canvas.w;
pJS.canvas.el.height = pJS.canvas.h;
/* repaint canvas on anim disabled */
if(!pJS.particles.move.enable){
pJS.fn.particlesEmpty();
pJS.fn.particlesCreate();
pJS.fn.particlesDraw();
pJS.fn.vendors.densityAutoParticles();
}
/* density particles enabled */
pJS.fn.vendors.densityAutoParticles();
});
}
What I am looking for is either a way to get the animation to load properly, or to trigger the resize immediately upon page load so that it always looks right to page visitors.
What I have tried
I have tried manually setting the size of the canvas element that the library creates, however that does not work. I have also tried changing the size of the div that contains the element, and that also does not work.
Potential conflicts or easier solutions
I am using Jquery 3.1.1 and Bootstrap 3
To trigger the resize you do:
$(window).trigger('resize');
when the dom is loaded

$(window).resize() executes when scrolling on mobile devices

For example:
HTML
<div><p>A lot of text that goes off the page so you have to scroll down.........</p></div>
JavaScript
$(window).resize(function(){
$("div").append("<p>appended</p>");
});
This works and appends the paragraph as expected on resize, but it is also appended when I scroll down. This means when I get to the end of the original text there is about 20 appended paragraphs.
This is only happening on mobile devices (so far I've checked Chrome, Safari and Firefox), not on desktop browsers.
Is there a way to stop this happening and have the paragraph appended only when the window (that you see) is resized?
Or maybe only have the code within the resize execute every so often?
Thanks.
The problem with mobile devices is that they have the browser toolbars that are hidden when you scroll and this leads to screen change (activates the resize event) and this means that you have to make some validations to your code and detect why was the resize event fired.
One way I have used is by saving the window width and checking if the correct window width is the same or changed. If it changes then it means that the append should happen (in your case).
var dwidth = $(window).width();
$(window).resize(function(){
var wwidth = $(window).width();
if(dwidth!==wwidth){
dwidth = $(window).width();
console.log('Width changed');
}
});

iPad Web App: Detect Virtual Keyboard Using JavaScript in Safari?

I'm writing a web app for the iPad (not a regular App Store app - it's written using HTML, CSS and JavaScript). Since the keyboard fills up a huge part of the screen, it would make sense to change the app's layout to fit the remaining space when the keyboard is shown. However, I have found no way to detect when or whether the keyboard is shown.
My first idea was to assume that the keyboard is visible when a text field has focus. However, when an external keyboard is attached to an iPad, the virtual keyboard does not show up when a text field receives focus.
In my experiments, the keyboard also did not affect the height or scrollheight of any of the DOM elements, and I have found no proprietary events or properties which indicate whether the keyboard is visible.
I found a solution which works, although it is a bit ugly. It also won't work in every situation, but it works for me. Since I'm adapting the size of the user interface to the iPad's window size, the user is normally unable to scroll. In other words, if I set the window's scrollTop, it will remain at 0.
If, on the other hand, the keyboard is shown, scrolling suddenly works. So I can set scrollTop, immediately test its value, and then reset it. Here's how that might look in code, using jQuery:
$(document).ready(function(){
$('input').bind('focus',function() {
$(window).scrollTop(10);
var keyboard_shown = $(window).scrollTop() > 0;
$(window).scrollTop(0);
$('#test').append(keyboard_shown?'keyboard ':'nokeyboard ');
});
});
Normally, you would expect this to not be visible to the user. Unfortunately, at least when running in the Simulator, the iPad visibly (though quickly) scrolls up and down again. Still, it works, at least in some specific situations.
I've tested this on an iPad, and it seems to work fine.
You can use the focusout event to detect keyboard dismissal. It's like blur, but bubbles. It will fire when the keyboard closes (but also in other cases, of course). In Safari and Chrome the event can only be registered with addEventListener, not with legacy methods. Here is an example I used to restore a Phonegap app after keyboard dismissal.
document.addEventListener('focusout', function(e) {window.scrollTo(0, 0)});
Without this snippet, the app container stayed in the up-scrolled position until page refresh.
If there is an on-screen keyboard, focusing a text field that is near the bottom of the viewport will cause Safari to scroll the text field into view. There might be some way to exploit this phenomenon to detect the presence of the keyboard (having a tiny text field at the bottom of the page which gains focus momentarily, or something like that).
maybe a slightly better solution is to bind (with jQuery in my case) the "blur" event on the various input fields.
This because when the keyboard disappear all form fields are blurred.
So for my situation this snipped solved the problem.
$('input, textarea').bind('blur', function(e) {
// Keyboard disappeared
window.scrollTo(0, 1);
});
hope it helps.
Michele
Edit: Documented by Apple although I couldn't actually get it to work: WKWebView Behavior with Keyboard Displays: "In iOS 10, WKWebView objects match Safari’s native behavior by updating their window.innerHeight property when the keyboard is shown, and do not call resize events" (perhaps can use focus or focus plus delay to detect keyboard instead of using resize).
Edit: code presumes onscreen keyboard, not external keyboard. Leaving it because info may be useful to others that only care about onscreen keyboards. Use http://jsbin.com/AbimiQup/4 to view page params.
We test to see if the document.activeElement is an element which shows the keyboard (input type=text, textarea, etc).
The following code fudges things for our purposes (although not generally correct).
function getViewport() {
if (window.visualViewport && /Android/.test(navigator.userAgent)) {
// https://developers.google.com/web/updates/2017/09/visual-viewport-api Note on desktop Chrome the viewport subtracts scrollbar widths so is not same as window.innerWidth/innerHeight
return {
left: visualViewport.pageLeft,
top: visualViewport.pageTop,
width: visualViewport.width,
height: visualViewport.height
};
}
var viewport = {
left: window.pageXOffset, // http://www.quirksmode.org/mobile/tableViewport.html
top: window.pageYOffset,
width: window.innerWidth || documentElement.clientWidth,
height: window.innerHeight || documentElement.clientHeight
};
if (/iPod|iPhone|iPad/.test(navigator.platform) && isInput(document.activeElement)) { // iOS *lies* about viewport size when keyboard is visible. See http://stackoverflow.com/questions/2593139/ipad-web-app-detect-virtual-keyboard-using-javascript-in-safari Input focus/blur can indicate, also scrollTop:
return {
left: viewport.left,
top: viewport.top,
width: viewport.width,
height: viewport.height * (viewport.height > viewport.width ? 0.66 : 0.45) // Fudge factor to allow for keyboard on iPad
};
}
return viewport;
}
function isInput(el) {
var tagName = el && el.tagName && el.tagName.toLowerCase();
return (tagName == 'input' && el.type != 'button' && el.type != 'radio' && el.type != 'checkbox') || (tagName == 'textarea');
};
The above code is only approximate: It is wrong for split keyboard, undocked keyboard, physical keyboard. As per comment at top, you may be able to do a better job than the given code on Safari (since iOS8?) or WKWebView (since iOS10) using window.innerHeight property.
I have found failures under other circumstances: e.g. give focus to input then go to home screen then come back to page; iPad shouldnt make viewport smaller; old IE browsers won't work, Opera didnt work because Opera kept focus on element after keyboard closed.
However the tagged answer (changing scrolltop to measure height) has nasty UI side effects if viewport zoomable (or force-zoom enabled in preferences). I don't use the other suggested solution (changing scrolltop) because on iOS, when viewport is zoomable and scrolling to focused input, there are buggy interactions between scrolling & zoom & focus (that can leave a just focused input outside of viewport - not visible).
During the focus event you can scroll past the document height and magically the window.innerHeight is reduced by the height of the virtual keyboard. Note that the size of the virtual keyboard is different for landscape vs. portrait orientations so you'll need to redetect it when it changes. I would advise against remembering these values as the user could connect/disconnect a bluetooth keyboard at any time.
var element = document.getElementById("element"); // the input field
var focused = false;
var virtualKeyboardHeight = function () {
var sx = document.body.scrollLeft, sy = document.body.scrollTop;
var naturalHeight = window.innerHeight;
window.scrollTo(sx, document.body.scrollHeight);
var keyboardHeight = naturalHeight - window.innerHeight;
window.scrollTo(sx, sy);
return keyboardHeight;
};
element.onfocus = function () {
focused = true;
setTimeout(function() {
element.value = "keyboardHeight = " + virtualKeyboardHeight()
}, 1); // to allow for orientation scrolling
};
window.onresize = function () {
if (focused) {
element.value = "keyboardHeight = " + virtualKeyboardHeight();
}
};
element.onblur = function () {
focused = false;
};
Note that when the user is using a bluetooth keyboard, the keyboardHeight is 44 which is the height of the [previous][next] toolbar.
There is a tiny bit of flicker when you do this detection, but it doesn't seem possible to avoid it.
The visual viewport API is made for reacting to virtual keyboard changes and viewport visibility.
The Visual Viewport API provides an explicit mechanism for querying and modifying the properties of the window's visual viewport. The visual viewport is the visual portion of a screen excluding on-screen keyboards, areas outside of a pinch-zoom area, or any other on-screen artifact that doesn't scale with the dimensions of a page.
function viewportHandler() {
var viewport = event.target;
console.log('viewport.height', viewport.height)
}
window.visualViewport.addEventListener('scroll', viewportHandler);
window.visualViewport.addEventListener('resize', viewportHandler);
Only tested on Android 4.1.1:
blur event is not a reliable event to test keyboard up and down because the user as the option to explicitly hide the keyboard which does not trigger a blur event on the field that caused the keyboard to show.
resize event however works like a charm if the keyboard comes up or down for any reason.
coffee:
$(window).bind "resize", (event) -> alert "resize"
fires on anytime the keyboard is shown or hidden for any reason.
Note however on in the case of an android browser (rather than app) there is a retractable url bar which does not fire resize when it is retracted yet does change the available window size.
Instead of detecting the keyboard, try to detect the size of the window
If the height of the window was reduced, and the width is still the same, it means that the keyboard is on.
Else the keyboard is off, you can also add to that, test if any input field is on focus or not.
Try this code for example.
var last_h = $(window).height(); // store the intial height.
var last_w = $(window).width(); // store the intial width.
var keyboard_is_on = false;
$(window).resize(function () {
if ($("input").is(":focus")) {
keyboard_is_on =
((last_w == $(window).width()) && (last_h > $(window).height()));
}
});
Try this one:
var lastfoucsin;
$('.txtclassname').click(function(e)
{
lastfoucsin=$(this);
//the virtual keyboard appears automatically
//Do your stuff;
});
//to check ipad virtual keyboard appearance.
//First check last focus class and close the virtual keyboard.In second click it closes the wrapper & lable
$(".wrapperclass").click(function(e)
{
if(lastfoucsin.hasClass('txtclassname'))
{
lastfoucsin=$(this);//to avoid error
return;
}
//Do your stuff
$(this).css('display','none');
});`enter code here`
The idea is to add fixed div to bottom.
When virtual keyboard is shown/hidden scroll event occurs.
Plus, we find out keyboard height
const keyboardAnchor = document.createElement('div')
keyboardAnchor.style.position = 'fixed'
keyboardAnchor.style.bottom = 0
keyboardAnchor.style.height = '1px'
document.body.append(keyboardAnchor)
window.addEventListener('scroll', ev => {
console.log('keyboard height', window.innerHeight - keyboardAnchor.getBoundingClientRect().bottom)
}, true)
This solution remembers the scroll position
var currentscroll = 0;
$('input').bind('focus',function() {
currentscroll = $(window).scrollTop();
});
$('input').bind('blur',function() {
if(currentscroll != $(window).scrollTop()){
$(window).scrollTop(currentscroll);
}
});
The problem is that, even in 2014, devices handle screen resize events, as well as scroll events, inconsistently while the soft keyboard is open.
I've found that, even if you're using a bluetooth keyboard, iOS in particular triggers some strange layout bugs; so instead of detecting a soft keyboard, I've just had to target devices that are very narrow and have touchscreens.
I use media queries (or window.matchMedia) for width detection and Modernizr for touch event detection.
As noted in the previous answers somewhere the window.innerHeight variable gets updated properly now on iOS10 when the keyboard appears and since I don't need the support for earlier versions I came up with the following hack that might be a bit easier then the discussed "solutions".
//keep track of the "expected" height
var windowExpectedSize = window.innerHeight;
//update expected height on orientation change
window.addEventListener('orientationchange', function(){
//in case the virtual keyboard is open we close it first by removing focus from the input elements to get the proper "expected" size
if (window.innerHeight != windowExpectedSize){
$("input").blur();
$("div[contentEditable]").blur(); //you might need to add more editables here or you can focus something else and blur it to be sure
setTimeout(function(){
windowExpectedSize = window.innerHeight;
},100);
}else{
windowExpectedSize = window.innerHeight;
}
});
//and update the "expected" height on screen resize - funny thing is that this is still not triggered on iOS when the keyboard appears
window.addEventListener('resize', function(){
$("input").blur(); //as before you can add more blurs here or focus-blur something
windowExpectedSize = window.innerHeight;
});
then you can use:
if (window.innerHeight != windowExpectedSize){ ... }
to check if the keyboard is visible. I've been using it for a while now in my web app and it works well, but (as all of the other solutions) you might find a situation where it fails because the "expected" size is not updated properly or something.
Perhaps it's easier to have a checkbox in your app's settings where the user can toggle 'external keyboard attached?'.
In small print, explain to the user that external keyboards are currently not detectable in today's browsers.
I did some searching, and I couldn't find anything concrete for a "on keyboard shown" or "on keyboard dismissed". See the official list of supported events. Also see Technical Note TN2262 for iPad. As you probably already know, there is a body event onorientationchange you can wire up to detect landscape/portrait.
Similarly, but a wild guess... have you tried detecting resize? Viewport changes may trigger that event indirectly from the keyboard being shown / hidden.
window.addEventListener('resize', function() { alert(window.innerHeight); });
Which would simply alert the new height on any resize event....
I haven't attempted this myself, so its just an idea... but have you tried using media queries with CSS to see when the height of the window changes and then change the design for that? I would imagine that Safari mobile isn't recognizing the keyboard as part of the window so that would hopefully work.
Example:
#media all and (height: 200px){
#content {height: 100px; overflow: hidden;}
}
Well, you can detect when your input boxes have the focus, and you know the height of the keyboard. There is also CSS available to get the orientation of the screen, so I think you can hack it.
You would want to handle the case of a physical keyboard somehow, though.

A bit of problem with implementing a modal dialog

I am developing a modal dialog as a part of a web application. There is one thing that's been of a puzzle to me. Please watch a movie clip that I just uploded at http://inter.freetzi.com/example/. I feel strongly that I have to accompany my question with a video because this is the case when it's better to see once, than to hear 100 times.
(It could be vertical scrolling, or both vertical and horizontal at the same time. But I am using horizontal scrolling in my example, so watch for it.)
Here's about my question:
Width of the transparent mask affects the width of the page itself. But in Opera, for exemple, every time the window gets resized, the page gets width that is at most close to 'true'. While in IE, once the transparent mask has affected the width, afterwards the page remembers it and stays with it. What is the problem and how to settle it? How to make IE behave the way Opera does?
In my project, I do the following:
//curViewpointW and curViewpointH are current width and height of the viewpoint (current is meant to be the moment of the resize event)
oMask.style.width = curViewpointW + 'px';
oMask.style.height = curViewpointH + 'px';
var pageWH = getPageWH(); //getPageWH() is a function that gets current width and height of the page (with scrolling if there is any)
var curPageW = pageWH[0];
var curPageH = pageWH[1];
if (curPageW > curViewpointW) {
oMask.style.width = curPageW + 'px';
}
if (curPageH > curViewpointH) {
oMask.style.height = curPageH + 'px';
}
But IE ignores that somehow...
P.S. It's jQuery in my example, so many of you may have used its dialog before.
Have you looked into setting an onresize event handler that will adjust your mask dimensions when the window is resized? If you are using Prototype, you can set up such a handler unobtrusively like this:
Event.observe(document.onresize ? document : window, "resize", function() {//dostuff});
courtesy of the Roberto Cosenza blog

Categories

Resources