When I try to get browser version with window.navigator.userAgent it displays Mozilla on Internet Explorer too. I tried navigator.appCodeName before, but it was the same problem.
What could be the reason ?
Thanks.
Internet Explorer 10 and above versions behave differently from IE 9 and below. When using javascript you need to handle those scenarios differently. Following code worked for me :)
//MSStream object supported only for IE 10 and 11 (hope this will work for above IE 11 too .. )
var isIE10or11 = window.MSStream;
//FormData object allow you to send form data as key and value pairs with ajax requests. Supported in modern browsers.
var isFormDataSupported = (window.FormData !== undefined);
if(isIE10or11 && isFormDataSupported){
alert('IE 10 or 11');
}
else if(!isIE10or11 && isFormDataSupported){
alert('HTML 5 browser Excluding IE');
}
else{
//Neither supports MSStream nor FormData object
alert('IE Version 9 or below');
}
Related
I am using the chrome namespace for both Chrome and Firefox, but would like to know which browser is running the web extension.
Links to extension resources have different schemes in Chrome and Firefox.
const isFirefox = chrome.runtime.getURL('').startsWith('moz-extension://');
const isChrome = chrome.runtime.getURL('').startsWith('chrome-extension://');
Check chrome.app which is absent in Firefox:
const isFirefox = !chrome.app;
Check for browser which is absent in Chrome:
const isFirefox = window.browser && browser.runtime;
(the additional check is to avoid false positives on pages that have an element with id="browser" that creates a named property on window object for this element)
Use the asynchronous browser.runtime.getBrowserInfo.
P.S. navigator.userAgent may be changed during debugging in devtools when switching to device mode or via about:config option in Firefox so it's an unreliable source.
This is what I do in my own extensions to check for Firefox (FF) vs Chrome:
const FF = typeof browser !== 'undefined';
Update: (1)
Here is an explanation .....
I am using the chrome namespace for both Chrome and Firefox, but would
like to know which browser is running the web extension.
AFA I understand, the question relates to extension code and not content code. I use above code in background script in "firefox-webextensions" or "google-chrome-extension" background script.
From then on then code would be:
if (FF) {...}
else { .... }
Once established, content script has no bearing on it.
In case of a developer who somehow decides to use id="browser" then a further step could be added which returns a boolean true|false e.g.
const FF = typeof browser !== 'undefined' && !!browser.runtime;
Worth nothing that the following returns an object or undefined and not a boolean
const isFirefox = window.browser && browser.runtime;
While it works fine in if() conditionals, it wont work in other situations where a boolean would be required (e.g. switch)
(1) Note: Marking down answers, discourages people from spending time and effort in answering questions in future.
The localStorage object in Internet Explorer 11 (Windows 7 build) contains string representations of certain functions instead of native calls as you would expect.
This only breaks with vanilla JavaScript and sites like JSFiddle have no problem with this code but I suspect it's because there are localStorage polyfills in place that correct it.
Take this HTML page code for example:
<!DOCTYPE html>
<script>
localStorage.setItem('test', '12345');
alert(localStorage.getItem('test'));
localStorage.clear();
</script>
This works perfectly well in all my installed browsers except for IE11. An error occurs on the first line 'SCRIPT5002: Function expected'.
Taking a look at what type the setItem function actually is in the IE developer tools console, states that it's a string...?
typeof localStorage.setItem === 'string' // true
Printing out the string for setItem displays the following:
"function() {
var result;
callBeforeHooks(hookSite, this, arguments);
try {
result = func.apply(this, arguments);
} catch (e) {
callExceptHooks(hookSite, this, arguments, e);
throw e;
} finally {
callAfterHooks(hookSite, this, arguments, result);
}
return result;
}"
Oddly enough, not all functions have been replaced with strings, for example, the corresponding getItem function is indeed a function and works as expected.
typeof localStorage.getItem === 'function' // true
Changing the document mode (emulation) to 10 or 9 still doesn't resolve the problem and both result in the same error. Changing the document mode to 8 gives the following error 'Object doesn't support this property or method' which is expected since IE8 doesn't support localStorage.
Is anyone else having the same issue with IE11 on Windows 7 where the localStorage object seems 'broken/corrupt'?
Turns out this is a problem in the base version of IE11 (11.0.9600.16428) for Windows 7 SP1.
After installing a patch to update to 11.0.9600.16476 (update version 11.0.2 - KB2898785) the issue gets resolved. Links to other versions of Windows (32-bit etc.) can be found at the bottom of the patch download page.
It's not just IE11's fault.
Probably WEINRE is injected into the page. It hooks into several system functions to provide Developer Tools functionality, but IE11 interprets assignments to the localStorage and sessionStorage properties wrong, and converts the hook functions into strings, as if they were the data that is going to be stored.
There's a comment in the apache/cordova-weinre repo which says:
#In IE we should not override standard storage functions because IE does it incorrectly - all values that set as
# storage properties (e.g. localStorage.setItem = function()[...]) are cast to String.
# That leads to "Function expected" exception when any of overridden function is called.
object[property] = hookedFunction unless navigator.userAgent.match(/MSIE/i) and (object is localStorage or object is sessionStorage)
Looks like it's either an old version of WEINRE being used, or this change hasn't been officially released (it's been there since 2013).
My localStorage returned undefined and I couldn't figure out why - until I realized that it was because I was running the HTML-page (with the localStorage script) directly from my computer (file:///C:/Users/...). When I accessed the page from a server/localhost instead it localStorage was indeed defined and worked.
In addition to the already excellent answers here, I'd like to add another observation. In my case, the NTFS permissions on the Windows %LOCALAPPDATA% directory structure were somehow broken.
To diagnose this issue. I created a new Windows account (profile), which worked fine with the localStorage,so then I painstakingly traversed the respective %LOCALAPPDATA%\Microsoft\Internet Explorer trees looking for discrepancies.
I found this gem:
C:\Users\User\AppData\Local\Microsoft>icacls "Internet Explorer"
Internet Explorer Everyone:(F)
I have NO idea how the permissions were set wide open!
Worse, all of the subdirectories has all permissions off. No wonder the DOMStore was inaccessible!
The working permissions from the other account were:
NT AUTHORITY\SYSTEM:(OI)(CI)(F)
BUILTIN\Administrators:(OI)(CI)(F)
my-pc\test:(OI)(CI)(F)
Which matched the permissions of the parent directory.
So, in a fit of laziness, I fixed the problem by having all directories "Internet Explorer" and under inherit the permissions. The RIGHT thing to do would be to manually apply each permission and not rely on the inherit function. But one thing to check is the NTFS permissions of %LOCALAPPDATA%\Microsoft\Internet Explorer if you experience this issue. If DOMStore has broken permissions, all attempts to access localStorage will be met with Access Denied.
I love what chrome offers me through its extension API.
But I always find myself lost in the jungle of what API is supported by which chrome version and when did the last chrome.experimental feature make it into the supported extensions.
The Chrome extension page gives me a nice overview what is supported, but without mentioning since what version. The same is true for the experimental API overview. Is that specific API still experimental or is it already supported in canary, for example.
If I try a sample from the chrome Samples website I usually have to change some API calls from chrome.experimental.foo to chrome.foo or find out that it is not supported at all. (What happened to chrome.experimental.alarm?) That usually means to just use the trial and error approach to eliminate all errors, until the sample works.
tldr;
So, I'm wondering is there an overview page which tells me since what version, what API is supported or when it was decided to drop an experimental API. And if there is no such page, what is the recommended way or your personal approach to deal with this situation?
On this page, the process of generating the official documentation (automatically from the Chrome repository) is described. On the same page, you can also read how to retrieve documentation for older branches. Note that the documentation is somehow incomplete: Deprecated APIs are included immediately, although they're still existent (such as onRequest).
What's New in Extensions is a brief list of API changes and updates (excluding most of the experimental APIs). It has to be manually edited, so it's not always up-to-date. For example, the current stable version is 20, but the page's last entry is 19.
If you really need a single page containing all API changes, the following approach can be used:
First, install all Chrome versions. This is not time consuming when done automatically: I've written a script which automates the installation of Chrome, which duplicates a previous profile: see this answer.
Testing for the existence of the feature:
Write a manifest file which includes all permissions (unrecognised permissions are always ignored).
Chrome 18+: Duplicate the extension with manifest version 1 and 2. Some APIs are disabled in manifest version 1 (example).
Testing whether a feature is implemented and behaving as expected is very time-consuming. For this reason, you'd better test for the existence of an API.
A reasonable manner to do this is to recursively loop through the properties of chrome, and log the results (displayed to user / posted to a server).
The process of testing. Use one of the following methods:
Use a single Chrome profile, and start testing at the lowest version.
Use a separate profile for each Chrome version, so that you can test multiple Chrome versions side-by-side.
Post-processing: Interpret the results.
Example code to get information:
/**
* Returns a JSON-serializable object which shows all defined methods
* #param root Root, eg. chrome
* #param results Object, the result will look like {tabs:{get:'function'}}
*/
function getInfo(root, results) {
if (root == null) return results;
var keys = Object.keys(root), i, key;
results = results || {};
for (i=0; i<keys.length; i++) {
key = keys[i];
switch (typeof root[key]) {
case "function":
results[key] = 'function';
break;
case "object":
if (subtree instanceof Array) break; // Exclude arrays
var subtree = results[key] = {};
getInfo(root[key], subtree); // Recursion
break;
default:
/* Do you really want to know about primitives?
* ( Such as chrome.windows.WINDOW_ID_NONE ) */
}
}
return results;
}
/* Example: Get data, so that it can be saved for later use */
var dataToPostForLaterComparision = JSON.stringify(getInfo(chrome, {}));
// ...
How can I detect if the browser is an internet explorer or firefox or chrome? Is there an easy way like just using jquery. Because I want to limit the jquery calls if my user agent is internet explorer.
Please advise.
Many thanks.
jQuery.browser is deprecated in jQuery since 1.9.
There is a plugin for jQuery that adds this "back" to jquery. You will fid it (and documentation) at https://github.com/gabceb/jquery-browser-plugin
Install it by adding <script src="/path/to/jquery.browser.js"></script> after where you are adding jQuery.
then you can use the following.
$.browser.msie; //returns true if ie
$.browser.webkit; //returns true if webkit-browser (Safari, Chrome)
$.browser.mozilla; //returns true if firefox
Try jQuery.browser
Check if IE
$.browser.msie ? alert('Internet Explorer') : alert('Not Internet Explorer');
Or info for the browser that is accessing page
$.each($.browser, function(i, val) {
$("<div>" + i + " : <span>" + val + "</span>").appendTo(document.body);
});
Working example here
I have a content editor web part. Whenever I edit the content and then click save, the following errors occurred:
"Cannot retrieve properties at this time."
"Cannot save your changes"
How do you fix this?
I tried googling it.. there are some similar cases but not exactly the same. I tried this link:
www.experts-exchange.com/OS/Microsoft_Operating_Systems/Server/MS-SharePoint/Q_21975446.html
and this one:
support.microsoft.com/kb/830342
and this one:
blogs.msdn.com/gyorgyh/archive/2009/03/04/troubleshooting-web-part-property-load-errors.aspx
I found the answer!! apparently using mozilla firefox it worked. Then I found out that there is a javascript error in IE, this javascript error doesnt happened in firefox. how ironic!
Are you doing anything to modify the URL in an HTTPModule? I ran into this problem on a publishing site where a module was hiding the "/pages" part of the URL. Modifying the CEWP via the page when accessed w/o the "/Pages" wasn't working, but with the "/Pages" it was.
Example:
Got error: http://www.tempura.org/webpartpage.aspx
Worked: http://www.tempuri.org/pages/webpartpage.aspx
I don't see how this is an answer -- "don't use IE".
In my case (and apparently many others) it has something to do with ISA + SharePoint + host headers. I will post the fix if I find one.
I have had problems with this before and have found recycling the Application Pool often corrects the problem.
Rodney
IE8 -->
Tools --> Compatiblity View Settings --> CHECK THIS : Display All Websites in ....
If you are editing a webpart page, make sure that it is checked out. Sometimes the document library the webpart pages are in will have a "force check out to edit" option and it will give you errors if the webpage itself isn't checked out.
I had this same error recently. In javascript, I had written some prototype overrides (see examples below) to add some custom functions to the string and array objects. Both of these overrides interferred with SharePoint's native JavaScript somehow in IE. I removed the references from the master page and this issue was FIXED. Currently trying to find a work-around so I can keep them because things like the string.format function is very nice to have...
//Trim
if (typeof String.prototype.trim !== 'function') {
String.prototype.trim = function(){
return this.replace(/^\s+|\s+$/g, '');
}
}
//Format
String.format = function() {
var s = arguments[0];
for (var i = 0; i < arguments.length - 1; i++) {
var reg = new RegExp("\\{" + i + "\\}", "gm");
s = s.replace(reg, arguments[i + 1]);
}
return s;
}
I also faced the same problem. Finally it worked for me using url /Pages/Contact-Us.aspx instead of clean URL. It worked only with IE browser. Don't know why this was happening but anyhow it worked with me.
Use IE browser
Use Pages in the URLinstead of clean URL.
to me,
compatibility mode in IE8, to work