Posted here is an answer that instructs those who miss the old window.showModalDialog JavaScript function to use the
<dialog>
element instead. I have used this along with the polyfill needed for IE and FF and it works. However, there is a noticeable lag introduced when using the polyfill that I would like to avoid for Chrome (not to mention there is a warning not to use the polyfill when browsers support it). How do I detect whether or not the dialog element is supported so I can leave out the polyfill processing? Specifically these lines:
var dialog = document.getElementById('<element id>');
dialogPolyfill.registerDialog(dialog);
You could write a simple test like this:
if (typeof HTMLDialogElement === 'function') {
/** yep */
} else {
/** nope */
}
Try console.log(typeof window.showModalDialog === 'undefined')
if (typeof window.showModalDialog === 'undefined') {
console.log('No. ');
} else {
console.log('Yes! ');
}
function dialogElementSupported() {
return typeof document.createElement('dialog').show === 'function';
}
Related
I have difficulty on integrating my JavaScript syntax. My code is working on Internet Explorer (IE). However, I encountered a JavaScript error when running it on Safari.
This is my test code:
document.onmouseup = function hideaddrspopup () {
if (event.srcElement.id != 'fieldName') {
alert(event.srcElement.id);
}
}
I tried something like:
document.onmouseup = function hideaddrspopup() {
if (event.srcElement.id != 'fieldName' || event.target.id != 'fieldName') {
alert(event.srcElement.id);
alert(event.target.id);
}
}
But still an error is appearing on the console:
'TypeError: 'null' is not an object (evaluating 'event.target')'
I am aware that event.scrElement is only working in IE. How to make it work on the other browsers?
According to MDN:
This feature is non-standard and is not on a standards track. Do not use it on production sites facing the Web: it will not work for every user. There may also be large incompatibilities between implementations and the behavior may change in the future.
Event.srcElement is a proprietary alias for the standard Event.target property. It is specific to old versions of Microsoft Internet Explorer.
So just avoid using event.srcElement instead you should use event.target.
As Bhojendra mentioned don't use srcElement. Check for object null or not before accessing id or target property as below.
document.onmouseup = function hideaddrspopup ()
{
if (e && e.target && e.target.id!='fieldName')
{
alert(e.target.id);
}
else if(e && e.srcElement && e.srcElement.id!='fieldName')
{
alert(e.srcElement.id);
}
}
Updated with else if to support older IE browser. target should support it too but you could test without else part if it is necessary or not.
You're missing the event variable in your function
document.onmouseup = function hideaddrspopup (event)
{
if (event.srcElement.id != 'fieldName' || event.target.id != 'fieldName')
{
alert(event.srcElement.id);
alert(event.target.id);
}
}
I see that XPathEvaluator isn't supported in IE 11 however I wanted to know if there's a proper detection mechanism to check for it's existence if not fall back to the selectSingleNode method in IE.
Something similar to this however whenever I check for XPathEvaluator in this fashion it blows up in IE 11 but works in Firefox/Chrome
if (XPathEvaluator) {
var xpe = new XPathEvaluator();
...... evaluation logic
return results.singleNodeValue;
}
else {
return xmlDoc.selectSingleNode(elPath);
}
Previous logic used to rely on the existance of the window.ActiveXObject to call selectSingleNode however the property has since been removed in IE 11 causing XPathEvaluator logic to be hit instead.
I'd rather detect if this functionality exists and not check for browser versions as features and functionality are constantly changing.
This is my simple test case.
IE 11 will alert the I am not IE popup, and then blow up on the XPath.
FF/Chrome will alert the I am not IE pop and then alert XPathEvaluator is a go.
function selectSingleNode()
{
// previous logic relied on this to call XPathEvaluator
if(window.ActiveXObject)
{
alert('Im IE');
}
else
{
alert('I am Not IE');
}
// I wanted to do something like this.
if(XPathEvaluator)
{
alert('XPathEvaluator is a go');
}
else
{
alert('XPathEvaluator is a no go');
}
}
If you want to use a certain method then check for it, so if you want to use selectSingleNode then do
if (typeof xmlDoc.selectSingleNode != 'undefined') {
// now use selectSingleNode method here
}
I am not sure why you want to check for XPathEvaluator, if you want to check whether there is an evaluate method on the document node to use the W3C DOM Level 3 XPath API then doing
if (typeof xmlDoc.evaluate != 'undefined') {
// now use evaluate method here
}
So together you can check
if (typeof xmlDoc.evaluate != 'undefined') {
// now use evaluate method here
}
else if (typeof xmlDoc.selectSingleNode != 'undefined') {
// now use selectSingleNode method here
}
I have been searching on the internet for a reason why my fullscreen javascript doesn't work in Safari, but yet works in webkit browser Chrome. It seems to that safari doesn't support the element.ALLOW_KEYBOARD_INPUT add-on for webkitRequestFullScreen.
function cancelFullScreen(el) {
var requestMethod = el.cancelFullScreen || el.webkitCancelFullScreen || el.mozCancelFullScreen || el.exitFullscreen;
if (requestMethod) { // cancel full screen.
requestMethod.call(el);
} else if (typeof window.ActiveXObject !== "undefined") { // Older IE.
var wscript = new ActiveXObject("WScript.Shell");
if (wscript !== null) {
wscript.SendKeys("{F11}");
}
}
}
function requestFullScreen(el) {
// Supports most browsers and their versions.
var requestMethod = el.requestFullScreen || el.webkitRequestFullScreen(el.ALLOW_KEYBOARD_INPUT) || el.mozRequestFullScreen || el.msRequestFullScreen;
if (requestMethod) { // Native full screen.
requestMethod.call(el);
} else if (typeof window.ActiveXObject !== "undefined") { // Older IE.
var wscript = new ActiveXObject("WScript.Shell");
if (wscript !== null) {
wscript.SendKeys("{F11}");
}
}
return false
}
function toggleFull() {
var elem = document.body; // Make the body go full screen.
var isInFullScreen = (document.fullScreenElement && document.fullScreenElement !== null) || (document.mozFullScreen || document.webkitIsFullScreen);
if (isInFullScreen) {
cancelFullScreen(document);
} else {
requestFullScreen(elem);
}
return false;
}
Does anybody know a way to make safari accept fullscreen yet still be able to handle keyboard inputs?
According to Apple's documentation, this is supposed to work in Safari 5.1 and later, but obviously it doesn't. I filed a bug report with Apple (which they don't make public), and the reply was as follows:
Engineering has determined that this issue behaves as intended based on the following:
We intentionally disable keyboard access in full screen for security reasons.
I have replied asking that they at least update the documentation and make the lack of feature support detectable somehow. I will update here if I get a reply.
Unfortunately, there isn't a good way to even do feature detection, since element.ALLOW_KEYBOARD_INPUT is defined in Safari, and the function call with that flag doesn't throw an error. The only remaining option is to parse the user agent string (try this library).
Obviously, Apple doesn't yet document which version supports this, but according to this, it stopped working as of v5.1.2. That would leave a very small number of people using 5.1 un-patched, if it ever even worked at all. So it's probably not even worth detecting the version.
As a fallback, I would expand the desired DOM element to fill the browser window by setting CSS height and width to 100% and position to "fixed" or "absolute".
Update: It looks like the documentation has been corrected and no longer mentions the ALLOW_KEYBOARD_INPUT flag.
This has been fixed in Safari 10.1!
Under the "Safari Browser Behavior" section.
I am having the below code for population the select box dynamically.THis works fine in all browsers except FireFox 3.6
var option25 = document.createElement("option");
option25.text = '25 miles';
option25.value = 25;
if(rad == '25')
{
option25.selected = 'selected';
}
var combo = document.getElementById('ddlProximity_' + controlId);
combo.add(option25); //not working in FF3.6
Any suggestions
The add method on select elements takes two arguments in Gecko versions older than 7 (MDN).
In IE it only takes one argument, or two if it's IE 8 in IE 8 standards mode, or something MSDN.
If we take krg's code and check the arity before calling add it works in Firefox 3.6.28, Firefox 15.0.1, and IE 9:
if (typeof combo.add === 'function') {
if (combo.add.arity === 1) {
combo.add(option25);
} else {
combo.add(option25, null);
}
} else if (typeof combo.appendChild === 'function') {
combo.appendChild(option25);
}
Assuming combo is a select menu, see this jsFiddle example.
if (typeof combo.add === 'function') {
combo.add(option25);
} else if (typeof combo.appendChild === 'function') {
combo.appendChild(option25);
}
If you would like to ensure that your JS code works across a wide spectrum of browsers, I would use a JavaScript framework such as jQuery to perform the DOM manipulation. JS frameworks have worked out most of the cross-browser problems and abstracted away the handling of them, so that you don't have to worry about writing code to address problems in a specific browser. Here's jQuery's site: http://jquery.com/.
Now to accomplish what your example says in jQuery, you would do the following:
var option25 = $('<option>').val(25).text('25 miles');
if (rad == '25') {
option25.attr('selected', 'selected');
}
var combo = $('#ddlProximity_' + controlId);
combo.append(option25); // Will work in all browsers supported by jQuery
If you really want to do this without any JS frameworks, I would take a look here: http://www.w3schools.com/jsref/met_select_add.asp . The add method should work, but there are some caveats in IE versions prior to 8 and your page must have a proper DOCTYPE declaration. You can also try appendChild, but I would test it in a few browsers to see if that accomplishes what you need.
I have JavaScript code that listens to the "return" key pressed,
works on all browsers except webkit browsers.
I am aware of webkits recent changes to keyboard event handling.
I cant find the right solution in this detailed explanation.
Here is the code:
function addEventHandler(node,type,fn){
if(typeof window.event !== "undefined"){
/* Internet Explorer way */
node.attachEvent( "on" + type, fn );
} else {
/* FF & Other Browsers */
node.addEventListener( type, fn,false );
}
}
function detectSubmit(){
searchTextInput = document.getElementById("txtSearch")
addEventHandler(searchTextInput,"keydown",triggerSearch);
}
function triggerSearch(e){
//getting the character that was pressed cross browser.
var key = e.keycode ? e.keycode : e.which;
//detect if the return key was pressed.
if(key==13){
alert("return clicked");
}
}
addEventHandler(window,"load",detectSubmit);
The most obvious thing is the simple typo on the following line:
var key = e.keycode ? e.keycode : e.which;
It should be keyCode rather than keycode.
Other than that, there are problems in the addEventHandler function. I suggest the following:
function addEventHandler(node,type,fn){
if (typeof node.addEventListener !== "undefined"){
/* DOM-compliant method */
node.addEventListener( type, fn,false );
} else if (typeof node.attachEvent !== "undefined") {
/* IE */
node.attachEvent( "on" + type, fn );
}
}
Two things: first, it's better to check for attachEvent directly rather than infer its existence from the existence of window.event. In fact, window.event exists in Safari and Chrome but not (I think) attachEvent, so that dodgy inference is preventing your code from working.
Secondly, it's better to check for the DOM standard addEventListener first and use it where it exists rather than attachEvent. Opera, for example, has both but only addEventListener is standardised.