Is there any reason to use AudioBufferSourceNode.start(...) over AudioBufferSourceNode.noteOn(...)?
Yes. start() will work in Mozilla's nascent Web Audio implementation, and will work in Safari in the future. noteOn() won't.
As of today NoteOn does not work in Google Chrome, so you must use start(). (2014-07-24)
(This should be a comment but I don't have the rep.)
My company's developers confirmed that noteOn() began to fail in browsers that use recent versions of WebKit, but that to start() is a reliable alternate. Sorry, I don't know the specific version of WebKit, but affected browsers include:
All native browsers for iOS 10.3 (and above). This is due to Apple's requirement to use WebKit on that platform, including Safari, Chrome, Firefox, and Opera. As an example of a non-native "browser", Puffin is really a remote-access portal to a LINUX window, so it is unaffected. (Apple recently pulled Puffin Academy from the store, but it may be a misunderstanding of the method used, or may be a tightening of their requirements.)
Safari 10.1 (and above) for Mac OS X 10.10 through macOS 10.12 (and above).
Related
Currently I'm using jQuery 1.8.1. I'm going to upgrade to 3.0 for security reasons. When I see the Browser support section, it's saying:
Chrome, Edge, Firefox, Safari: Current and Current - 1
But I'm not sure what it means.
ex. Google chrome : 65.0.3325.181 jquery 3.0 compatible to 64.0.x but not previous versions?
current means the time when jQuery 3.0 released?
Basically, means that they guarantee compatibility for the Current and the Current - 1 versions of browsers, not of jQuery.
This does not imply that jQuery won't work on previous versions of all browsers, just that every bug or problem in previous browsers version won't be fixed, unless it happens also in current browsers version.
Actually, most of jQuery code works flawlessly in older browsers.
It's worth pointing that nowadays every browser in every platform (Windows, Mac, Linux, Android...) comes with automatic updates, so old browsers are increasingly uncommon.
I am trying to build a simple AngularJS application using an old Chrome (version 2010).
Then I am facing various problems with routing. Basically Chrome becomes unstable, even crashes often.
I suspect that my old Chrome is not compatible with the specific AngularJS I am using (v1.3.8).
Where can I find such information? I mean the version of Chrome needed by AugularJS of specific version?
I searched AngularJS document, but didn't get a clue.
Edited:
Quoted from link https://code.angularjs.org/1.3.8/docs/misc/faq:
We run our extensive test suite against the following browsers: Safari, Chrome, Firefox, Opera 15, IE9 and mobile browsers (Android, Chrome Mobile, iOS Safari). See Internet Explorer Compatibility for more details in supporting legacy IE browsers.
I think these details above are a little vague as a reference. I understand the recommended practice is upgrading Chrome to the latest. As "Derek 朕會功夫" commented, my environment is restricted to some extent. One of the restrictions is, it is not feasible to upgrade Chrome.
That is why I want to find out the exact Chrome version supported by AngularJS. People may come up with similar concerns with other browsers like Firefox. Right?
thanks!
Answer To PSL: I am not using bangrang.
BTW, "add a comment" link doesn't work for me , so I have to comment here :(
As far as I can tell, you require Chrome 13 (MDN) from 2011 in order to support the functions tested in the Angular source found here, such as File and Blob.
I'm using the digitalbazaar/forge JS library, but I cannot find anywhere what the browser support is. Does anybody know?
After some digging we found that forge uses window.JSON and Object.create and other more ECMAScript 5 stuff. This means that out of-the-box the lib doesn't work in IE7 and below.
We included two shims: ES5-shim and Json3 and with those in place the code ran without any issues.
I'm not sure of the comments of #bruno (see above) are valid or not for our use case (we're not using TLS itself, but other encryption stuff that is also in the lib), but with respect from it just running this seems to work on all browsers we tested it in (IE6 and up, chrome, firefox, mobile safari, mobile android and opera mini).
What will be worse in the older browsers is the entropy of the PRNG's seed because they do not have a strong native entropy source, which makes the encryption a lot less secure in those browsers.
I made an addon for Firefox and it works with the latest version. My problem is that I want it to work with all versions of Firefox. How can I do this?
Info:
I used the Add-on SDK to make the extension.
I use jQuery too in my extension, could it come form here?
Add-on SDK 1.14 (the current release) marks add-ons compatible with Firefox 19 and disallows installation in older Firefox versions. If you don't like that you have several options:
Edit app-extension/install.rdf in your Add-on SDK install and set minVersion to something other than Firefox 19. If your extension is simple you might even get away with that and your extension will actually work in older Firefox versions, maybe even in Firefox 4 (definitely not below that however, restartless extensions were introduced in Firefox 4). This is obviously not supported and verifying that everything really works correctly (e.g. no memory leaks) will be close to impossible.
You can get an old version of the Add-on SDK. You will not get any of the improvements in the newer Add-on SDK versions but you get support for old Firefox versions. You will still need an Add-on SDK version that's compatible to at least Firefox 10 however, otherwise your add-ons won't install in current Firefox versions (Firefox 10 is where the "compatible by default" switch was flipped). Also, regardless of compatibility flags - while your extension might work correctly in current Firefox versions, it's just as likely that it won't.
You can drop the Add-on SDK and just create a classic extension. Then you can set the compatibility boundaries to anything you like. Taking care of backwards compatibility will also be your responsibility however - and depending on what range of Firefox versions you want to support this is a very non-trivial task.
The main question is however: why do you want that? The current Extended Support Release is Firefox 18, so no version below Firefox 18 is supported by Mozilla. There are of course a few users on outdated Firefox versions for some reason but people who don't update also rarely go install new extensions. So, do you really want to spend tons of time making your extension work in Firefox 1.0 (release 2004)? How about Firefox 4 (released 2011)? How much effort do you want to invest into staying compatible with old versions when there are tons of addon-relevant changes in each single release?
You should read the addon compatibility page on the sdk documentation.
https://addons.mozilla.org/en-US/developers/docs/sdk/1.14/dev-guide/guides/firefox-compatibility.html
Did you simply try to change the minVersion field in your install.rdf file?
It is very slow to access this page using IE, but much faster using Firefox. Especially when I increase the number of nodes of people. Any ideas what is wrong?
http://thejit.org/static/v20/Jit/Examples/RGraph/example1.html
BTW: IE is even slow when accessing from local file system.
thanks in advance,
George
Internet Explorer's Javascript engine is slower than that from other web browsers, at least when using IE with versions lower than 9. So, if you're using IE 6, 7 or 8, now you know why.
Like raynjamin said, try testing IE using Sunspider.
The latest stable Firefox (3.6) is fast, but for example, Google Chrome is even faster. A browser's Javascript speed depends on its underlying implementation.
Update: to give you an idea of how "fast" IE is compared to other browsers, I've done a benchmark on my own computer using Sunspider 0.9.1. Here are the results:
- Internet Explorer 8: 5039.8ms
- Firefox 3.6: 967.9ms (loaded with extensions)
- Chrome 9: 276.3ms
- Opera 10.6: 293.2ms
- Safari 5: 397.0ms
As you can see, IE 8 is about 5 times slower than Firefox 3.6 and almost 20 times slower than Chrome 9, at least when using Sunspider tests. That is a drastic difference and you can see that IE 8 isn't all that fast.
Update 2: There is one way to make IE faster. A plugin called Chrome frame exists. Using this plugin will make IE faster since it will use Chrome's engine. I haven't tried it personally, but I've heard good things about it.
IE is slow. Fact.
Javascript runs much slower in IE than in other modern browsers. You can test it for yourself using a javascript benchmark like sunspider.
Guys Got the Culprit here... :) :)
After doing lot of RnD on Server side and Client side, I took a look at "Developer Tool" in IE. You can find something like "Document Mode: Quirks". If you check the Wiki page for this Quirks mode, You can find a definition as "In computing, quirks mode refers to a technique used by some web browsers for the sake of maintaining backward compatibility with web pages designed for older browsers, instead of strictly complying with W3C and IETF standards in standards mode."
So this all becuase of checking for compatibility for all components on page. And hence the performance issue. :)
And When I changed this mode to IE 8 Standard. Things started working really well.
IE and its issues ...!!!! :D