Detect edge://flags/#edge-click-once enabled in Chromium Edge - javascript

We have an application that starts via Click Once in the browser. Since Chromium Edge, Click Once isn't enabled by default. You can enable this setting via edge://flags/#edge-click-once.
I would like to detect if this setting is enabled. If not i would like to direct them to a support page with instructions to enable it.
I don't have access to clients browser in anyway. So I would like to detect this via JavaScript.

I think the flags can't be accessed through js, because js codes can be executed in any browsers. We can't only target the features in a certain browser. I also searched a lot and find no way. Maybe Extension can do this, but I think that will take a lot of effort to research.
As this feature is not enabled by Edge Chromium by default, I think the easiest workaround is to detect the browser version, if Edge Chromium, then remind the user to check if the feature is enabled:
var checkbrowser = (function(agent) {
if (agent.indexOf("edg") > -1) { //check if Edge Chromium
return "the page of showing how to enable clickonce support";
} else {
return "not Edge Chromium"
}
})(window.navigator.userAgent.toLowerCase());
document.body.innerHTML = checkbrowser;
Besides, if your application is used in an enterprise and someone has access to the group policy, you can also suggest IT department to set this group policy: ClickOnceEnabled to enable clickonce in Edge Chromium.

Related

Add to Home screen (A2HS) feature detection (no user agent sniffing)

