Suddenly I’m experiencing something strange with document.getElementsByClassName in my website.
Here is what happened:
I am running an aspx website on IIS7.0 where some parts of my JavaScript code uses document.getElementsByClassName.
I never experienced any problems with this on Firefox, Chrome or IE8+
Today, I’m migrating my website to a new server, which runs IIS7.0 as well.
I copied my website, and suddenly document.getElementsByClassName is not recognized any more by IE8+ (it works normally in Chrome and Firefox though...)
I know there is a workaround for this issue described here: javascript document.getElementsByClassName compatibility with IE but that is not the question.
My question is: how is it possible that document.getElementsByClassName no longer works, while I just copied my website?
Is their something to be changed on the new server, IIS, … ?
Many thanks,
The major change to this working app is the change of server. I'm
pretty sure my comment above is a much more likely cause for the issue
than Joseph's prediction of coding mistakes. Sudhansu gave a good
suggestion as to the reason Compatibility Mode is being changed, but
ultimately, that's the thing you have to check. Read my earlier
comment.
– Katana314
Already suggested in comments, but to wrap up as answer:
If a working IE11 site suddenly stops working on another server, and the connection string's structure has changed in some way, the most likely cause is that IE11 believes it's viewing an old intranet site, and pessimistically uses IE7 mode for maximum compatibility. A few other things can cause this, like having an unreadable or old <!DOCTYPE at the beginning of the page.
You can change IE11's default compatibility settings to fix the issue locally, use a fully-qualified domain name, or there are some <meta> tags or HTTP response headers you can add to change IE's default behavior. Microsoft would likely have more informative articles on their own site.
Related
On http://www.dutchsupercross.nl/inschrijven I implemented a captcha at the bottom. But does not seem to work in Internet Explorer.
It also looks like that IE does not like to load HTTPS because i do not see that this file is loaded in the developer tools (Network) When i change it to HTTP it seems to load the javascript but still nothing shows up.
Any ideas are welcome
I checked the website in my Chrome, Mozilla, IE, and Yandex browsers and it worked pretty well. Sometimes the browsers have something about the compatibility.
There is a good documentation in google's recaptcha website. Check the following link and apply the steps under the section "reCAPTCHA isn't displaying properly on Internet Explorer, what do I do?"
The link is: Google reCAPTCHA website
I can't find nearest possible issue,
I don't rely much on dealing browser specific without encourage the user to update their browser.
Since the implication may not only issue like this.
Based on SO question,
we won't and we can't agreed all of that. Which if we decide support IE we should drop IE older than 11 now on.
Which also proper and diligent decision that you take, base on microsoft official documentation
Which i want to highlight is when we decide browser support we also should take care of the browser ecosystem.
That you probably can upgrade the jquery version from 2.1.0 to 2.1.4 which from semantic versioning it's just the patch, that hopefully doesn't break your code.
But futhermore you should include upgrade the minor patch to your working schedule which suit your need and priority.
Frankly i can't find the glance on the change log, so i can't guarantee that this work.
But personally this is better than repetition same debugging process that the result is uncertain.
Action step:
Make sure follow installation recapcha properly.
Which display mode you choose to display the widget ?
Its also have different behaviour.
Recaptcha doc already notice that automatic render is the easiest way. Use this if you don't, but more importantly change this display mode if this
can fix your issue.
It possible jquery bug, but be aware directing it. (Possibilities unreported, not yet fixed, fixed on certain version).
3 Most possible nearest bug for me 1764, 3041 since it will render through iframe
Fixed on certain version :
Work on your code with jQuery changelog
Work on your code, while upgrading it. (have draw back on it's own).
Not yet Fixed.
seek out on jquery issue
seek out on bug
Issue and Bug are differs.
Follow framework or lib specific for re
Unreported and Untracked
It's a bit hard to recaptcha since
I've created a page which utilizes dynamic page loading with JS, it works fine in Safari, FF and Chrome - But of course the infamous Internet Explorer isn't doing a good job.
(I know there are other issues on this page, under the "Cykler" section, these aren't important for this question and shouldn't be focused at)
http://soegaardcykler.dk/beta
Try clicking on one of the categories, Cykler, Info and so on.
The strange thing is that if I open developer tools in IE and set the mode to IE8 and back to IE9 there is no issue, it switches pages like any of the other browsers.
If I close and open IE again the issue is back - If I go to the console to check what's going on it asks me to refresh the page - When I do this the issue is gone again.
I have no idea what the heck is going on, two of my friends have tested as well and they both have the issue when coming to the page for the first time.
I notice you're logging to a console. That's problematic in IE. The console object only shows up if the console is actually open (I think).
There are several solutions out there to avoid console issues; I can't recommend a best practice though besides creating your own logger object (which isn't a bad idea anyway).
Just a side node: I don't know if you're using a Windows operating system, but if you're familiar with the Fiddler2 HTTP traffic analyzer, you can search through sessions really easily. That's how I found the file you missed.
One last edit: here's a good related post: What's the correct way to write to the script console (console.log) in IE?
Ok so I'm having some strange issue with an mvc 3 site using javascript / jquery
hosted locally in IIS 7.5.
When I open the site through http://localhost/..... the site works perfectly in IE 9 and firefox,
when I use http://computername/..... the site doesn't work in IE. It does still work in firefox.
Looking to the script console using F12 and computername I see the following error:
SCRIPT1028: Expected identifier, string or number
When I use localhost this error doesn't popup.
I've tried adding the site to the trusted sites in IE, this doesn't make a change.
Also I've used fiddler which shows all the needed javascript files are loaded correctly.
How can it be the difference in url obviously alters the way the javascript is interpreted?
What am I missing here?
Actually, the problem probably IS the trailing comma:
One of the reasons may be that the document on computername loads the site in "Compatibility View". The trailing comma causes syntax error in IE7 document mode. Not other versions.
Check for extra commas!
Ok so I solved it,
apparently it has something to do with the compatibility mode in IE,
it automatically seems to go into IE7 mode for non-localhost domains.
adding this tag to the head of the page solved the issue:
meta http-equiv="X-UA-Compatible" content="IE=9"
The next post describes a similar issue and how to solve it:
https://serverfault.com/questions/142721/iis-displaying-page-differently-when-localhost-is-used-in-url-vs-hostname
this article from the msdn specifies it:
http://msdn.microsoft.com/en-us/library/cc288325%28VS.85%29.aspx
Why some javascript error only comes in IE not in firefox? should i solve all IE javascript errors, if my site is working fine with it ?
You should definitely seek to fix any JS errors you are getting in IE. What shows up in your IE as a little yellow icon, will show up in other IE browsers as a popup letting the user know there was an error.
One way you can minimize problems is by using one of the many JavaScript framework/libraries like jQuery, MooTools, etc that seek to minimize browser differences. Then, when you get specific errors, they can often be fixed by added a missing ; or adding an if statement in the correct place.
You should never knowingly leave code unfixed that is known to break in modern browsers.
should i solve all IE javascript
errors, if my site is working fine
with it ?
I'd say, yes absolutely. Under certain circumstances, IE throws Javascript errors right into the user's face with a big fat dialog. I think it's very embarrassing for a visitor (who may not even know what JS is, and even less the intricacies of cross-browser scripting) to get a error message as their first impression of you.
they have slightly different implementations of javascript, dom, css, etc.... should you fix the errors? if no major functionality is impacted, then it would probably be a very low priority... and depending on your userbase (say its a corporate intranet) you could simply say Firefox is your preferred browser. all depends on the requirements. Prioritizing tasks will help ensure the most important objectives are met.
Yes, you should fix the Javascript errors being reported in IE, because it can be unclear how the errors manifest themselves in your application. For instance, it can cause menu navigation to not work, or incorrect behavior of buttons.
As for actually detecting where the problem came from and how to fix it, you can try our Browsera service, which will detect and log the Javascript errors for you that occur in the browser, and use the Script Editor, which comes with MS Office
Or, if you dont have OFfice, use the free Microsoft Script Debugger, which works, but is less powerful.
if you are working with ajax than you can use $.getJason using jQuery, instead you get data from ajax and then use JSON.parse();
I have un-installed and re-installed IE8 a few time and javascript will not run.
I have checked jQuery and numerous sites, and run simple examples like alert("hi"); nothing works. The ie8 developer tools under script debugging says
"Breakpoint cannot be set in this location, the code in the document is not loaded"
This also happens when using the Spoon plugin and IE7 Or IE8.
also any of these scripts work just fine in firefox.
Any ideas or help is much appreciated!
Go to Internet Options, Security, Custom Level, and enable Active Scripting under Scripting.
OS: WinXp service pack2
issue in IE7 and IE8
I had spent alot of time today, uninstalling and reinstalling IE v 7 & 8. I had checked the security settings multiple times. Even disabled my firewall, nothing worked. eventually a friend of mine found the clue.
Apparently IE7 & IE8 use the same javascript registered DLL which had become un-registered for whatever reason.
To fix it:
Start > Run...
In the Run box, type in (without quotes) "regsvr32 jscript.dll"
You should receive a popup says that it registration succeeded.
I had the same problem, but the issue for me was the way I defined my block of script. I used type="application/javascript". This is supposed to be the correct way to do it, but IE only wants text/javascript.
IE -> Tools -> Internet Options -> Advanced -> Disable script debugging (uncheck)
ensure tag ends with > instead of />
None of the above worked for me,
Reserved keyword
It was blocked because I tried to invoke my custom export function from my custom object. The 'export' keyword seemed to be reserved in IE.
Chrome works fine comme toujours.
In my case the problem was that IE8, doesn't support Object.defineProperty, which lead to all JavaScript not working.
I found out about that problem, when I started debugging JavaScript in IE8 and got the error Object doesn't support this action.
This helped me, apparently IE doesn't always load script when running from local drive. I had to add a "Mark of the Web".
<!DOCTYPE html>
<!-- saved from url=(0021)http://www.google.com -->
<html>
for my case which was in IE11 in windows server 2008 R2
at first my site was recognized as internet zone which IE Security Level bar was configured high and not normal.
but adding my site simply to Trusted Sites which have low security via Internet options - Security tab - resolved the problem.
Looks like there can be multiple causes for the same symptom. For me it turned out to be the ActiveX controls/active content was blocked (I'm developing on local and had forgotten that IE likes to make things nice and secure from local).
Side note: With IE9 (I just upgraded) they moved the 'yellow bar' to the bottom and I was failing to notice it. MS is missing more than hitting lately on their UX/UI design
(see for example the ribbon interface visual overload http://www.appleinsider.com/articles/10/03/29/new_office_11_for_mac_sports_dense_ribbons_of_buttons.html)
I tried
regsvr32 jscript.dll, but it didn't work.
Then I tried
regsvr32 C:\Windows\System32\jscript.dll
regsvr32 C:\Windows\SysWOW64\jscript.dll
And it works!
In my case, the JavaScript key const lead to an error that stop JavaScript execution. The key word is not support in the IE 10(and early version). See this for more infomation.