How to tell whether an existing site is using WebGL? - javascript

I'm trying to work out whether a certain website is using WebGL. I'm comfortable using Chrome's developer tools, but I'm not quite sure what I'm looking for. I see various variables and classes with "webgl" in the name, but no call to initWebGL() for instance.
Is there a reliable, perhaps simpler, way to tell?

First, there should be a <canvas> element in the body. If not, it can't be WebGL.
Second, open the chrome debugger and press Ctrl+Shift+F (Command+Option+F for MacOS). At the very bottom, expand the search pane if necessary. Search for "bindBuffer". You absolutely must bind buffers to do anything with WebGL. It will be used.

Its been awhile since the original question but thought I would share:
If you use the "Profile" tab in Chrome Dev Tools, and record a second or two you should see in the results a row with the name "GPU". If there is a <canvas/> in the DOM, but it's not using WebGL, the GPU row won't be there.
With WebGL
Without WebGL

In Google Chrome Version 97 this worked for me:
Open the "Elements" tab in Chrome DevTools
Select the <canvas> in the DOM which you want to inspect, so it shows == $0 next to it (see screenshot below)
Open the "Console" tab in Chrome DevTools
Enter $0.getContext('2d'), when it shows null then it's a WebGL-powered canvas, when it shows CanvasRenderingContext2D then it's a plain 2D canvas
Here are some sites to try:
WebGL Canvas - https://get.webgl.org/
Non-WebGL Canvas - http://www.professorcloud.com/mainsite/canvas-nebula.htm
Screenshot:

Related

How to add an animated GIF in Desktop Notification using Notification API in JavaScript

I am creating a web app with a timer. Let's say every 30 seconds, it will fire a Desktop Notification using Notification API. I can do this smoothly, and also design it with images. But my problem is I want to add an animated GIF as Image on my notification. But when I add the image link, it only appears as a fixed (not moving or animating) image.
var notification = new Notification("Any Text will do",{
icon: 'some-icon.jpg',
body: 'Hello!',
image: 'some-animated-pic.gif'
});
Thanks in advance and happy coding! ^_^
Short answer: Unfortunately, animated images are not currently usable with the Notifications API, and are usually converted to a single frame grab, except for on IOS 10+. Sorry.
Longer answer, and evidence used to back up answer:
Likely because it is relatively new, the documentation and specifications for the Notifications API is rather weak. For example, this is basically all that the WHATWG standard (Note: W3C standard is not up to date with WHATWG) says about image resources:
An image resource is a picture shown as part of the content of the notification, and should be displayed with higher visual priority than the icon resource and badge resource, though it may be displayed in fewer circumstances.
Furthermore, at the moment, the image attribute is not even supported on many modern browser, including Firefox. MDN compatibility table.
The documentation for how each browser vendor (e.g. Chrome vs Firefox) implements this standard is even worse, likely because it is still labeled "experimental" and so nothing is really set in stone yet. For example, although Firefox does not accept use the image property yet, it will accept and show the full animation of a GIF passed as the icon property.
By manually testing in Chrome (tool), I was able to get the same results as what you stated; that it will accept an animated GIF as the image property, but only show a single frame from it. I can't find a single Chrome documentation that speaks to this being true, or why it is so. However, poking around in the actual Chromium source code, I was able to find clear evidence that they are currently passing around Bitmaps and forcing single frames as output for images used with notifications.
IOS is the only exclusion here, as they introduced "Rich Media Push Notifications" with IOS 10, which supports animated GIFs, among other features. Apple Docs, article about announcement.
Further links that back up my assertions here:
WonderPush (notes only iOS 10+ supports animating GIFs)
OneSignal
Big Picture on Android (warns GIF will be frozen on first frame)
Web Push Notifications - Images (states Chrome does not support animations)

Best ways to test a responsive website

