When testing various demos for webauthn, the credentials.create() function stopped working for safari (on mac), returning NotAllowedError: Operation failed. I tried these demos (1 , 2 , 3), and they all still work on chrome, but after being able to create two passkey credentials through safari, I can no longer use any webauthn demo (on my device) to create a credential (for any authenticator type). Nothing changed about my computer or my safari preferences. What could be going on here? Is there some setting to change in the .create() options that could prevent this?
Two potential causes spring to mind.
There are issues with ongoing concurrent WebAuthn requests, such as across multiple tabs. You may either have had a visible request going via a modal window, or have encountered a browser bug. In both cases, you'd see the issue clear up if you quit the browser (or force-quit on iOS-based platforms).
Because of the potential for abuse of modal UI, latest Safari institutes a policy where after the first request, subsequent requests may have to be triggered by user activation (e.g. a click). Older versions of Safari instituted more aggressive policies here, including not carrying that activation through a fetch()
Related
I am using ModHeader when I test with mock but when I pause it and I am connected with a real service then it seems that I cannot use real test data to test and I get always error pages. If I go on incognito mode and use the same test data (real service behind) then all good, I don´t have any problem. If my session is expired and I continue testing without being in a incognito mode then I have again no problem. It is somehow a session saved somewhere and sees that extension as active although is not. This issue appeared after a couple of updates of the browsers (Chrome and Firefox). I use the extension on Chrome and Firefox equally. Anyone having something similar?
Hello I'm using neodynamic weblientprint to print directly from browser. There's a part that includes a script that detects if the client utility is installed, after which its retrives the printers installed on the system.
However I intermittently get this error when the script runs - Unable to launch 'webclientprintvi: -getPrinters: because a user gesture is required.
I get this error on some client system browsers, while some client systems browsers never show this error. Is there a setting that needs to be configured on the browser. Browsers tests are chrome and edge
Thanks.
I discovered that if you are using the WCPP detection feature, then calling jsWebClientPrint.getPrinters() will produce the "...because a user gesture is required" console error. I had a page that called that method w/o the detection and it worked w/o complaining.
I didn't dive any deeper than that as to determining why the extra embedding detection causes this to happen. I just re-worked the page, calling the method instead on a Refresh button click; which, of course Chrome is then happen with.
In a previous answer regarding Notification Delegation between Chrome and an Android TWA app it was said that:
"If the TWA has notifications disabled in Android Settings, we disable
them in Chrome instead. There's a little bit of latency with how this
gets propagated, but things should get updated on the next TWA launch
at latest.
How exactly Notification Delegation does work?
On my site I am sending the user to androids app notification settings when I find that notifications are not allowed in the browser.
But upon the users immediate return, the changes are not propagated to Chrome (to be expected from the comment above since the TWA is not launched again).
I wonder if there is anyway I can speed this up? Otherwise the user is forced to exit the page completely and restart the app before the permission is granted, which is not a very good user experience.
It seems the only workaround would be to force restarting the application, which is not a great user experience. I have filed an issue on Chromium bugs to track a fix for this: https://bugs.chromium.org/p/chromium/issues/detail?id=1064300
Is it possible to capture desktop screen sharing through webRTC.. As we know that it just captures the screen on the browser tab but is it possible to capture the whole desktop screen like navigating through files on computer or opening and viewing files like pdf etc..
Currently, only "stateless" screen capturing is available in RTCWeb implementations (both chrome & firefox). E.g.
Install chrome extension and then try this demo
Above demo will simply capture screen of "any" opened application's screen. Though, such screen capturing API fails to capture screens of full-screen game applications.
More information available here:
https://developer.chrome.com/extensions/desktopCapture (HTTPs+getUserMedia+postMessage)
Regarding remote desktop sharing from a web-browser, it has a pile
more security risks associated with it compared to screen sharing. The
UI/security aspects will be tough to deal with, and the feature will
be very susceptible to social engineering -- phone call: "this is
Google/Dell/Computer-Management; we've detected your machine has a
virus on it; could you browse to and we'll assist you in
removing it" -- etc. Ref
Yes, it's possible. At least using Chrome. There are several ways of doing it, but the simplest one is:
Add this constaint when you invoke getUserMedia:
constraints.video.mandatory.chromeMediaSource = 'screen'
When starting chrome, use this argument (chrome version > 35):
--enable-usermedia-screen-capturing
You can find an example of sharing screen and recording the shared screen at a remote server repository here:
https://github.com/Kurento/kurento-tutorial-js/blob/develop/kurento-recorder-screen/static/index.js
If you try to execute that example, play close attention to the security restrictions. All signalling needs to travel using TLS. Using raw HTTP will produce chrome to refuse sharing screen.
Yes it is. I recently worked on WebRTC and was able to stream desktop easily. Following links helped me implement my requirements :
Firefox Extension : http://mozilla.github.io/webrtc-landing/
Dont forget to add your *.github.io to about:config -> getUserMedia screensharing allowed domains
Google Chrome extension : https://developer.chrome.com/extensions/samples#search
Open this in Run : Chrome.exe --enable-usermedia-screen-capturing
Other Reference : https://github.com/muaz-khan/WebRTC-Experiment
Prob 1 : Do I need to care about some bugs of Firefox 2, firefox 3, chrome7,8, opera 8,9... etc that can make my site look weird on these old browser ? I wonder if the developer changed the HTML-render-engine everytime they update their browser & make my site imcompatible with all version.
Will almost visitors keep their browser up2date ? If not, please suggest me with some tools that can help me test my site against FF, Chrome, IE, Opera, Safari in all major versions.
(I've try this by some online services but it's extremely slow to take screen shot of my site)
Prob 2 : Is there any difference among browser for PC, Tablet, Mobile (except the screen resolution) that can cause a display error for my website ?
Thanks a lot!
Well, whether you should test your website against:
all browsers: Yes, because Windows users have any among IE, Chrome, Firefox & in remote cases, Safari, Opera among others. Whereas Mac users will have Safari, Chrome as their preferred one.
all versions: Probably no. Limit yourself to only those which are still supported, i.e. IE 7 onwards & so on.
But, the key lies in the engine upon which the browser is based upon. It can be said:
*OS: Kernel :: Browser:Engine*
For instance, Chrome, Safari, both are based upon "webkit" layout engine.
Check out, web-layout engines: http://en.wikipedia.org/wiki/List_of_web_browsers
(This consideration will save a lot of effort as you can be rest assured that browsers using same engine will behave in a similar manner.)
Also, keep in consideration your target audience, this can help you limit your browser choices.
And yeah, most browsers have developer tools (F12 key), which allow you to simulate the previous versions of the browser.
But, all in all, the answer is relative & depends solely upon how much time you have & how much effort, time, testing are you willing to spend...
Developers should always try to make their websites cross browser compatible. I personally wouldn't worry about the very old versions of browsers (ie. Firefox 2) and would instead display a message telling the user that they should upgrade their browser.
As a lot of users don't always upgrade their browsers straight away, you should still try to maintain the compatibility of your site with these browsers.
I would recommend this tool for checking the browser compatibility of your website https://browsershots.org/
As a general rule there is a quick and dirty way to test your site. The dirty assumption is that if it works on IE, it will work in anything since IE handles more things differently than other browsers.
With that being said, you can test on IE by opening up an IE9 browser window and hitting F12. This will bring up a box on the bottom that allows you to check the site for compatibility quickly. On the top right hand corner of the box that popped up there are two drop down menus to change the IE engine that is interpreting the site (The one on the left is the Engine and the one right is compatibility mode that the engine is running). You can switch between IE7 engine to IE9 engine seamlessly and without needing a 3rd party application to do so.