I have built some extensions of Google Chrome. I have the CRX files and I kept them my local system which is MAC 10.13. I wish to install my custom build extensions through bash script, purpose is academic only. I have followed the instruction at https://developer.chrome.com/apps/external_extensions. But the extensions are not showing in chrome. Can anybody help?
UPDATE 1
I dont want to host my extensions to chrome web store. If required I can use my web-hosting to store the crx files.
Make sure Chrome is in Developer Mode if you are unable to host your CRX in the Chrome Web Store. Assuming your CRX follow's Google's policies, you might also consider hosting it in the Web Store, and making it private. The latter approach could make it easier to privately share the CRX with your academic peers.
Related
I am learning to build a web application for Hbbtv using the Hbbtv SDK.
So for testing a sample app, I was looking for an emulator and came across FireHbbtv Extension by firefox.
However, whatever I do, it says the extension is not compatible with the version of Firefox. can any of you help with what is happening
Firehbbtv extension is abandoned, but you can install it using an old Firefox version (<52 as far I remember). Make sure the automatic updates are disabled if you want to keep the extension available.
There is another HbbTV plugin named hybridTV (https://github.com/karl-rousseau/HybridTvViewer) It works fine, but it is in development.
There is also a third option, using the opera (now called vewd) SDK. You can find the info and the virtual machine downloads visiting
https://www.vewd.com/products-services/vewd-tv-emulator/
I don't see a VM for Edge listed on http://dev.modern.ie/tools/vms/mac/
Is there currently a way to do this?
Browserstack has Edge available as one of its options. In addition, you can try out the remote.modern.ie to test this via a free cloud version of Windows 10
Link to all of this, and more resources on GitHub
Testing the application using RemoteIE & BrowserStack
There are several ways of testing websites, aside from the good old-fashioned way of using a device lab and physically looking at your site on multiple devices and in multiple browsers. Two of the more popular and easier ways to go about testing include modern.IE remoteIE and BrowserStack.
RemoteIE
RemoteIE is a free service offered by modern.IE that allows you to connect to a hosted version of the latest IE builds running in the cloud using a client. This client, called the Azure RemoteApp Client, is available for Mac OS X, iOS, Android and Windows OS devices, and includes simple installation and account set up steps. The available IE builds run on Windows 10 Technical Preview for Enterprise. In this preview version of the service, only public URLs and IP addresses can be accessed.
Other tools offered by modern.IE include:
Virtual Machines with versions of IE ranging from IE6 to IE11, that can be downloaded and managed in your own development environment.
Browser Screenshots of how your site looks across nine common browsers and devices.
Compatibility reports generated from analyzing your site while it runs to detect patterns of interactions known to cause issues in browsers.
Site scans for common coding problems in your website.
BrowserStack
RemoteIE has partnered with BrowserStack to provide interactive browser testing in the cloud, regardless of the platform, and within your own browser.
BrowserStack is a paid online service, but you can sign up for a free trial. With BrowserStack it is possible to test internal websites or local html designs using remote browsers after configuring for local testing, so the website does not have to be live to test it out. Signing up for the free trial gives you a 30-minute session to test the website in a broad range of platforms and browsers. The full list of browsers & mobile devices for live testing can be found here.
I want to distribute my Mac App on both Mac App Store and my own website. The Mac App Store app will be signed via the Mac App Distribution certificate from Apple and the Website version will be signed via the Developer ID Application certificate. The website version will be distributed as a simple MyAppName.zip file that lets the user unpack MyAppName.app to where ever the user wishes. My app is a document based app that creates documents with extension .mydoc
I have two options to implement such a scenario.
First, and my preferred method is to have same bundle identifier for both apps. If a user tries to install from MAS first and then website; Will both apps live on my Mac without any issues? If a user installs the website version first, and then tries to install from MAS, how will MAS behave? How is it decided that which app will open my document by default?
Second, I use different bundle identifier for the apps on MAS and my website. Essentially they are different apps and I don't like this because it is confusing for a user because the apps look and behave exactly the same. In this case, how is it decided which one of the apps will open my document by default?
If a user tries to install from MAS first and then website; Will both apps live on my Mac without any issues? Answer: YES
If a user installs the website version first, and then tries to install from MAS, how will MAS behave? Answer: MAS will ask user that there already exists a version and if it should be kept.
How is it decided that which app will open my document by default? Answer:
Launch Services documentation says the the behavior is not determinate. So either one will open.
Second, I use different bundle identifier for the apps on MAS and my website. Essentially they are different apps and I don't like this because it is confusing for a user because the apps look and behave exactly the same. In this case, how is it decided which one of the apps will open my document by default? Answer:
Launch Services documentation says the the behavior is not determinate. So either one will open.
This is my first time on this site. I have a HTML/CSS/JS application. For that application to work, we also have a browser npapi plugin ".so" file that is installed in plugins dir of firefox. This works on firefox browser on Linux. Now I want my application to run on Firefox OS (B2G). How do I port that ".so" plugin to firefox OS?.
What I have done is, I have built B2G and flashed it on my test device. I have built that plugin for android platform by using gecko sdk and firefox OS source. I have pushed my .so file in FFOS phone in /system/lib as well as /system/b2g (the folders where I can see other .so files.). Is that the correct approach? What else do I need to do to make it work. Currently my application is unable to load that plugin ( I checked using ./run-gdb ).
Any pointers would be helpful. I have gone through the documentation on mozilla website and also googled it alot but couldn't find the solution.
Thanks.
You are right, NPAPI is not supported on Firefox OS / B2G.
You do see code for it in the tree (and maybe even in the object directories) because much of the code is actually being used over different products (desktop Firefox, mobile Firefox, Firefox OS, ...).
Mozilla use single gecko engine to support all platform browsers. Those plugins are only used by desktop browsers.
Does anyone know if the Mac App Store is allowing third party plugins for the Mail.app? With the new release of Mountain Lion, the security architecture will sandbox every signed application (and thus Mail) so that the process of installing a plugin is very limited.
The question is: since a plugin must use a private API (Mail.app doesn't expose APIs) and access private data from another application, how can this be accomplished within Mac App Store rules? Is it possible at all?
You never could publish plugins through the Mac App Store. The rules only allow for self-contained apps. You also couldn't sell an app that does nothing more than installing your plugin - the rules forbid apps to install any code in shared locations. And with the sandbox it's not possible either.
Your application would need to be usable without the plugin present. MsgFiler offers a good example: it works, albeit slowly, by itself, and offers a plugin downloadable separately from the App Store which speeds it up.