I'm using Videojs Framework to show video on a page, but there is a problem with PictureInPicture functionality. I'm trying to go in PictureInPicture mode automatically when user scrolls down, and again when user scrolls up (back to the actual video player) exit the PictureInPicture mode.
The first time I scroll down and up it's all working, but any attempt after that fails.
Here's a pen to my code: https://codepen.io/madefortestonly/pen/GRJxMya?editors=1011
This is the error message I got from the catch block:
DOMException: Failed to execute 'requestPictureInPicture' on 'HTMLVideoElement': Must be handling a user gesture if there isn't already an element in Picture-in-Picture.
at Html5.requestPictureInPicture (https://vjs.zencdn.net/7.6.6/video.js:22669:23)
at Player.techGet_ (https://vjs.zencdn.net/7.6.6/video.js:26085:34)
at Player.requestPictureInPicture (https://vjs.zencdn.net/7.6.6/video.js:26787:21)
at Player.<anonymous> (pen.js:75:16)
at https://vjs.zencdn.net/7.6.6/video.js:4530:9
By the way, someone seemed to have exactly the same problem as I had in here:
Why video.requestPictureInPicture() works only once?
It looks like you need to click on the page for scroll to work for the next attempts because scroll is not part of the user-trusted events.
I tried to simulate a click with javascript on scrolling up but so far no luck.
How can I fix my code to automatically go PictureInPicture back and forth on scrolling without telling the user that he/she needs to click somewhere on the page?
You can't get around this, as you can't forge user interation. An alternative implementation, like reszing and repositioning the player within the page, might be a better option for your use case than the browser's native PinP.
Related
I found something weird. Desktop and mobile browsers do not work the same way regarding back button.
I have hamburger menu overlay, when I click it, it opens (absolute position DIV). When I click on the link inside this overlay, on desktop, it goes to the new page. Back button then brings the previous page back, WITHOUT the overlay. This is my expected behavior.
But as I've seen, on mobile (at least on Chrome, but I think on others also), when I have overlay open and click on a link, I get to the new page, but with back I get to the previous page with the overlay STILL OPEN. It would be kind of ok, IF clicking back again would close the overlay, but it doesn't. It goes to the page I was before clicking hamburger menu or exit site, if that was my first thing I did...
Now I can handle this in 2 ways:
I can close the overlay when clicking on a link inside the menu. When I did that, overlay closes and I get to the next page. Back gets me back to the previous page without overlay. So far so good, BUT... on desktop, when I click and get on a new page this way, I have to click back 2 times to come to previous page. So that is not good.
I can somehow make the back button to close the overlay first and the next back would go back one page, but that seems even more dirty than the first option handling the push states etc.
As I see many sites have solved this. On mobile, clicking on link inside hamburger menu (or some other "popup" with menus) gets to a new page and clicking back goes back to the previous page with hamburger closed. Same behavior is on desktop, no need for double back click.
Does anybody know how I should manage this and if anybody knows why mobile browsers do not close the overlay in the first place when clicking inside it or is there some easy setting that I could trigger this behavior?
Yours
Jerry
This sounds like you just discovered a browser feature called "bfcache". I have experienced similar issues once and it took me hours to figure out whats going on.
The implementation is inconsistent through out browsers (as well as their mobile & desktop versions) and background requests the page made. It requires a certain amount of page optimization if a consistent history back/forward behavior is needed. I'm not 100% sure if that's the problem here as you missing a minimal reproducible example, but you might want to investigate in that direction.
One of the best guides on how to handle back/forward caching is this one from Google Developers.
Back/forward cache (or bfcache) is a browser optimization that enables instant back and forward navigation. It significantly improves the browsing experience for users—especially those with slower networks or devices.
As web developers, it's critical to understand how to optimize your pages for bfcache across all browsers, so your users can reap the benefits.
The "cache" used by bfcache is different from the HTTP cache (which is also useful in speeding up repeat navigations). The bfcache is a snapshot of the entire page in memory (including the JavaScript heap), whereas the HTTP cache contains only the responses for previously made requests.
– web.dev
I have multiple iframes on a page that when they start to play they automatically go fullscreen on mobile. I am using the youtube api to load the videos and have a "cover" image over the top with a custom play button. On mobile, when the user clicks the play button the cover image disappears and the video goes fullscreen and starts playing - so far so good. But what I need to be able to do is that when the user clicks 'done' the video leaves fullscreen (which it does) and the cover image comes back up (which it currently doesn't). The problem is that I cant seem to detect when the user clicks 'done'.
I've tried using:
$('iframe').bind('webkitendfullscreen', function(){
// code in here shows the cover image but even just a standard alert isn't firing.
$('#coverImage').show();
});
No matter what I do the webkitendfullscreen isn't firing. Is there no way to detect when an iframe is done on mobile?
any help/pointers appreciated!
According to the answer from powtac from this SO post:
You can not interact with iframes which are not under the same domain.
This is always prevented by the browser's policy.
I think from this SO post you will have a hint on your problem.
You can check this SO post as well.
I am developing a website that has scrolling transitions on the "index" page and then normal scrolling with a sticky navigation bar on other pages. The site also uses ajax to transition from one page to the next. I have an if statement based on if the user is on the index page use the scrolling transitions, else use normal scrolling with the sticky navigation.
The problem I've found is that in safari when I click on a link from the index page, scroll on the new page and then go back to the index page, the scroll transitions are not activated again. In fact it seems that the scroll events I have set up stop working entirely.
However this problem does not occur in any other browser: Chrome, IE, Edge or Firefox.
I don't know if it's best for me to post the code for it on here because it is a bit long. But here is a link to the code: http://www.dreshaddev.dreamhosters.com/layout/js/scripts.js
Here is a link to the development site: http://www.dreshaddev.dreamhosters.com/layout/index.php
I have tried multiple solutions like reinstating the same code after an ajax call and removing event listeners and re-adding them back in. I'm not sure what to do. I am testing this on Safari 9.1.3.
What's the Problem:
Unfortunately I must use an Iframe in a web solution (tenant scoped SharePoint hosted App with App Parts).
The iframe needs around 50% of the website's space and the space for it in the host will be programmatically blown up in size so that there will be no scrolling bars shown. It works good on every browser except Safari. In Safari the touch event seems to be caught by the iframe window and will not be forwarded to the host window. Imagine this on the iPad: in over 50% of the page the user can't scroll down the page.
Hardware I used for testing:
Windows 8.1 (touch enabled screen) with latest version of Safari (5.1.7)
iPad with iOS version 8.4.1.
What I researched/tried so far:
This has nothing to do with everything that can be solved by "-webkit-overflow-scrolling: touch;" and similar approaches. From what I understood in my research, this will make the iframe scrollable but I need to make the host window scrollable when moving the finger in the iframe area. In other Browsers the iframe for example scrolls down until the end and then starts scrolling the host window
In some post one suggested to overlay the iframe with a div (z-index: 2) and then forward the click events from this overlaying div to the Iframe window ( I do have control on this Iframe window, so I can catch events in there). The overlaying div fixed the scrolling behaviour on my testing page but not in my target application, so it's not a reliable solution. Besides that: I managed the click event to be triggered (with same approach as in 3.) but could not manage to make it click links in my iframe-page (what I need... because this is the reason why I want the clicks to be forwarded.)
Another approach was to forward the touch events from the Iframe page to the host page. I did this via postMessages, JSON-stringified event parameters and a javascript library called "jquery.simulate.js" that is used to simulate touch events. I did not manage to trigger the touchmove event correctly on the parent window (and besides that I doubt that this is really good concerning user experience and performance)
I also thought about getting the simple html from the Iframe and add it to the host page programmatically. Unfortunately SharePoint hosted Apps are hosted on other subdomains, so due to the cross-browser restrictions I think is not worthid to follow.
Another approach was pointer-action: None; - This also breaks the link functionality and unfortunately worked only on the desktop
Setting scrolling="no" (or "yes") did not have any effect nowhere (maybe because it's gone in HTML5)
So here I am stuck... and it seems that no one else in this world has the same problem as I cannot find any really working idea anywhere. But I tested around 20 different websites with iframe - and I tested with the Desktop touch and the iPad.... and I have the same problem. I could not find a single Safari-Touch-working iframe throughout all suggestions and possible solutions.
How to reproduce:
A simple
<iframe src="http://www.w3schools.com"></iframe>
embedded on any html page with long content, Safari and a touch device (similar to the ones I used for testing) should be enough to reproduce.
What I want to know:
Does anyone have the same problem?
Could you put me into the right direction? I am actually unsure which of the above mentioned approaches I should continue to go on with
Do you have a completely new idea that I could follow?
Did you test this on any other device and know it's working? (I am thinking maybe downgrading could be a solution)
Edit: (Solution Nr. 2) The overlaying div makes the page indeed also scrollable in Safari, but I could not find the correct way how to forward the click event to the child successfully (meaning: which of the event parameters are necessary to be forwarded to trigger the click event in the child window?)
Edit: Searching again and found out that you cannot create events like clicking programmatically due to security reasons. Makes sense as this will be a big security issue if you could force the user to click on your ads for example.
How can I click on specific (x,y) coordinates on a web page?
I'm trying to get add a delay of 1000ms before a person leaved the page. I'm using the beforeunload event to start a jquery animation and would like it to finish before the page leaves.
I'm not concerned with older browsers, IE9, latest safari, chrome and FF4 are all i'm interested in.
Edit: Well I was hoping to implement it when just navigating internal pages. Sure I can make all my internal links a javascript call, but I would have preferred a less brute force method.
Also, I'm not stopping people from leaving the page, not even making them wait a huge long time, 1 second for a fade out? Thats no worse than every game I play fading out when I select quit.
Now had I asked how do I prevent a person from leaving a page, then yes all the "don't do it" would have been deserved.
Firstly, if people want to leave your page, don't put any barriers or difficulties in leaving it. Just let them.
Konerak said it well...
Using a blocking action is acceptable when the user is about to lose data by leaving the page, but using them for animations and gimmicks will quickly annoy your users.
Secondly, you can only prevent automatic closing with a blocking action, such as an alert() or prompt(), which temporary blocks the browser's viewport, waiting for user response.
jsFiddle.
Well I was hoping to implement it when just navigating internal pages.
I know it’s four years later now, but I wanted to point out that, within the bounds you’ve described, you can do this.
$(document).on("click", "a", function (e) {// Listen for all link click events on the page (assuming other scripts don’t stop them from bubbling all the way up)
// Stop the link from being followed.
e.preventDefault();
// Grab the link element that was clicked
var linkClicked = e.target;
// I'm using setTimeout to just delay things here, but you would do your animation and then call a function like this when it’s done
window.setTimeout(function () {
// Simulate navigation
window.location = linkClicked.href;
}, 1000);
return false;
});
It’s still inadvisable:
I suspect it would get annoying to users pretty quickly
Without additional code, this would prevent users from command/control-clicking to open links in a new tab.
8 years later and I'm about to code this for my own website, specifically as a fade between pages. But I'm only going to do this for navigating between pages within my site, and I'm not going to use window.onbeforeunload or window.onclick. I attach a click event handler to specific "buttons" on each page. pointer-events is even disabled for other elements, so the event's element scope is very limited. The code is a switch() statement with cases for each "button". Each button navigates to a specific page within the site.
I don't think this is bad web page or web site behavior. A 1 second delay when transitioning between pages is not going to annoy users. I think you might be able to get 2 seconds or more out of it, if you include the time it takes to load the destination page, which can also fade in gradually in as it loads data.
It's visually elegant, especially compared to typical news/info sites with flex layouts that shift all over the page while they load. Those pages spend 2 or more seconds shifting stuff around before you can read anything.
My site is already filled with CSS and SVG animations, so adding this to the internal page navigation is no sweat for this project. If you limit the element scope of the user events and you make the delays small, this is good behavior, not bad behavior, IMO. Visual elegance has value.
EDIT- As I get into it, I see that for one group of similar pages I can achieve better cross-fading between them by consolidating them into one page. That way I can truly cross-fade between each sub-page instead of fading out one page then fading in another.