We have a kiosk system (running on ubuntu) which used chromium 65 until now.
We want to update to the newest version (90), but as soon we update the autoplay don't work as before.
I could figure out that the autoplay behavior has changed (https://developers.google.com/web/updates/2017/09/autoplay-policy-changes). I searched for a way to reenable the autoplay (with sound!), i found the parameter "--autoplay-policy=no-user-gesture-required" which should reenable the autoplay.
Unfortunaly this is not the case, i still have to start the video myself. We also have (sometimes) a few weired behaviors, sometimes the sound is played but the video not. Sometimes i cant even start the Video.
Currently installed:
chromium-browser 90.0.4430.93-0ubuntu0.18.04.1
chromium-codecs-ffmpeg-extra 90.0.4430.93-0ubuntu0.18.04.1
For testing purposes i used the following simple html (i also tried it without the source tag).
<video autoplay>
<source type="video/mp4" src="preview.mp4" >
</video>
I hope somebody can help with that and maybe have a explanation.
To my experience somewhere between version 70 and 80 the --autoplay-policy=no-user-gesture-required parameter stopped working.
Whether autoplay is allowed is now determined by magic.
It is said you need to (manually) play at least 7 seconds of video (with audio) After doing that about 20 times Googles Media Engagement Index database will have learned you want to allow autoplay for that site.
But mind you, playing videos shorter might get your site disqualified again.
This is very annoying as aborting videos too soon, like you do during development, gets you further away from autoplay.
You can see your current stats in chrome://media-engagement
But these stats are unreliable. I have projects on origins which qualify, but still refuse to autoplay and project which do not qualify, but do autoplay.
A guest session is said to start with a fresh index, but I have never seen this make a difference.
Google has exempted its own youtube.com from this indexing. Youtube can always autoplay. Maybe you can find a way to get your own domains in that list too.
You can build a check to see whether the autoplay was prevented using a promise which is rejected with a message explaining you autoplay was rejected because the user didn't interact with the page first. There are other reasons too, so do check the error message.
Related
I have a question regarding executeJs function.
page.executeJs("$0.click();", downloadAnchor.getElement());
This line of code is not working in real iPhone Safari browser, though it works in mobile responsive mode from desktop safari. Appreciate your help on this
Browsers will be "suspicious" of anything starting a download that isn't a direct reaction to interaction by the user. This is done as a security precaution since starting to download files without the user's explicit consent can be dangerous in specific cases. Different browsers and configurations have different policies for exactly where to draw the line.
In your case, the download isn't started as a direct consequence of user interaction but instead as direct consequence of receiving a message from the server. This kind of pattern will simply not work reliably no matter what you do.
Instead, you need to design the interaction so that the download is directly triggered by the user. The easiest way of doing that is by having the user directly click on the actual download link. If you want to have some indirection, then you still need to make the action work directly in the browser without going through the server.
We're currently using the MediaElement.js HTML5 video player for site viewing on tablets and are using DFP to serve pre-rolls via VAST. The main parts of this works fine (playback, tracking of views and clicks), but we are encountering an issue where pre-rolls will not serve at all when frequency capping (i.e., max once per 5 minutes for each line item) is enabled for them in DFP. This does not appear to be specific to playback in tablet browsers (e.g., based on default cookie security settings), as testing in desktop browsers returns the same results. Has anyone else experienced a similar issue, and if so, what was done to resolve it? Thanks.
We were able to solve this by not pulling the DFP XML file directly, but by using the Google IMA HTML5 library to do so. As soon as we did this, frequency capping no longer became an issue.
I've been on the search for html5 video players for well into 3 months trying virtually everything...
Right now my best choice is SublimeVideo as it seems to work the best, my only gripe is that when playing videos from my website over 3g/LTE data connections the videos will sometimes have trouble playing. The first 3 to 4 videos will run fine but after that it's hit and miss where 50 percent of the videos will give a connection error or not play at all..
I really have no idea as over wifi or via pc - it will work flawlessly.
I've tried jwplayer - wifi, 3g and desktop videos seem to load 75 percent of the time and freeze the rest.
I've tried flowplayer but that also is inconsistent and takes a long time to load videos in general. The three spinning circles for about 10 to 15 seconds before the video starts.
I've verified my server and everything seems fine on that end which is why it seems to work well via wifi and desktop? I'm guessing maybe there is an issue with concurrent connections over 3g? As it seems sublime does not close the video connection when it finishes it kind of leaves it where it left off..
any help would be GREATLY appreciated.
If someone has a slow connection, you need to offer those users low quality streams. The JW Player offers dynamic (adaptive) bitrate switching for this exact purpose.
Try Video.js it worked well for me
I want to record and play the video. I have found the below article to capture the same. but the recorded video is playing so fast and not playing all of the actions. after 32 seconds, it gets reset to starting position.
http://html5-demos.appspot.com/static/getusermedia/record-user-webm.html
I have used the code from (http://www.html5rocks.com/en/tutorials/getusermedia/intro/#toc-history). I can share it if required.
Any clues to resolve this?
Thanks
Off the top of my head, a reason why the video plays back too fast may be the fact that you are using a resolution that is to high for the current API to handle when recording.
I've tested similar attempts to record video directly in browser and had the same issue with playbacks of recording made with high resolutions.
Maybe this link could help
https://www.webrtc-experiment.com/RecordRTC/
or for an extensive overview of the current state of webRTC you can read the following article:
http://hdfvr.com/html5-video-recording
Is there any way to consistently detect PhantomJS/CasperJS? I've been dealing with a spat of malicious spambots built with it and have been able to mostly block them based on certain behaviours, but I'm curious if there's a rock-solid way to know if CasperJS is in use, as dealing with constant adaptations gets slightly annoying.
I don't believe in using Captchas. They are a negative user experience and ReCaptcha has never worked to block spam on my MediaWiki installations. As our site has no user registrations (anonymous discussion board), we'd need to have a Captcha entry for every post. We get several thousand legitimate posts a day and a Captcha would see that number divebomb.
I very much share your take on CAPTCHA. I'll list what I have been able to detect so far, for my own detection script, with similar goals. It's only partial, as they are many more headless browsers.
Fairly safe to use exposed window properties to detect/assume those particular headless browser:
window._phantom (or window.callPhantom) //phantomjs
window.__phantomas //PhantomJS-based web perf metrics + monitoring tool
window.Buffer //nodejs
window.emit //couchjs
window.spawn //rhino
The above is gathered from jslint doc and testing with phantom js.
Browser automation drivers (used by BrowserStack or other web capture services for snapshot):
window.webdriver //selenium
window.domAutomation (or window.domAutomationController) //chromium based automation driver
The properties are not always exposed and I am looking into other more robust ways to detect such bots, which I'll probably release as full blown script when done. But that mainly answers your question.
Here is another fairly sound method to detect JS capable headless browsers more broadly:
if (window.outerWidth === 0 && window.outerHeight === 0){ //headless browser }
This should work well because the properties are 0 by default even if a virtual viewport size is set by headless browsers, and by default it can't report a size of a browser window that doesn't exist. In particular, Phantom JS doesn't support outerWith or outerHeight.
ADDENDUM: There is however a Chrome/Blink bug with outer/innerDimensions. Chromium does not report those dimensions when a page loads in a hidden tab, such as when restored from previous session. Safari doesn't seem to have that issue..
Update: Turns out iOS Safari 8+ has a bug with outerWidth & outerHeight at 0, and a Sailfish webview can too. So while it's a signal, it can't be used alone without being mindful of these bugs. Hence, warning: Please don't use this raw snippet unless you really know what you are doing.
PS: If you know of other headless browser properties not listed here, please share in comments.
There is no rock-solid way: PhantomJS, and Selenium, are just software being used to control browser software, instead of a user controlling it.
With PhantomJS 1.x, in particular, I believe there is some JavaScript you can use to crash the browser that exploits a bug in the version of WebKit being used (it is equivalent to Chrome 13, so very few genuine users should be affected). (I remember this being mentioned on the Phantom mailing list a few months back, but I don't know if the exact JS to use was described.) More generally you could use a combination of user-agent matching up with feature detection. E.g. if a browser claims to be "Chrome 23" but does not have a feature that Chrome 23 has (and that Chrome 13 did not have), then get suspicious.
As a user, I hate CAPTCHAs too. But they are quite effective in that they increase the cost for the spammer: he has to write more software or hire humans to read them. (That is why I think easy CAPTCHAs are good enough: the ones that annoy users are those where you have no idea what it says and have to keep pressing reload to get something you recognize.)
One approach (which I believe Google uses) is to show the CAPTCHA conditionally. E.g. users who are logged-in never get shown it. Users who have already done one post this session are not shown it again. Users from IP addresses in a whitelist (which could be built from previous legitimate posts) are not shown them. Or conversely just show them to users from a blacklist of IP ranges.
I know none of those approaches are perfect, sorry.
You could detect phantom on the client-side by checking window.callPhantom property. The minimal script is on the client side is:
var isPhantom = !!window.callPhantom;
Here is a gist with proof of concept that this works.
A spammer could try to delete this property with page.evaluate and then it depends on who is faster. After you tried the detection you do a reload with the post form and a CAPTCHA or not depending on your detection result.
The problem is that you incur a redirect that might annoy your users. This will be necessary with every detection technique on the client. Which can be subverted and changed with onResourceRequested.
Generally, I don't think that this is possible, because you can only detect on the client and send the result to the server. Adding the CAPTCHA combined with the detection step with only one page load does not really add anything as it could be removed just as easily with phantomjs/casperjs. Defense based on user agent also doesn't make sense since it can be easily changed in phantomjs/casperjs.