I'm writing a unit test that uses getComputedTextLength() and test passes in all browsers except IE (i'm using IE10).
Any ideas?
This is the error im getting: Unexpected call to method or property access.
You could fallback to calling getBBox() and look at the width field of the result for IE10. It isn't quite the same but it's better than nothing I guess.
This occurs when the element is not in the visible DOM. You can do a check before hand to avoid having to use try/catch.
if(!document.body.contains(self.node())) return;
In my limited investigations it seems IE11 (so I assume IE10) throws this error when the actual element is not visible. To get around this problem I did
var a;
try{
a=textElement_.getComputedTextLength();
}catch(e){
a=textElement_.childNodes[0].length*8; //I used 8 as a width, but you should experiment
}
I hope this helps. Once the element is visible it seems to use getComputedTextLength normally.
If you call "el.getSubStringLength()" in a SVG in an iframe. Then you refresh this iframe, IE will also complain about this, but refreshing the whole page will work just fine.
I guess this was because the text element is already in the DOM, and there is a bug between these update worker.
Related
I am writing to an iframe via document.write then trying to overwrite the document on that same iframe. In FF this works properly. However, in chrome code from the initial document.write persists even after I overwrite it with a second document.write.
See this fiddle: http://jsfiddle.net/meQcC/
If you view it in FF as one would expect, the iframe is blank and you actually get a "function onLoad is not defined error" because in the line
doc.write("<html><head><script>;" +
"<\/script></head><body onload='onLoad()'></body></html>");
There is obviously no onLoad function defined. However, if you view the same fiddle in chrome, the iframe will display a black rectangle, and there will be no error regarding the onLoad call, it will call the previously defined function as though it still exists!!!!
Is there any way to clear the document in chrome so that I can overwrite the contents of the iframe without old code somehow persisting? Is this a bug in chrome?
Yes, this is a bug in Chrome (or more precisely in WebKit). Per spec, it should be creating a new Window object and removing all global event listeners, and it's not doing that.
In particular, see http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#dom-document-open step 14.
Deleting a <script> does not undefine any functions it defined.
If you want to achieve that you need to keep a list of all globals you create and delete them using delete window.WHATEVER;
I recently launched a website for a client http://www.bridgechurch.us/ only to recieve complaints of it not displaying correctly on ie8 or ie9. I have confirmed this to be true. IE is pointing to this line of Javascript:
jQuery(function () {
jQuery(".scrollable").scrollable({circular: true}).navigator().autoscroll({interval: 7000});
[...]
Can anyone help me figure out what is wrong with this line of code?
Thank you
UPDATE - FIXED
I figured out that there was a comment before the Doctype Declaration that forced IE into quirks mode.
You have a lot of 404's on that page, mainly related to ie-specific css and border images, which is probably why the page doesn't look like it should. Files like /images/internet_explorer/borderBottomRight.png and /wp-content/themes/Moses/styles/default.css aren't loading.
That being said, looking at the scrollable documentation, there is no .navigator() function off of the return value of scrollable(); and I'm getting the same error in Chrome.
Well, visually, the site doesn't appear to work well at all in IE9 (compared to Chrome). But just looking at the code that adds scrollable() to jQuery, you can see that that function doesn't always return the original element. In your code, if you split the call into two, you might be ok:
jQuery(".scrollable").scrollable({circular: true});
jQuery(".scrollable").navigator().autoscroll({interval: 7000});
I blame the plug-in on this one: functions that extend jQuery are supposed to always return the original elements found by the selector.
The following piece of code, works correctly in Firefox and Chrome, but it gives me a headache in IE.
var anotherDiv= document.getElementById("anotherDiv");
var destination = document.getElementById("mySourceDiv");
destination.appendChild(anotherDiv);
I'm trying to get a Div element and place it inside another div.
I get an error message (in the debug console in IE) similar to "interface not supported", and points me to the appendChild line.
What I've seen is that the type of the destination variable is an object rather then a DOM element.
What can I do to append the anotherDiv to mySourceDiv?
I'm trying this in IE 8.
You probably will need something like an importNode, there are various cross browser solutions around. The issue is that each node has a corresponding document object on it, in IE and so called security doesn't play nice moving things from one document to another.
So, essentially it's doing a deep clone, but the difference between using cloneNode is that cloneNode also sets the document which you don't want.
This might get you going in the right direction:
IE support for DOM importNode
I'd recommend using a library designed to sort through the browser incompatibilities for you. I've personally found jQuery to be quite good. jQuery has an append function.
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.
Can any one give me a scripts (HTML/CSS/Javascript) that can reproduce this error on IE 7.0? I am trying to fix this bug in my page where I get this warning but could not exactly found the problem. Line number does not match with the source either.
I thought the better approach would be to create a bug and then work on it incrementally rather than making some wild guess!
As Shog said, that error will occur when you try to call a method on an object which doesn't have that method.
This is most often caused by an object being null when you expect it to, well, not be null.
var myEl = document.getElementById('myElement');
myEl.appendChild(...)
The above example will cause that error if the "#myElement" element doesn't exist.
If it's only happening on IE and not Firefox, chances are it's because you're using a method which IE doesn't support.
The solution? You can try the Script Debugger, but I've never found that to be useful myself. The most reliable, yet painfully slow method is alert() debugging. At strategic points through your code, put in an alert with a unique message. At some point IE will throw an error, so you'll know that the error is somewhere between the last alert which you saw, and the next one which didn't.
function myFunc() {
alert('a');
var myEl = document.getElementById('myElement');
myEl.appendChild(something);
alert('b');
// more code
}
if you ran that and you saw 'a' but not 'b' you know it's in between there somewhere. This is just the sad state of javascript in IE, I'm afraid.
If you make your code follow the jslint.com rules, it will go away.
It will also point you at exactly where the issue is in your code.
I thought the better approach would be
to create a bug and then work on it
incrementally rather than making some
wild guess!
You would be wrong. There are countless scenarios that could produce the error you are seeing. All it means is that you're trying to call an undefined method. For instance:
var blah = {};
blah.methodWhichDoesntExist(); // <-- error
This could be the result of a typo, an undetected failure in some other component, or gamma rays consistently flipping bits in your HTML right after you save. Hard to be any more specific without knowing more about what you're doing.
For IE, download the Microsoft Script Debugger
I just fixed a similar bug by using IE8 and switching it into IE7 mode. You then get a more specific error message telling you which line of which file is failing.
After that set a breakpoint so that the code stops just before the offending line (F12 to get to debugger tools, then choose the JS file you want from the 'scripts' dropdown and click to the left of the line number. Click 'start debugging' to make it use the breakpoints).
As others have pointed out, this error could have many causes, but in my case, I had two IDs on the same page with one capitalised and one not. getElementById() was getting the wrong one. Only IE7 complained.