I happen to be working on some changes to a proof-of-concept app I already have in the Chrome Web Store that are indeed awesome: the chrome.app.window.create() option that allows developers to bake Aura/Ash transparency into their windows (right now, there's actually a static image set as the app's background). Since the app is only really meant for Chrome OS users anyway, the fact that it depends on Ash to function is really no problem on my part.
However, there's a stumbling block. Thank God it doesn't actually require the experimental permission, as that would ban an update to the app from entering the CWS, but still, the only way the window will truly be transparent is with the Experimental APIs flag enabled. So, is it possible to check if the Experimental Extension APIs are enabled to fall back on the app's packed wallpaper in case they aren't?
This API is still being developed, and has not completely gone through our API approval process, so it might change. That's why it is listed as experimental :) You shouldn't ship an app relying on this API in its current state as it will likely break.
Having said that, part of the plan is to allow you to detect, via the API, whether the feature is available. This is so your app will be able to work on platforms like Windows XP that won't support transparency.
Related
I want to identify a user by unique machine id across all browsers. So came up with an idea of launching a app which determines the machine-id (like electron using nodejs) and passes back the info to the browser that launched it and use for identifying the user.
I have seen something like this been done on canyourunit
Can anyone point me right direction where can i find some info about this kind of approach.
As you would be asking a user to download and execute native code, electron or whatever else, there are several complicated issues to consider.
The obvious first one is that you must consider the user platform (OSX, Windows, Linux...) then, communicating back with the browser directly (which one?) is probably not practical.
Your native application could however send the machine id/fingerprint to your backend so you could identify what web client is what.
This is quite involved, fragile, and even if you only support Windows, will fail in many scenarios (system policies, firewalls, antivirus, proxies, strange network setups...)
All in all, it would seem that you should consider more standard Device fingerprinting techniques if you only need an ID.
I'm trying to detect whenever the default/selected microphone changes or gets disconnected in a web app using plain Javascript. The idea is to let the user know if the correct microphone is selected and working or not.
The best option I've found is MediaDevices.ondevicechange. But it seems to be behind the Experimental Web Platform features flag in Google Chrome:
It is behind the Experimental Web Platform features flag, and use call it with navigator.mediaDevices.ondevicechange = ...
Another answer on this topic echoes the same thing:
Browser Support It looks like it's pretty patchy as of writing this. See this related question: Audio devices plugin and plugout event on chrome browser for further discussion, but the short story is for Chrome you'll need to enable the "Experimental Web Platform features" flag.
My question is two-fold:
Is my understanding actually correct that I cannot use MediaDevices.ondevicechange on Chrome without the experimental features flag? (I cannot use this flag because of some other constraints).
Is there another way for me to detect an audio device change?
I'm doing some research on whether or not it's possible for a web app (meant to be used and distributed internally) to scan and read files from a local directory (on user machine). I came across a couple of terms as following:
NPAPI: no longer supported by majority of web browser
ActiveX: IE only
Sandbox: Chrome uses this kind of technology, plus it's not fitting to the requirement so I have to look elsewhere
I feel like ActiveX might be the only option even though I haven't actually written any ActiveX control before (not sure if it's possible).
Also the goal is to support more than one kind of web browser, so other than IE I thought Firefox might be capable of achieving the requirement, since no search result so far said otherwise.
Could someone please give me some pointer? I just need to know if it's at all possible to build a ActiveX control or Firefox extension to scan and read files from a local directory. If it is, then what is the downside other than security vulnerability.
So recently I've come across a Webapp on Chrome Web Store called Type Fu. What amazed me is they actually created a true chromeless window.
I'm thinking if I can do it in a Chrome extension because in most parts they use the same APIs. However, I can't find anything that will let me to do this effect.
chrome.tabs.create is not useful at all.
It would be madness if I can't do that in an extension because in my opinion, an extension should have more "power" than a webapp (a webpage basically).
I couldn't press Ctrl + Shift + I or even right-click on it. It's just like a real native program on my computer.
Some buttons will open another floating chromeless window.
...in most parts they use the same APIs
Chrome extensions are designed to interact with the browser. Chrome packaged apps are designed to be standalone and operate independently from the browser. Their APIs have now widely diverged. Just take a look at the API listings for apps and the equivalent listing for extensions, and you'll see that they are quite different.
In this case, the Type Fu uses the chrome.app.window API, particularly the frame: 'none' option of the create function.
As the name of app.window suggests, it's only available to packages apps, not extensions. The extension-based chrome.windows.create method will eventually support a type: 'panel' option that will supply visually similar functionality (see it at work in Google's Hangouts extension). It's described in the API with a note:
The 'panel' and 'detached_panel' types create a popup unless the '--enable-panels' flag is set.
Currently only Hangouts is whitelisted to use panels, but the discussion at Having panel behavior in chrome extension suggests that your extension can pretend to be Hangouts by adding a specific key value to your manifest:
"key": "MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDsDApubb73tPfYlNIFxDu3K3/EHgV6/YOJXJkld1OZ20jW/cOht1j0NggnXhQYuu1mXFUufud4I2N7b5ydyg09gcM9Va3Zk17RhNV9smbPHOd4XlzJeXifX/9MgHPu4FzCen3CiSXsOeAELJIXEuT28xICriuUko/rNPwGeIB9VwIDAQAB"
However, I wouldn't rely on this undocumented behavior; Google is likely to fix it, or it may break something else in the future.
Until panels are fully supported then, you can begin developing your extension with the --enable-panel browser flag and hope the feature is enabled by default once you have completed development.
I need to write a Chrome extension to track file download dates and speeds.
Is there any Google Chrome API to detect when a file starts/ends downloading?
Thanks,
-J.
There's something in the pipe right now!
http://developer.chrome.com/extensions/downloads.html
No, not at the time of writing.
The Chrome extensions API documentation doesn't currently cover such functionality.
The experimental downloads API doesn't cover the functionality you need but may be worth checking back on as changes are made.
Tracking starting and stopping can be done with onCreated/onChanged/search(), which are implemented and will probably be released out of experimental into the dev branch in a couple weeks or so. I'll make an announcement on the Google Chrome Developers G+ stream.
Tracking the speed of the download can be approximated, but the speed that is displayed in the shelf and chrome://downloads is not directly accessible via the extension api as currently spec'd. We'll consider exposing the information if there's a use case that can't be met well enough by approximation.
No firm plans yet on when the api will be released to the stable branch.