Cross Browser Utility to Encourage Users to "Allow Camera & Microphone" - html

When we ask the user to allow us to use their Camera and Microphone the browser presents some sort of interface asking the user to accept or reject this action.
In Google Chrome this interface looks like this:
Our users seem to be missing the appearance of these Deny and Allow buttons.
Is there any cross browser utility that serves as "visual encouragement" for the user to click allow?
For instance, in the case of Google Chrome, something like a big yellow arrow would appear in the upper right of the page window and point at "Allow".

Agree that the default presentation in the major browsers leaves a lot to be desired. That pop-down menu bar is (typically) visually isolated from whatever the user clicked on to trigger the permission request. That is, their locus of attention is on an element that's disconnected from what they need to do next. This problem is exacerbated (1) by banner blindness (which means that people are used to ignoring animations in their peripheral vision, assuming that it's an ad) and (2) on larger screens.
So those are the issues causing the problem.
Here's a quick video walkthrough of one way to solve the problem by the site and by the browser itself, using Google Maps' "use my location" feature in the web browser:
http://cl.ly/2h2f382A143F/so-browserpermissions.m4v

Related

When will SpeechSynthesis.speak work on iOS Safari?

I've been exploring the limits on SpeechSynthesis.speak on iOS Safari. I believe the current rules are more restrictive than there were in the recent past.
Are the rules documented anywhere?
These are the rules that I think apply.
Speak in direct response to a click on a <button> always works.
After the initial speak initiated by a button click additional speaks are allowed on the same page. They may be triggered programmatically by timers or whatever.
Initial speak on a change/input event does not work.
Initial speak on a click event on a <tr> does not work.
Any change of page, relative or not, puts you back to square one requiring a direct user action.
When a speak is suppressed you don't get any events nor any error indication.
You want tell if the speak was suppressed by watching for SpeechSynthesis.speaking and timing out if it isn't seen after some delay.
Are these consistent with your recent experience?
I've been testing on BrowserStack watching the events that get fired to determine which cases work.
I can confirm that you can't use SpeechSynthesisUtterance programmatically without a user action before. In my case I have in my web app a button to enable/disable audio, if the user enable the audio and later I try to speak something, it doesn't work
To solve it I had to trigger a fake speak (empty text new SpeechSynthesisUtterance('')) right after the user click on enable audio and then the audio works during all the session.

Instagram in app browser is shifting all click events

