I have been debating whether using polymer in my chrome extension is worth while.
Here is the scoop. (or should I say scope, haha bad programmer jokes)
My extension relies heavily on web components which have been available natively in chrome since the release of chrome 36
Now, if the browser statistics listed here are correct, then logically, there isn't much of a reason to polyfill web components since only a small percentage of chrome users use versions earlier than 36 (and lets face it, chances are they aren't using extensions).
What do you guys think? Are there any other reasons using polymer in this case which I fail to see?
Related
I had used js-ctypes on Firefox OS app long ago but I dont seem to be able to do it now. I can't even use Components, has js-ctypes been disallowed form FxOS apps?
The Components object you're referring to is only available to Firefox Add-ons or Gecko/XUL. Apps on Firefox OS are 100% HTML5, CSS3, and ECMAScript5. The only additional APIs are lower level hardware access that we're working to standardize.
If you're looking to work with C or C++ code in the browser, the preferred way is to use Emscripten to cross compile it to JS. Emscripten does have its limitation, and it depends on what you're trying to do.
If you're simply trying to work with data backed by a Typed Array, in the future we will have Typed Objects in ES7, which more usable than the current story.
I want to detect whether a browser supports the Ember.js library. If not, I will show users a message to let them download the latest version of their browser. How can I do that?
There is an answer to a similar question contributed by an Ember.js core team member.
In it, he states that the majority of the browsers on browserstack.com are supported, meaning they do thorough testing.
Rather than show the message based on a functionality test of the user's browser each time they load your application, I suggest you instead build a list of known incompatible browsers (anything older than what is on BrowserStack would be a good start) and expand it based on monitoring your access logs or reported issues from the likely minority users on unsupported browsers.
That "blacklist" approach would serve most efficient, as Ember.Js and other libraries like jQuery are usually designed to continually support all new browsers.
I've found this nice article about the "injected Way", but the author never finished it :
http://hightechstartups.blogspot.ch/2012/05/different-way-of-developing-browser.html
I would like a bare bone cross browser extension, without any 3rd party extensions or framework (to be as light as possible and not dependant on a 3rd party) that would load Jquery and a JS from a distant server and the ability to load it before or after the page is fully loaded.
I've read a lot of topics about the subject, but since IE10, Chrome 26 and FF20 are out with their new cross-link limitations, i was wondering if somebody had ressources, source code or tutorial about the following requirements :
I need :
Cross browser extension supporting (IE 8+ or 9+ worse case, Chrome
26+, FF20+, Safari)
Ability to inject a single JS hosted on another server. Inserts a script tag that references a javascript file in the head of the HTML
page and then be executed
Not be dependant on a third party extension (greasmonkey) or framework (Kango, Crossrider)
Ability to load before or after the page is fully loaded
This method allows me to customise the browser extension depending on the user's location and it also avoid having updates as the JS is updated on each page refresh.
I'm aware of the downsides, but i would like to achieve this.
I'm aware of cross browser framework like Kango or crossrider, but both don't fit me needs.
The closest example i could find is this How can I run a <script> tag that I just inserted dynamically from a BHO
but it only covers IE and as i got very little Csharp experience, i would like to see a full example to understand it properly and learn from example.
I would LOVE to have a few examples, even if it's not cross-browser (IE being the worst part for me).
Thanks a lot for your support !
Update1:
About Kango and Crossrider, Kango is 2000$ if you want to use IE and for Crossrider you're required to be distributed and monetized by them.
I've managed to code for IE and Chrome, but i was looking for an "elegant" way and figured it was the best place to ask given the level of knowledge of people on this site.
For the installer i currently use NSIS, but i'll test Wix too.
Finally i guess the only way for me would be to learn C++ and .net to get it to work with IE, but if anyone could provide more source code it would be great to test speed and compatibility and discuss here what's the best solution.
Why do Kango or Crossrider not fit your needs? Both frameworks allow you to manipulate the page's DOM (which is what you want):
Kango: Adding content script
Crossrider: documentation, example code
If you want to code your own solution, take a look at the relevant documentation:
Content scripts (Chrome)
The Page mod Jetpack API (Firefox)
Injected scrips (Safari)
Injected scripts (Opera)
Internet Explorer does not natively support extensions. It took me about 80 hours to create a stable and reliable IE extension which supports cross-site AJAX, a (preference) storage method and injection of scripts as early as possible in any frames based on its URL. I developed and tested the extension with Visual Express 2010 on Windows XP and Windows 7, for IE 8-10 (the extension might work on IE6/7, but I decided to not support these ancient and rarely used browsers).
First, I wrote an extension in C# based on LiveReloadIEExtension (a sample IE extension, which in turn is based on this Stack Overflow answer - see also this blog post). It was functional, but it required .NET 4, lacked support of frames, and it's relatively slow.
So, I decided to write an IE extension from scratch in C++. A good starting point is available at http://www.wischik.com/lu/programmer/bho.html: Sample code for C++ BHO, which changes the document's background based on key/mouse events. I've also learned a lot by looking at other code samples on CodeProject, topics on the MSDN forums, questions and answers on Stack Overflow, lots of other blogs, and the MSDN documentation:
DWebBrowserEvents2 interface lists several events which you use to find an appropriate injection point.
Scripting Object Interfaces (MSHTML) lists even more interfaces. You'll be mainly interested in the iHTMLDocument, iHTMLDocument2, ... interfaces.
After creating the IE extension, you want to deploy it of course. I used Wix toolset to create a MSI.
I would like to know what the members of this great community think of developing and adjusting their web apps and sites in general to recent Google Chrome beta browsers on Linux and Mac OS X and of course Google ChromeOS.
Do you think it's too early and I shouldn't waste my time adjusting myself to something that might change due to bugs resolutions?
Thank you.
Since Google Chrome uses Webkit you could also (as an alternative) test against Safari or Konqueror instead. Chances are your test results will be very portable across these browsers.
I think you answered your own question. While it is good to test against multiple browsers, there is very little point in testing against a beta browser - especially one with as little marketshare as Chrome.
With that said, the only reason I could see testing against a beta browser, is that you want your website to look good in it as soon as it is released and becomes mainstream. But, I really only see this need arising for the browsers that, again, are more popular.
Code against the standard, if you code it right the browsers will move toward you - rather than you constantly playing catchup.
I want to display a message to users with unsupported browsers, as opposed to having the site fail in an ugly manner.
What's the best way to do that?
GWT also provides browser detection using the .gwt.xml file. Have a look at this:
http://code.google.com/p/google-web-toolkit-doc-1-5/wiki/DevGuideDeferredBindingReplacement
It's an interesting solution, but I'm not sure if it's the best solution in your case. It could be very useful for creating a simplified version of your application which would automatically be loaded in unsupported browsers.
The GWT team does not provide a list of unsupported browsers, only supported browsers, and it's a vague list at that "most recent versions of Internet Explorer, Firefox, and Safari. (Opera, too, most of the time.)".
If you have a good idea yourself of what browser/version won't work you can use this code:
public static native String getUserAgent() /*-{
return navigator.userAgent.toLowerCase();
}-*/
to learn what browser is being used and perhaps cook up a work-around.
On the other hand, browser rendering of web pages can fail in many subtle ways ranging from mildly annoying to catastrophic, and there is often no way to know where your page falls on that scale. One of the major reasons for GWT is that you can stop worrying about this sort of thing. At least until it happens.
If you want to make it simple and stupid, check with some javascript code in your main html file, before GWT is loaded. Novertheless, I would rather trust GWT to handle things more or less quirky. You could also just recommend chrome or firefox.
I realise this is an old question, but I had the same problem, and wanted to share a new solution for it.
Today with GWT2.7 "obsolete" browsers try to download undefined.cache.js. This obviously fails and the client is stuck forever.
You could patch GWT itself setting fallback compile steps, but the easy solution is to simply provide a (manually crafted) undefined.cache.js and place it where the other generated files are.
Inside you put this one line:
xxxxxxx.onScriptDownloaded(alert('This browser is not supported anymore.\nPlease upgrade to a more recent browser.'));
where xxxxxxx is your module basename (from xxxxxxxx.gwt.xml).