I have a PWA where Android users are prompted to Add the PWA to their home screen, but I would also like to show a tooltip for Safari users on iOS showing how to add the PWA to their Home screen since it's not a supported feature for them.
I was thinking about using feature detection but I can't find a way to do it, something like:
if ("a2hs" in navigator) {
// Do something for browsers supporting A2HS feature
} else {
// Show the tooltip if the browser does not support A2HS
}
I also thought I could use something like this:
const isIos = () => {
return window.navigator.vendor === 'Apple Computer, Inc.';
};
but this is also returning true for users of Chrome on iOS :(
Any idea how I can detect if a user is using Safari on iOS?
Note: I also want to avoid using user agent sniffing. I think I read almost all topics related to this subject on SO but so far I couldn't find any solution not using user agent sniffing.
a partial solution:
if('BeforeInstallPromptEvent' in window)
alert('Chrome-style PWA install experience supported!');
if('standalone' in navigator) // only available on iOS - but also on alternative browsers on iOS without Add-to-Homescreen support
alert('iOS Safari-style PWA Add-to-Homescreen maybe supported!');
Open problems:
avoid false positives on iOS - if you could accept using the user agent for that, you could use navigator.userAgent.match(/(iOS|OPT|Brave|GSA|DuckDuckGo|Snapchat)\//) to detect most alternative browsers; For explanation: iOS in the regex should detect CriOS|FxiOS|EdgiOS|OPiOS (Chrome/Firefox/Edge/Opera mini); Does anbody have a way to detect alternative browsers on iOS without using the user agent?
it does not detect Firefox on Android; and I don't know if other browsers based on Firefox for Android support PWAs (e.g. QuantMobile, PrivacyWall, Fennec, KAIOS - all tokens that appear together with Firefox and Android in the user agent string)
Addition (untested & unreliable):
I did some more research:
A sure sign that you are in a webview on iOS is (or was?) that navigator.mediaDevices.getUserMedia or maybe navigator.mediaDevices is undefined. But I also read that Apple implemented it some months ago - so there will be webviews for which this isn't true.
Another hint might that if navigator.doNotTrack is undefined, it could mean that you are in a webview (or that Apple decided to remove this deprecated property from Safari...)

SharePoint & JavaScript - The "Open with Explorer" issue

This is a JavaScript/SharePoint issue. I have a similar question in the SharePoint StackExchange community but I haven't got anything over there in months. This particular issue is related to SharePoint 2010.
To the ones not aware, there is standard a functionality in SharePoint that allows users to open Document Libraries with Windows Explorer, which is very handy when you want to upload lots of documents or move file/folders around.
When the user clicks a button called "Open with Explorer", most of the time, the folder opens in Windows. Common answers like "Try restarting WebClient service" will not work, once users do not have permissions to do almost anything in their work PC's.
After researching the SharePoint JavaScript files I found how this functionality is supposed to work:
After clicking the "Open with Explorer" button, some functions will be called, but here is where the "magic" should happen:
function NavigateHttpFolderCore() {
httpFolderDiv = document.createElement("DIV");
...
document.body.appendChild(httpFolderDiv);
httpFolderDiv.onreadystatechange = NavigateHttpFolderCore;
httpFolderDiv.addBehavior("#default#httpFolder");
d = httpFolderDiv.navigateFrame("https://sharepointsite.com/sites/site1/docLib", "_blank");
if(d == "OK"){
...
}
...
}
From above:
addBehavior - not supported by IE 11, Chrome and Firefox, only IE 10 and older. If using IE 11, the <meta http-equiv="X-UA-Compatible" content="IE=8"> will take care of it.
#default#httpFolder - a behaviour(?), apparently not used anymore nowadays (obsolete)
navigateFrame - this either return the string "OK" if successful, meaning that the "Open With Explorer" will indeed Open in Windows Explorer, or it returns the string "FAILED" and the "your client does not support opening this list with windows explorer" will popup in my screen.
My main concern is, why sometimes navigateFrame return "OK" and other times "FAILED"?
Does anyone know what happens "inside" navigateFrame or can I check it? Any ideas?
Thank you
In my case the problem was in IE which blocked navigateFrame() call due to CORS restrictions. I dealt with SharePoint 2013 and provider-hosted add-in: I tried to open WebDAV folder (having the URL containing SharePoint host domain) with JavaScript from a PHAI web application in another domain -- PHAI domain. If you've got this problem in IE (version up to 10 inclusively) and you try to run your JavaScript code in a domain different from SharePoint one, try to add your site to 'Trusted Sites' and set 'Access data sources across domains' to 'Disable' or 'Prompt'.
Excerpt from MSDN :
Behaviors are subject to cross-frame security rules where a document cannot refer to a behavior on another server or another domain. In this case, the addBehavior method returns E_ACCESSDENIED. For more information, see the Security section in the Introduction to DHTML Behaviors article.

Why does accessing the localStorage object in Internet Explorer throw an error?

I'm working on a client issue where Modernizr unexpectedly does not detect the support for the localStorage object in Internet Explorer 9. My page correctly uses the HTML 5 doctype (<!DOCTYPE html>) and the developer tools report the page has a Browser Mode of IE9 and a Document Mode of IE9 standards so I would expect this to work.
I've debugged into the following try/catch block in Modernizr and discovered a JavaScript error is thrown as soon as the localStorage object is accessed.
tests['localstorage'] = function() {
try {
localStorage.setItem(mod, mod);
localStorage.removeItem(mod);
return true;
} catch(e) {
return false;
}
};
On some machines the message of the JavaScript error is The system cannot find the file specified.. On others it is just Invalid argument. and Internet Explorer blocks for exactly 5 minutes before it throws the error.
What is causing accessing the localStorage object to throw an error here on Internet Explorer?
I've discovered if the lowest level subdomain matches one of the reserved device names as documented at Restrictions on the File Mask and File Name Properties on Internet Explorer then accessing the localStorage object will throw an error.
This problem is likely happening because internally Internet Explorer is attempting to access the file system using a reserved device name when accessing the localStorage object in order to satisfy the Storage object initialization steps.
It's certainly very much an edge case but if your page is comes from a server whose lowest level subdomain is exactly any of con, prn, aux, clock$, nul, com1, com2, com3, com4, com5, com6, com7, com8, com9, lpt1, lpt2, lpt3, lpt4, lpt5, lpt6, lpt7, lpt8, or lpt9 (e.g. http://prn.example.com) then this could well the reason why you are seeing this problem.
Choosing a lower level subdomain that wasn't a reserved device name in this situation solved the problem.
We hit a similar issue because we ran CCleaner on the machine.
To solve:
Internet Options -> Browsing History -> Delete:
Make sure to check all options except the very first one (Preserve Favorite website data).
We were able to fix, then reproduce this issue by using CCleaner again, then fix again.
Go to this site for more information: http://grekai.wordpress.com/2013/02/24/localstorage-the-system-cannot-find-the-path-specified/

How to prevent script error in C# webbrowser?

I am getting script error in loading some web sites.
Please help me how to prevent script error in C# WebBrowser.
This is my code:
try
{
webBrowser1.Navigate(textBox1.Text);
while (webBrowser1.ReadyState != WebBrowserReadyState.Complete)
{
Application.DoEvents();
}
MessageBox.Show("Loaded");
}
catch(Exception)
{
MessageBox.Show("failed");
}
Write this in Your Code
webBrowser1.ScriptErrorsSuppressed = true;
To disable the script error pop up, you need to go to (in Internet Explorer) Tools->Internet Options, there go to the Advanced tab, and in Browsing select Disable Script Debugging (Other), but, the problem may be related to the fact that every site loaded in the WebBrowser control is rendered in IE7 compatibility mode, to solve this the only thing you can do is a registry hack like this: WebBrowser control to use IE9
change your registry to 2af8 which is IE 11 for devenv.exe
software/Microsoft/internet explorer/main/featurecontrol/feature_Browser_emulation
If your working with a GUI (like in Visual Studio) just go to the Webbrowser Properties and set "ScriptErrorsSuppressed" = true
It is easy to see how this error has been eliminated. But Visual Studio uses Internet Explorer and another Web Browser coding is hard. If you look at the versions, the last Visual Studio one uses IE 11 for WebBrowser tool.
The C++ GUI is recommended for one of each encoding:
https://msdn.microsoft.com/en-us/library/60k1461a.aspx

prompt() with Internet Explorer 8

I am having a hard time figuring out a solution for my problem. Here's a code snippet:
var ans = prompt("Mot de passe", '');
if (ans != '' && ans != null)
__doPostBack('__Page', ans);
else
window.location = "../Erreurs/NotAuthorized.aspx";
This code works really great with Internet Explorer 9. But my client is exclusively working with Internet Explorer 8 so I tested it with ieTester in IE8. But the problem is that the prompt doesn't show and it automatically redirect because the input had an empty string ('').
So how do I fix this to work with Internet Explorer 8?
IE has an setting in Internet Options to allow or deny prompt().
(source: adamhaskell.net)
By default in IE8, this setting is off. Consequently, calls to prompt() are ignored and "" is returned by them.
You shouldn't use prompt() anyway. Use a form.
It looks like a security thing specific to IE- 8 for sure, I don't have other versions to test. Calling prompt() produces a warning about a scripted window asking for information. I can click to allow and after refreshing the page, the prompt box appears as expected.
If you are going to insist on using prompt(), you will probably have to stipulate that security settings on the target machines are configured to allow it.
Microsoft developer website tells us that "prompt()" is deprecated and now normally blocked for security reasons:
"By default, this method is blocked by the information bar in the Internet zone. This helps prevent malicious sites from initiating spoofing attacks. "
See http://msdn.microsoft.com/en-us/library/ms536673.aspx
From this report it looks like it's a known bug in IETester?
http://www.my-debugbar.com/forum/t294-Javascript-Alerts.html

Categories