I'm writing a script which leverages keypresses, and I have need of detecting whether or not the user is in insert mode or overwrite mode.
Fortunately overwrite mode is not a thing in Firefox, Chrome, or Safari, but it is in Edge.
I've done copious amounts of searching and the only applicable code I have found is:
document.queryCommandValue("OverWrite");
However this seems to have gone unsupported since IE11 from what I can gather. In Edge it returns an empty string regardless of whether or not you are in insert mode.
I've tried using document.queryCommandState('OverWrite'); instead, however likewise it always returns false.
Is anyone aware of the new way to test for this, assuming it is a thing that is possible to test for?
I try to test it with MS Edge and I am able to produce the issue. It can be possible that it is some kind of bug or the Edge team needs to add the support of the API. I will try to submit the feedback regarding this issue.
As a workaround, you could refer to this answer. You could use the jsfiddle demo in the answer to detect the overwrite mode in Edge. But the draw back of the function is when you add characters at the end of the inputs, the mode detect will not work.
Related
Need an intervention here, as I am pretty much losing my mind on this 0_o
I am using IE 9 and am using IE's F12 developer tools, trying to test for IE8.
I am performing a pretty simple task with JavaScript.
I am grabbing some inner html - using it as a sting for whatever reason.
Like this:
<div id="Some_Container_div">
<div class="Some_Inner_Div_Class">sometext</div>
<div class="Some_Inner_Div_Class">sometext</div>
<div class="Some_Inner_Div_Class">sometext</div>
</div>
<script>
var Div_Contaiers_Inner_Html_As_String = document.getElementById('Some_Container_div').innerHTML;
alert(Div_Contaiers_Inner_Html_As_String);
Array_Of_Divs = Div_Contaiers_Inner_Html_As_String.split("</div>");
alert(Array_Of_Divs);
</script>
The above code properly alerts:
First:
<div class="Some_Inner_Div_Class">sometext</div><div class="Some_Inner_Div_Class">sometext</div><div class="Some_Inner_Div_Class">sometext</div>
Then the second alerts the proper array:
<div class="Some_Inner_Div_Class">sometext,<div class="Some_Inner_Div_Class">sometext,<div class="Some_Inner_Div_Class">sometext,
If I now use the developer tools (f12) and switch to "Browser Mode" IE8 and I switch the "Document Mode" also to IE8 the browser now alerts :
First:
<DIV class=Some_Inner_Div_Class>sometext</DIV><DIV class=Some_Inner_Div_Class>sometext</DIV><DIV class=Some_Inner_Div_Class>sometext</DIV>
Notice the missing quotes now?
Notice the capitalization of the words 'DIV' now?
And next it alerts the same thing:
<DIV class=Some_Inner_Div_Class>sometext</DIV><DIV class=Some_Inner_Div_Class>sometext</DIV><DIV class=Some_Inner_Div_Class>sometext</DIV>
So it looks like it is not even splitting the string into an array now - not sure why, like it was not a string anymore.
If I now use the developer tools (f12) and keep "Browser Mode" IE8 and I switch the "Document Mode" also to IE9 - it works fine again....
So thanks so much for confusing me again Bill Gates 0_O
Anyway - so I looked through here for help - I see some people saying you should switch both "Browser Mode" to IE8 and "Document Mode" also to IE8 when testing with developer tools - but I do not see an explanation I understand as to why. and what is the difference if you switch just one or both.
In the mean time:
Can anyone tell me if this is going to work properly in IE8?
Why it is stripping the quotes out?
Why is it not creating the array in developer tools testing mode?
Thanks to all : )
Short answer:
It's a compatibility issue. The JScript 5 engine (IE7/IE8) was severely flawed, and this is one of the things it does (stripping the "s from attributes and altering capitalization when generating an innerHTML string). As well, because innerHTML screws with capitalization, it's trying to match your .split("</div>"); against a string containing </DIV> and failing.
Try using .split(/<\/div>/i); instead. This won't solve the loss of "s from your attributes, but it's a partial fix. See this answer for a function that appears to fix missing quotes and capitalization if the quotes are necessary.
In the larger issue of how to test against older versions of IE:
In essence, the Browser Mode doesn't do anything to how Internet Explorer renders the page1. Browser mode influences how IE acquires the page, changing the UserAgent sent to the server.
Document Mode changes which version of the Trident rendering engine, and whether the IE9 Chakra Javascript engine or the IE8/IE7 variants of the JScript engine are used.
TL;DR, for testing purposes you should change the Browser Mode to IE8, then observe whether the Document Mode defaults to IE8 Standards or Quirks. If the code is not working, toggle between the two. If the code then works, make sure you're setting an appropriate DOCTYPE for whichever mode works (Transitional for Quirks mode, Strict for Standards mode).
[1] Browser Mode also influences how the browser interprets conditional comments, and the default Document Mode (makes it match the Browser Mode), so changing only this is a good way of figuring out how IE8 will interpret the page... but this behavior breaks quickly if you have X-UA-Compatible Meta tags, so if you're using those, just set Document Mode to match.
It's a pity but "IE8 Browser Mode" and IE8 are realy different things :/
I think that this code will work fine in IE8.
By the way, you can use free IETester tool, that is much better then "browser modes".
According to this website calling removeChild() in JavaScript causes an Internet Explorer Specific leak called a pseudo-leak.
Sometimes Internet Explorer keeps items in memory after the page is done using them. Although these pseudo-leaks are freed after the user leaves the page, some web pages may be open for long periods of time. To avoid pseudo-leaks, do not use removeChild to remove elements. Instead, set the parent's innerHTML to ""
Does deleteCell() cause pseudo-leaks the same way that removeChild() does?
Edit: I was able to reproduce this error on IE8. Believe it or not, Microsoft claims to have fixed this problem in IE7.
I don't have the benefit of being able to look at IE's source code and confirm, but I imagine if it's anything like how Chrome implements deleteCell, it uses removeChild internally, which could trigger IE's pseudo leak. I know older versions of IE had this issue, but I'm not sure if the current versions do.
From chromium source:
void HTMLTableRowElement::deleteCell(int index, ExceptionCode& ec)
{
...
HTMLElement::removeChild(cell.get(), ec);
}
I have the following:
Test
When run in Chrome, it functions as expected and turns the page red. However, in Opera I get:
[object Object]
Closer inspection reveals that Opera thinks that javascript:Query('body')... is some kind of URL. What am I doing wrong? Doesn't Opera recognize javascript: links in the href attribute?
jsFiddle: http://jsfiddle.net/9CZZL/
Edit: seems to be a Firefox problem too...
The issue is that the return value of jQuery('body').css('backgroundColor','red') is an object, which some browsers interpret as the new content for the web page. To fix this, you can use the JavaScript void operator to turn it into undefined, which FF and Opera (and potentially others) will handle as you intended. You will notice that this issue is also described on that page, since it's the premier use-case of the void operator (other than code golf where void 0 is less characters than undefined).
Test
This should give the intended result: http://jsfiddle.net/9CZZL/13/
It should be noted that handling clicks this way is considered bad practice. Instead, using event handlers in JavaScript is recommended. This helps separate the different layers of your web app, which in turn will make debugging in the future easier.
I just did a google search and no, apparently Opera does not recognise "javascript:" href values. You would have to implement an onClick or similar solution.
Does it in Firefox too.... not quite sure why. But I never liked putting JavaScript right in the URL... you could try putting it in the onclick event or pull the whole thing out and separate it:
http://jsfiddle.net/mnbayazit/6d5An/
These all work as href values for me in Opera 10.1:
javascript:void(0)
javascript:alert("Hello")
javascript:window.location.href = 'http://www.google.com'
Your snippet does not though.
A viable work around is:
Test
Or even:
Test
...since that seems to work.
Apologies but this is not a programming question, but it may have a programming answer.
For some reason my site, http://pctools.alwinsights.com will not display properly in IE (I'm using version 8) but it's fine in firefox and chrome. The content does not appear in the centre of the screen in IE and also generates two JS error messages while the pages are loading.
I've tried enabling Active X and Scripts in the security settings but with no joy. I've also looked around the net but cannot find an answer, well not one that works!
Unfortunately I know nothing about javascript so really don't know where to start with the error messages that are generated.
Any help appreciated.
regards
Nigel
Update:
OK initial error has gone, I'd screwed up with a directory name - apologies.
I've found out that if I disable the option to display the last twitter feed in the wordpress theme it loads OK. So it is the JS code in a php script called thememx-document.js that is causing the error. The code generating the error is "var twitterHtml = jQuery.cookie(twitterCookieName);" It says it's charcater 4, which is a space but I don't understand this.
I can live without Twitter on this site but it still leaves issues as to why content isn't centred nor the pop-up ad is not showing (compare to Firefox) but this may not be a programming issue that warrants a question on this site.
Thanks to all for your comments and input.
Nigel
Start with valid code; a validator will pick up lots of problems. Among yours is content before the Doctype, which triggers quirks mode. Quirks mode causes browsers to emulate bugs in ancient browsers and become much more inconsistent with each other. One of the emulated bugs in Internet Explorer breaks standard centring techniques.
for not properly disply-- its the problem of CSS ...IE7 and IE8 dosen't support css3.so you should simply make another css stylesheet for IE and call it on page only if someone visit your site using IE. and for other broswers it will show exiting style.
and abot JS error --you should check all your php coding and then fix it. its not JS problem. if you are not familar with PHP coding then i am here to offer my free service to you or anyone else. i will help you as i can.
First, having problems with any version of IE is expected and the norm. IE is the worst browser on the planet.
You have a link element on your first line. Links belong inside the head element. Placing it on the first line throws IE into 'quirks mode' and then IE becomes even worse than it normally is.
Good.
OK, maybe your site has to work for IE. 9 times out of 10, the problem is a terminal comma. The following is understood in real browsers but generates an unintelligible error in IE:
var x = [ 1, 2, 3, ];
The tenth time (in my experience), it's string indexing.
var x = "abc";
var c = x[2];
In a real browser, c is set to "c"; in IE, another unhelpful error message.
If this helps, remember: in IE, it's very important to create as many circular dependencies as possible. That is, attach to DOM elements JavaScript functions that have references to other DOM elements. IE fails to clean up such dependencies when the user leaves your site and so leaks memory. Once it leaks enough memory, IE slows and eventually freezes the OS and the user learns a valuable lesson: don't use IE. (Microsoft has a good page explaining how to do this although, inexplicably, they recommend against doing it.)
Our site makes use of FreeTextBox, a web-based, rich-text editor. In IE, but in not Firefox, if a user types in something like:
someone#blah
IE automatically creates a mailto hyperlink. I have tested this with other text editors out there and the story is the same with all of them.
Can I override this browser behavior somehow from within my application?
This has to do with the MSHTML editor, which (I'm guessing all) Windows browsers use to instantiate rich text editors. There's a setting called IDM_AUTOURLDETECT_MODE that lets you decide if the autolinking will take place, and the default is true (other browsers apparently set it to false on instantiation, hence no autolinking in Firefox.)
Unfortunately, until recently Microsoft didn't have a mapping from the command ID to a command identifier string, so the function wasn't accessible via Javascript prior to IE9.
I just tried it out in IE9 and can confirm that, for that version and presumably all future ones, you can override the feature by calling
document.execCommand("AutoUrlDetect", false, false);
Note that it's IE9+ only, so you're still stuck for previous versions, and that you'll want to wait until the DOM is loaded before you call it and have some error handling around it, etc, etc.
There's a good summary of the original issue here, and a discussion of the fix in the minor change list here.