I'm pretty new to JavaScript programming when it comes to UI automation and have come from a Java based Selenium background. I'm currently trying to get my head around InternJS and how to use it to take full page screenshots of any URL that I wish and on any device. The end goal is to take screenshots of a specific website on multiple devices for manual visual verification purposes and using a Sauce Labs account.
I was able to separate the takeScreenshot() functionality into a re-usable method as follows:
MyFile.prototype.takeScreenshotAndWriteToFile = function (fileName) {
return function () {
return this.parent
.takeScreenshot()
.then(function (fileAsBuffer) {
fileSystem.writeFile(fileName, fileAsBuffer, 'base64');
})
.catch(function (error) {
console.log(error);
});
};
};
However when I run this on various devices / browsers via our Sauce Labs account, I am getting the following results:
Desktop with Chrome and Firefox (latest versions on Windows 10) only takes a screenshot of what's immediately visible in the browser window at the time I make the request.
The same result as above applies to testing on Mobile devices and Tablets.
Oddly, Safari Version 11 (on Mac) does take a full page screenshot. Same method. Same implementation. Different result.
I'm completely confused as to why something so simple as wishing to take a full page screenshot is proving to be such a complicated issue... could anyone please point me in the right direction as to what I can do to achieve my goal?
Or if anyone knows of a better alternative to Intern JS in this case? I'm open to any ideas / advice at this stage.
As Florent pointed out, screenshots are actually handled by the driver that's interfacing with the browser (e.g. chromedriver) rather than Intern, which is interfacing with the driver. According to the WebDriver spec, a screenshot will only be of the viewport, not the full page. The JSON wire protocol (the precursor to WebDriver) is a bit vaguer on the subject. In any case, different browser drivers can and do behave differently in many situations.
Any testing system that uses WebDriver/Selenium to manage browsers (which is most of them, particularly the popular open source ones) is going to be subject to the capabilities of the driver, and may not support this feature out-of-the-box. However, it could probably be implemented in the testing system (higher level than the WebDriver), so it would be worth filing a feature request with Intern (or whichever WebDriver-based testing system you might be using) if it seems worthwhile.
Related
Short version:
Is it possible to detect that someone added code to run inside a page from the browser inspector?
Long version:
Stock broker companies give their users the real time value of stocks, other free tools give you a delayed version of such values, for example 15 minutes old information.
There are other types of financial companies that have real time API to give you access to stock market at a cost.
What some people do is to keep their browsers open in the broker site and inject some JS code to observe the changes and post them elsewhere using XHR or web sockets. Not only network calls but also notification API and the draft Serial API can be exploited to put data out of the site.
This usually can't be done automatically due to the secure nature of logins requiring captcha or other methods. But once logged in and injected the hack will work until the tab is closed.
Usually this is not done by injecting script tags with outer files source, just pasting the whole code inside inspector and running it.
Now back to the question: Can a site know that code rogue code is running in their site?
I thought of some methods like a HASH of every variable used and if anything new is created it reloads the page or warn the user. But I'm not sure it is possible in nowadays JS, I guess document.all could help.
So yes, kinda, and also no kinda... there isn't a great cross browser solution to this as their implementation of the debug tools are all slightly different. This solution is probably the best I've found so far.
I tried to take a screenshot of a movie on the Disney+ web app when I realised that the video turns black as soon as I try to take a new screenshot with Snipping Tool. When I tried to do the same thing with OBS and Discord streams, I saw the same effect.
Interestingly, this only works for Chrome on my machine (I also tried Firefox and Edge and they just let me record my screen).
When I saw this, I became really curious on how they achieved this.
Does anyone have any idea how I can recreate this for my own web projects?
I became really curious on how they achieved this.
They use Widevine.
Widevine homepage.
https://ottverse.com/widevine-drm-how-does-it-work/
https://en.wikipedia.org/wiki/Widevine
News reports:
https://www.cordcuttersnews.com/sadly-disney-wont-work-on-chromebooks-linux-some-android-devices-because-of-drm/
https://www.tomsguide.com/news/disney-plus-will-work-on-chromebooks
https://www.androidpolice.com/2019/10/22/disney-will-only-work-on-devices-that-support-the-strictest-widevine-l3-drm/
It's also used by Netflix, Hulu and others.
Widevine is Google's DRM system that's baked-in to Chrome.
All other major browsers have adopted it as well, because no-one will use a browser that can't access Netflix.
Mozilla's and Microsoft's support is less user-hostile and as you noticed.
It's just a standard HTML5 <video> element - when the browser downloads the video stream it will see that it's encrypted with Widevine and that engages the Widevine client-side code which does all the DRM biz.
Though there are HTML and DOM features that facilitate DRM, I'm unsure of the extent that any JavaScript is required to use it - as theoretically everything the browser needs to know to load the DRM system should be embedded in the raw media stream.
On Windows, I understand (though unconfirmed) that Widevine makes use of SetWindowDisplayAffinity to block screenshots.
Nothing stops you from doing this in your own native code (e.g. if you had an Electron fork), but please don't because it's a real dick-move to your users, in addition to not working at all if the user has the DWM disabled (e.g. they're running Windows 7 with Aero disabled).
Has anyone any idea how I can recreate this for my own web projects?
You'll need to license Widevine yourself. This is a complicated process intended only for large media production companies and content rightsholders, not individuals or small businesses.
Anyway, even if you could, please don't. Why would you want to make to harder for users to share and appreciate your media? Just stick it up on YouTube instead.
My problem is:
I have being developing a Python script that connects to an URL, and using the selenium driver I manage to inject a Javascript file, after this file executes the currently page is redirected. This's all done using selenium to handle Firefox:
driver = webdriver.Firefox();
, but when I try to use PhantomJS as the browser, since it doesn't have any graphical interface:
driver = webdriver.PhantomJS();
I can't handle the response properly. Still haven't found out if the driver is not injecting the script correctly or if it's an response handling problem. If someone has any ideas it'll be great to hear.
I posted this on another question, but I think this will help:
After dealing with this same dilemma myself, I can wholeheartedly recommend using your preferred Selenium webkit (mine is Chrome) in conjunction with XVFB.
XVFB allows you to heedlessly run a browser like Firefox, Chrome, etc. which basically eradicates all of the bugginess that inherently comes with using PhantomJS. While it’s definitely an awesome piece, it’s inner workings tend to have different interactions at times (I ran into issues for instance with not being able to TAB from one element to another like one can in any browser). If you are using Jenkins, there is an incredibly awesome Plugin which literally takes one click of a button. Otherwise, I’d definitely recommend checking this out.
Phantom is a real pain in the ass, so it's definitely worth circumventing it :)
Hope this helps!
I have an ASP.NET MVC application that makes pretty heavy use of javascript and JQuery for both administrative functions as well as customer-facing functions. Recently I reorganized the administrative screens to be able to more cleanly fit administrative controls for some new features.
I tested using IE and Chrome and found that there was a slight, but acceptable hang in one of the busier pages. However, the main person who uses the admin pages uses Firefox and kept reporting an unacceptable hang. I finally checked it out and found that what hangs in Chrome and IE for 2-3 seconds hangs in Firefox for 10-12 seconds, which is no good.
Not knowing where to turn, I wound up installing Glimpse and got it configured and running just fine, but I'm still having trouble figuring out how to drill into it to find out what area of the page is causing trouble. All I can tell so far is that it is definitely something with how the client (Firefox) is rendering. To be clear, it happens on all browsers, but for some reason it is way more pronounced in Firefox.
Can someone please give me some pointers on how to get started on diagnosing the issue? I'm not married to the idea of using Glimpse, but it seems like a pretty decent tool from what I can tell.
Thanks for your help.
Based on what you're describing, the problem appears to be client side. With that said, Glimpse may not be as well-suited as using Firefox's own profiler.
SHIFT+F5 will bring up the web developer performance screen. From there, you can begin/end a performance analysis and gain more insight into what may be taking longer than expected.
It may also be worthwhile to look at the network tab and make sure assets are loading in a timely manner.
Keep in mind as well that add-ins could play into the latency. If the end-user has a setup that performs post-page processing (such as Greasemonkey scripts or (recalling an earlier add-in) a Skype plugin that used to transform phone numbers on the page to direct-dial links), that would also play a part in the performance. A good way to rule these out is to hold down SHIFT while starting up Firefox (effectively running it in Safe Mode), which would determine if it's Firefox itself or an add-in that's to blame.
The Problem
I'm working on a web application where users can sequence audio samples and optionally apply effects to the musical patterns they create using the Web Audio API. The patterns are stored as JSON data, and I'd like to do some analysis of the rendered audio of each pattern server-side. This leaves me with two options, as far as I can see:
Run my own rendering code server-side, trying to make it as faithful as possible to the in-browser rendering. Maybe I could even pull out the Web Audio code from the Chromium project and modify that, but this seems like potentially a lot of work.
Do the rendering client-side, hopefully faster-than-realtime, and then send the rendered audio to the server. This is ideal (and DRY), because there's only one engine being used for pattern rendering.
The Possible Solution
This question lead me to this code sample in the Chromium repository, which seems to indicate that offline processing is a possibility. The trick seems to be constructing a webkitAudioContext with some arguments (usually, a zero-argument constructor is used). The following are my guesses at what the parameters mean:
new webkitAudioContext(2, // channels
10 * 44100, // length in samples
44100); // sample rate
I adapted the sample slightly, and tested it in Chrome 23.0.1271.91 on Windows, Mac, and Linux. Here's the live example, and the results (open up the Dev Tools Javascript Console to see what's happening):
Mac - It Works!!
Windows - FAIL - SYNTAX_ERR: DOM Exception 12
Linux - FAIL - SYNTAX_ERR: DOM Exception 12
The webkitAudioContext constructor I described above causes the exception on Windows and Linux.
My Question
Offline rendering would be perfect for what I'm trying to do, but I can't find documentation anywhere, and support is less-than-ideal. Does anyone have more information about this? Should I be expecting support for this in Windows and/or Linux soon, or should I be expecting support to disappear soon on Mac?
I did some research on this a few months back, and there is a startRendering function on the audioContext, but I was told by Google people that the implementation was, at that time, due to change. I don't think this has happened yet, and it's still not a part of the official documentation, so I'd be careful building an app that depends on it.
The current implementation doesn't render any faster than realtime either (maybe slightly in very light applications), and sometimes even slower than realtime.
Your best bet is hitting the trenches and implement Web Audio server-side if you need non-realtime rendering. If you could live with realtime rendering there's a project at https://github.com/mattdiamond/Recorderjs which might be of interest.
Please note that I'm not a googler myself, and what I was told was not a promise in any way.