On the iPhone's Instagram app browser(in app) if you open a website that includes html inputs of any type, something strange happens.
In the beginning everything is working, but once you tap an input and type something ( and the keyboard is opened), after you close the keyboard you can't click on anything anymore because all buttons/inputs/elements are clickable in a different location than where they showed ( button is showed in the original 100px location but click events are now on 50px).
It looks like after the keyboard opens the whole location calculation is shifted up(because the keyboard pushes the whole body up)
How to even begin to debug such thing ?
Honestly, I've been there. There is no way to debug the in-app browser (you can try on an iphone device mirroring with Chrome in MAC, but you will eventually fail), but I've tried without success.
It turned out that after digging around with similar issues, there was a caching issue and some disabled features with WP ENGINE from my client. They were able to fix it by allowing some parameters on nginx settings and then the In App browser wasn't stucked anymore.
I know every issue is different, but at this time, I haven't found a way to debug the In - App browser.
I can't speak to iOS specifically, but there definitely are ways to remote debug things.
My go-to for stuff like this (speaking from experience of browsers on gaming consoles) is Weinre: https://people.apache.org/~pmuellr/weinre/docs/latest/Home.html You get something similar to Chrome Developer Tools, but it works over a Socket.IO connection.
Another tool I like to use is Fiddler. While it won't help you with your DOM issues, if you ever need to debug network stuff on oddball devices, it's perfect. It serves as a proxy server and can intercept all your connections, including HTTPS. https://www.telerik.com/fiddler
Turns out, that it's a fixed position and it's not supported, which means when keyboard is closed, the system will push back the whole view but click events stay up (because it's being pushed up when you open a keyboard).
So instead of make it an absolute modal, which has it's own problem, we keep it fixed, BUT, we do the pushing up/down by our own.
We could just push the screen back down on input unfocused, but if user click the next field you get unwanted behavior, so we create a delay based machine like so :
var isfocused=0;
var focusTimer=0;
$("input").blur(function() {
isfocused=0;
focusTimer = setTimeout(focusDone, 150);
});
$("input").focus(function(){
isfocused=1;
});
function focusDone(){
if(isfocused===0)
$(window).scrollTop(0,0);
clearTimeout(focusTimer);
}
This works great on social browsers, with fixed positioned modals that has inputs inside them.

Hide Icons displayed on address bar in Chrome Extension

I am developing a chrome extension. When I install it one of its icon is displayed in address bar. I want that icon should not be displayed after installation.
Starting with Chrome 49 (see the announcement and detailed description) all extension icons are displayed in the browser toolbar:
[...] each extension the user has installed has a persistent UI surface. By default, this will be in the toolbar to the right of the omnibox (where browser actions are now), and the user can choose to hide ("overflow") these actions in the Chrome menu.
The reason for this is to protect our users. We've heard too frequently that many users are unaware of the extensions they have installed, whether this is due to sideloading, installation by phishing, or simply the user forgetting how many and which are installed. Unfortunately, extensions consume computing resources, and may have significant security, privacy, and performance impacts. Because of this, we've decided we need to increase user visibility.
What this means for your extension:
If the extension has a browser action: Nothing! (Apart from the slightly different hide/overflow functionality.)
If the extension has a page action: The extension will be given a persistent icon in the toolbar. On pages where the extension's page action wouldn't normally be visible, the action will be greyed out, indicating that it doesn't want to act. On pages it does want to act, it will be fully-colored.
If the extension has no action: Similar to page actions, the extension will be given a persistent icon in the toolbar. It will be shown with the greyed-out look all the time.
Displaying the action persistently, even in the cases of a previously hidden page action or an extension with no action, is necessary because the presence of an action doesn’t always correlate with the extension acting. We also can’t show the action conditionally on, e.g., a per-tab basis, because there are many actions that are not correlated with any tab. In order to ensure users are aware of the extensions they have installed that could be affecting their browser, we need to ensure each extension is visible.
We've done our best to limit the functionality this breaks, and hope you understand the trade-off between developer inconvenience and user benefit. Thank you for understanding as we keep our users safe!
An end user of your extension may manually hide the icon either by adjusting the overall toolbar width (click the space between addressbar and toolbar and drag) or by rightclicking an icon and selecting Hide or Show:

Google Chrome Extension Top Sites Images

So using the Google Chrome Top Sites api has values for the url and the title, but when you load the default google chrome page it also has an image of those sites, is there any way to get that sort of image for an extension? If not how does google get that image and how can you get an image of the the user's top viewed website?
Since that it isn't possible to get a screenshot of a page without loading it inside a tab, Chrome is simply getting those screenshots while you're browsing your favourite sites. You can tell this easily because sometimes sites and images do not coincide (e.g. sometimes my facebook.com top site has the image of my profile page, but links to the home).
Then, if you want your screenshots of the Top Sites, you'll have to start without screenshots, and create them while the user browses the web by using the chrome.tabs API to check when a tab loads one of the Top Sites (listening to the event onUpdated), and get a screenshot of that tab using captureVisibleTab.
NOTES: make sure that you've requested the permission for "<all_urls>" in your manifest, which is required for captureVisibleTab to work. Additionally, you may find this question and its answer helpful.
It's unfortunately not possible*. Chrome stores those thumbnails internally in URIs not accessible from an extension.
There is an existing feature request: https://code.google.com/p/chromium/issues/detail?id=11854
If you look at the comments, one of the main use cases is to access site thumbnails to replicate the New Tab page.
Do star the feature request above to raise its priority if you want this functionality implemented.
* By that I mean that it's not possilbe to access Chrome's own internal store of thumbnails.
Furthermore, as Marco suggested the way to replicate that would be tab capture, but you can't do it "in the background" for privacy reasons - a user must make an explicit gesture (e.g. click the extension's button, press a shortcut, etc.) to perform capture.
Marco's answer is valid now, captureVisibleTab should be accessible upon events. But yes, as of now Chrome forces you to have very broad permissions and maintaining your own thumbnail store.

Difference between a chrome popup and Panel

I am building an extension for Chrome and Can't decide If I should use chrome.windows.create type popup , panel or detached panel. I could not find a comparative study of the three options . Any links or short description of positives and limitations of each will be helpful .
Thanks
You are having difficulty understanding it, because unless you specifically enabled an experimental feature, they are exactly the same, or rather the latter ones are ignored and a popup type is created.
Unfortunately, this means that this API is unavailable for general use until Google decides to mark it stable.
Quoting the docs:
The 'panel' and 'detached_panel' types create a popup unless the '--enable-panels' flag is set.
As for what panels are, here is the API proposal with detailed description.
Panels are windows that are visible to the user even while the user is interacting with other applications. The small windows are positioned at the bottom of the screen, with minimal manual window management by the user. This API will allow extension developers to create and use panels.
[...]
An extension opens small "pop up" windows, for example, separate chat sessions, calculator, media player, stock/sport/news ticker, task list, scratchpad, that the user wants to keep visible while using a different application or browsing a different web site. Scattered "pop up" windows are difficult for the user to keep track of, therefore panels are placed along the bottom of the screen and are "always on top".
The user would like easy control of chat windows: finding them, moving them out of the way, etc. Window management of separate chat "pop ups" is time consuming. All panels can be minimized/maximized together.
If you want a real-life example, the Hangouts extension is whitelisted to use this window type; that's how they make the chat panels:
Since chrome doesn't by default enable panels , this need to be set to display panel behavior instead of popup window . Note that popup windows can be re positioned and one can view console window , but none of it is available in panel .