I've been tasked with creating a website (using mainly javascript & JQuery) that reads in a certain element from a website - e.g. the navigation bar - and test it to see how it react at different screen sizes.
My question is that is this a good approach? To test elements one at a time instead of just testing the responsiveness of the whole page? Wouldn't an element react differently to media query changes with other elements around it, rather than the element by itself?
My vote will be to firefox default responsive tester. Use Ctrl+Shift+M to make the firefox screen responsive.
If you want to see the dimensions with name, go with google chrome, right-click, inspect element. There you will see a mobile icon. Click that.This will give you a dropdown of variety of devices.
Usually the good approach is to test the whole page. But clearly there are cases when element testing is necessary, even disabling certain ones and check the rest together. So the tool you're about to create actually makes sense; not good enough, tho. But maybe you're better off with a Google Chrome element inspector and some "display:none"-s.
(Side note: this is my own responsivity tester and I never needed much more than this. It aims for the typical bootstrap breakpoints; it has maybe twelve lines of code, it's just as complex as a screwdriver.)
If you want to try it on native devices you should check out www.browserstack.com
There is an extensions for your browser so that you can run local sites (localhost), on the emulated device.
30 min trial is free which is usually enough for a few tests.

automate move mouse in javascript

I'm interested in a reliable way to move the mouse across html, canvas or iframe elements to a given set of coordinates. The browser (chrome and firefox) will be run under a testing driver with the web security options disabled, so doing $('iframe').contents().find() will not result in an cross-site security error.
selenium has something that seems to work quite good, which is move_by_offset. I'm working with that API, but it would make my life so much easier if there was a javascript code that could produce the same end result.
I've search for js code snippets, but most examples I've seen only move to given elements (in the case of firefox, to the center of the element bounding box)

How to select a node in a range with webkit browsers?

I'm currently working on a WYSIWYG solution and need a function to correctly select with a range a node (by this I mean the node itself, not only it's content)
DOM lvl2 clearly have a function for this w3.org/ranges and define that
range.selectNodeContents() // Select the contents within a node
and
range.selectNode() //Select a node and its contents
The problem is that when selectNode() perfectly work with Firefox or even ie9, it seem to be impossible to achieve with any Webkit browser (at last Chrome and Safari). On Webkit both selectNodeContents() and selectNode() select the node content only (which according to the specs seems to me to be a bug)
To make it work I tried to emulate the selectNode() goal by using
range.setStartBefore(node);
range.setEndAfter(node);
but the result is still the same, it work everywhere (ie>8 of course) but not on webkit browsers..
If you want to try it I made a little jsfiddle with which you can play here (just open the console and look at the console.warn result which is not the same on webkit :/ )
I searched a lot but I can't find a way to actually select a full node on webkit browsers.
By miracle would some of you know a way to do it or even just any tip to continue my quest ? :/
ps : I know "rangy" lib but I can't use it in my project and ,from what I read in the source, I'm not even sure they deal with that thing anyway :/
The problem is not with selectNode(), which works fine in WebKit, but with WebKit's selection object, which mangles ranges to fit in with its own (not always unreasonable) idea of where selection boundaries and caret positions are allowed to be. There are bugs filed against this with WebKit:
https://bugs.webkit.org/show_bug.cgi?id=23189
https://bugs.webkit.org/show_bug.cgi?id=15256
You're right, Rangy does not deal with this, preferring instead to reflect the reality of the browser's native selection. Pretending the selection is different would quickly lead to odd behaviour.

Chrome and SVG (Raphael), trouble with drawing "off-screen"

I'm working on a prototype system which will act as a proof of concept that an existing system can be made a lot more interactive.
It basically emulates our main software package but over the internet using JSONP requests to update a load of images and Raphael vectors to make it look like everything's running.
I'm having trouble on Chrome however with Raphael not drawing vectors "off-screen". What I mean by "off-screen" is that the main app runs through an iframe as it relies on cross-domain long poll comet through AJAX to get communicate back and forth. Below is an image demonstrating what I mean.
Here I've scrolled a long a little bit in the iframe to look at the bits "offscreen" and you can hopefully see that the grey arrows aren't rendered. I've used Chrome's developer tools to highlight over the SVN tag, showing that it's only given 450px by 810px to the SVG tag, which is the same size allocated for the iframe.
It's worth pointing out that it renders fine in Firefox. Any ideas?
I've had a similar problem and found a bug report for the WebKit project that seemed related:
https://bugs.webkit.org/show_bug.cgi?id=64823
According to the comments, it's a bug in the rendering engine and there's no workaround aside from losing the iframe or resorting to other means of scrolling the SVG viewport (like moving all the elements within the SVG element).
On the upside, version 16.0.912.21 has been released to the beta channel today and it seems that the bug has been fixed. I've also checked the latest chromium build (17.something) and the bug hasn't resurfaced. I'm guessing the fix should find its way into the stable channel in a couple of weeks.

Categories

Resources