I've seen several threads about reading contents, but nothing on writing to noscript.
$('body').append('<noscript><div></div></noscript>');
In Chrome and IE9 I get a noscript-element with a empty div inside like I expect, but in IE7 and IE8 I just get a empty noscript-element without the div inside.
Example: http://jsfiddle.net/cEMNS/
Is there a way to add HTML inside the noscript-tag that works in all browsers? What I need is to add some tracking code into a noscript-element at the end of the page, but the info I need isn't available until after document ready.
Edit: I'm getting a lot of comments on "why". It's some poorly done tracking library that requires this. We don't have access to the code to change it. Regardless, I find it interesting that it works in some browsers and not in others since jQuery was supposed to work equally in all browsers. Is it simply a bug?
Edit2: (2 years later) Adding a noscript on the browser doesn't make sense, I know. My only excuse not the question the task I had was because of lack of sleep, like everyone else in the project. But my rationale was that jQuery should behave the same on all browsers and someone might want to do this on the server.
Regardless of the tracking code, what you are doing (or are required to do) makes no sense!
Why? There are two cases possible here:
user has JavaScript enabled in which case the NOSCRIPT get's inserted into the DOM but is ignored by the browser (does nothing)
user does not have JavaScript enabled, NOSCRIPT does not get inserted and does not "execute"
The end result of both cases is that nothing actually happens.
Just an idea: You could try giving your noscript tag an ID, and then try to use native js.
for example:
$('body').append('<noscript id="myTestNoScript"></noscript>');
document.getElementById('myTestNoScript').innerHTML = '<div></div>';
I would claim that if it does not work with native js, it will not work with any library (feel free to correct me on this one).
I tried following simple HTML code:
<html>
<body>
<noscript>I'm a noscript tag.</noscript>
</body>
</html>
Then I did analyse this with IE8 (in IE7 mode) and his integrated code insprector. Apparently the IE7 checks are script allowed. If so he declared it as empty. And empty tags will be ignored. Unfortunatly I could not try that with disabled script option, because only the Systemadministrator can change the settings (here at my work).
What I can assure you, the noscript does exists. If you add
alert($('noscript').size());
after the creation, the result will be 1.
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.)
Can I somehow load a "broken" DOM tree in JavaScript
for example if someone forget to close a tag..
The current page? ...if this is an HTML document (ie. not served as XHTML) then the browser will auto-close (and even attempt to 'fix') certain elements that may at first appear 'broken'. When reading the current DOM, you are reading the fixed version. However, if the page is in fact 'broken' (or is just not standards compliant) then different browsers will 'fix' it differently. Depending on how broken is "broken", this may or may not be OK. If you are wanting this to work cross-browser, then this is probably not OK.
Here's a sample page with a couple datepickers. Here's the Drip result for that:
alt text http://www.picvault.info/images/537090308_omoya.png
This page leaks indefinitely in IE6sp1 when I click the Refresh button repeatedly (IE6sp3+, Opera 9, Chrome2, and FF3+ seem to be good). The memory goes up and never goes down until I actually close the browser completely.
I've also tried using the latest nightly of jquery (r6414) and the latest stable UI (1.7.2) but it didn't make any difference. I've tried various things with no success (CollectGarbage, AntiLeak, others).
I'm looking for a solution other than "use a different browser!!1" as I don't have any control over that. Any help will be greatly appreciated!
Update 1: I added that button event to a loop and this is what happens (the sudden drop off is when I terminate IE):
Update 2: I filed a bug report (fingers crossed).
Update 3: This is also on the mailing list.
Update 4: This (as reported on the mailing list) doesn't work, and in fact makes things worse:
$(window).bind("unload", function() {
$('.hasDatepicker').datepicker('destroy');
$(window).unbind();
});
It's not enough to just call destroy. I'm still stranded with this one and getting very close to ripping jquery out of the project. I love it (I really do!) but if it's broken, I can't use it.
Update 5: Starting the bounty, another 550 points to one helpful individual!
Update 6: Some more testing has shown that this leak exists in IE6 and IE6sp1, but has been fixed in IE6sp2+. Now, about the answers I have so far...
So far all answers have been any one of these:
Abandon IE6sp0/sp1 users or ignore
them
Debug jquery and fix the problem myself
I can't repro the problem.
I know beggars can't be choosers, but those simply are not answers to my problem.
I cannot abandon my users. They make up 25% of the userbase. This is a custom app written for a customer, designed to work on IE6. It is not an option to abandon IE6sp0/sp1. It's not an option to tell my customers to just deal with it. It leaks so fast that after five minutes, some of the weaker machines are unusable.
Further, while I'd love to become a JS ninja so I can hunt down obscure memory leaks in jquery code (granted this is MS's fault, not jquery's), I don't see that happening either.
Finally, multiple people have reproduced the problem here and on the mailing list. If you can't repro it, you might have IE6SP2+, or you might not be refreshing enough.
Obviously this issue is very important to me (hence the 6 revisions, bounty, etc.) so I'm open to new ideas, but please keep in mind that none of those three suggestions will work for me.
Thanks to all for your consideration and insights. Please keep them coming!
Update 7: The bounty has ended and Keith's answer was auto-accepted by SO. I'm sorry that only half the points were awarded (since I didn't select the answer myself), but I'm still really stuck so I think half is fair.
I am hopeful that the jquery/jquery-ui team can fix this problem but I'm afraid that I'll have to write this off as "impossible (for now)" and stop using some or all of jquery. Thanks to everyone for your help and consideration. If someone comes along with a real solution to my problem, please post and I'll figure out some way to reward you.
I hate to say this, your approach is correct and professional, but I'd be tempted to just leave it.
The consequences of not fixing this is that IE6 users will notice their machine getting slower and slower and ultimately either crashing completely or more likely crashing IE6.
So what?
Really - why is this your problem?
Yours definitely won't be the only site they visit with this leak, and they will see IE6 crash regularly regardless of what you do, because that's what it does.
It's unlikely that anyone still on IE6 could even point out your application as one that leaks.
Finally when IE6 does crash it reports IE6 as the culprit - you can legitimately point out that this is a bug in IE6 that Microsoft have fixed in a new release.
Your expensive time is better spent on improving the application for the users not trapped in legacy hell - your app should basically work for IE6 users, but this sort of issue can suck away all of your time and not fix their problem. IE6 is still going to be an unsupported, crash ridden, security hole of a browser.
I suspect the jQuery devs take a similar view to me. Also you have to do some really ugly stuff to get round this bug in IE6, including hacky DOM work that stops the leak but is actually much slower.
Update
Ok, this isn't an easy problem to fix - MS describe the IE6 bug (and provide advice on how to fix it) here: http://msdn.microsoft.com/en-us/library/bb250448(VS.85).aspx
Basically this isn't a problem with javascript or jQuery - the actual issue is with the IE6 DOM - when HTML elements are added to the page (by javascript, rather than being in the page when it loads) IE can't garbage collect them unless they are created in a very specific way.
This is back to front from how jQuery UI builds elements (see DOM insertion order bug in the link above) and so this isn't something that either the jQuery devs or you can easily fix.
So how do you fix the issue? Well, you can stick with the legacy pop-up calendar for IE6 or you can write your own one.
I would recommend the former, but if you really want to built the latter there are some basic rules to follow:
Always add elements top-down - for instance if you want to built a table add the <table> element into the page's DOM, then add <tr> then <td> and so on. This is back to front as it's much quicker to build the entire table and then add it to the DOM - unfortunately that's where IE6 loses track of it.
Only use CSS and HTML 3.2 attributes - sounds dumb, but IE6 creates extra objects to store the extra attributes (or 'expando' properties) and these also leak.
Kinda related to (2), but as #gradbot mentions IE6 has problems garbage collecting javascript variables - if they reference a DOM element inside an event fired from that element you can get problems. This is also compounded by javascript references to DOM elements that have 'expando' properties.
If you have a look around online there may already be a drop-down DHTML calendar that sticks to these rules - it won't be as pretty, quick or configurable as the jQuery UI one, but I'm sure I've seen it done without leaking in IE6.
I think the best bet is to keep as much static as possible - for instance you could load the calendar grid (week numbers and day column headings) with the page and then dynamically load in the numbers (and nothing else). Create the day numbers as links, with javascript in the href - not best practice normally but far less likely to leak in IE6.
It's obvious that the problems you've been describing stem from a flaw in IE6 that you can't subvert with a software fix (be it a jQuery update, a manual call to CollectGarbage, or some other JavaScript/DOM hack).
There are 3 options, in my mind, that would fix this problem.
I would imagine that your customers/users are using IE6 SP0 because of some company standard or regulation, or even because some older web-app they still use doesn't support newer browsers. If it's not an option to upgrade to IE7 (or therefore IE8), you could get in contact with your customers' IT department and politely point out that updating IE6 with the latest service packs would not only fix a problem with an application that they are paying for, but also patch many security and performance flaws that undoubtedly exist in IE6 SP0. Admittedly, that might not be a comfortable situation, but it might solve the problems you are encountering, while still allowing them to work with a browser that require for whatever reason.
If you can convince your customers' IT department that IE6 is antiquated, they may be willing to allow your users to upgrade to a newer browser. It's not a stretch to say that someone running an IT department would be more willing to force employees to upgrade a piece of software if they knew it was either a) riddled with flaws and security holes or b) approaching its end of support date (as IE6 SP0 is). IE6 SP0 on XP Pro SP2 is supported until July 13, 2010 - so it still has some time, but pointing that out, along with other flaws/limitations you could find might make them think seriously about upgrading sooner rather than later.
If you can't convince anyone to upgrade their browsers either to IE6 SPX, or to IE7/8, then I don't know if you have a choice but to remove the offending control from your page, and pursue a different option until the user's browser permits it. There are assuredly many implementations of a date picker control available online which would suit your needs. It might not be as snazzy as the jQuery version, but you don't have many other options at this point.
I hope you find a solution!
try deleting these objects after destroying the datepicker object:
$.datepicker = null;
$.fn.datepicker = null;
This problem is either in a IE6-only part of jQuery, or in a general part of jQuery that is lacking IE6 especific code (as noted in the comments). Either way, it's still a bug in jQuery that needs addressing.
about:blank
You'll either have to dig yourself into jQuery or file a bug ticket. If you manage to fix it, don't forget to attach a diff to the bugtracker, so the project gets a little bit better. ;)
If I get some spare time, I'll try to help you with this.
Edit
Ok, so the problem seems unsurmountable.
The leak you are facing is an IE 6 SP 0 only problem, a leak caused by IE's approach to DOM. Doesn't matter what JS framework you use, it refuses to work correctly.
So, your current options are:
Die trying to get your users to upgrade IE 6 to a newer version/Service Pack,
Die (as in leak) in IE (loosing customers) or
Die trying to work on IE.
But that doesn't necesarily means you can't work this out. What about just trying to side pass the wole thing?
Show every non IE 6 SP 0 user the jQuery datepicker, and only IE 6 SP 0 another more resilient (and probably basic) datepicker with IE's conditional comments. This way you can keep the eye candy/functionality in your software, and allow IE 6 users to have the same basic functionality.
It might not be such a clean option, but you'd still be able to use what you want, and IE6 will still be able to work without leaking.
The only problem will be that you'll have a bigger burden, by having to degug two distinct datepickers. But you'll have to debug IE 6 anyway so, it may be your best bet at the moment.
The problem with IE 6 is that it has two garbage collectors. One for JavaScript and one for the DOM. So for example if you attach a function to a DOM event and then delete the DOM element the function will still exist in memory.
Check out this slide show. It's a bit tongue in cheek but it's good information.
They fixed this issue in IE 7. I tried your page in IE8 in windows 7 and I'm not seeing a memory leak.
The problem here lies a bit deeper than 'just' jquery. Jquery along with many other browsers "leak" circular references between DOM objects and object listeners. Say you have an input field that has attached to it a listener, then you remove the element from the dom and do not have any reference to the listener in your code. Now any modern browser (>=ie7, ff, chrome, safari, opera) will live with that and garbage collect it, while IE6 will think that because there is a listener attached to a dom element it should not garbage collect the dom and the listener itself.
To get around that some folks use very complicated design patterns as highlighted for example in events code in Google Doctype. To fix the problem for IE6 you would really need to rewrite a portion of jquery to work around IE6 issue and/or switch to using a different library and/or not attach any event listeners in your application to DOM events.
Can you try this demo here. It uses the same method as dojo implements to remove elements from the dom. Some quick testing it seems to ease the leaks, not fully but much better.
UPDATE After spending a little time on this I am convinced it is nothing to do with the datepicker itself.
My tests show that by just reloading a dummy page every 1 second sees ie leaking memory.
If you then include jquery on this page the leaks increase slightly (overhead of parsing the script) If you then add jquery-ui into the mix then again there is another slight increase in memory leakage.
To prove this if you avoid reloading the page and instead have a button that just adds an input, creates the datepicker on it then removes it, you see very little if any leaks.
Take a look at this snippet that cleans up DOM nodes. You may find it useful. https://stackoverflow.com/a/9519996/139667
The best debugger available for IE6 is Visual Studio. (Even the free edition will work.) As Janie mentions, if your problem is only happening on IE6 you'll want to debug on IE6, paying special attention to code that only runs there.
I'm hoping some Javascript/ASP.Net gurus can give me some hints here.
I've written an application which (unfortunately) uses UpdatePanel (yes, I'm aware that was a dumb idea, too late now though, I understand it more now - even though its an intranet site I'm having troubles with it)
The site is a web based timesheet site, kind of tabular format. Anyhow, it basically saves everything in it in an update panel, and autosaves once a minute. This seems to work fine for me, but I use firefox. Other users with more timesheet entries, and IE7 have problems with IE memory usage increasing and their browser slowing down.
I ran Sieve (checks for memory leaks on a website) and it was pretty obvious it was bad:
alt text http://rodh.org/images/Programming/sievemain.png
Thats my site loaded up and left running for a bit, refreshed it at the dip and left it and you can see once a minute it jumps up a little bit. THe area on the timeline before the dip was when i was hitting the save button a bit, so its obvious what is causing it. The DOM nodes and memory both go up.
I'm using a ScriptManager.RegisterClientScriptBlock's (mainly to get the clientID's of controls so I can do javascript totals) and also a ScriptManager.RegisterStartupScript on page_load to get set the focus to be the same after a partial postback. Maybe they are contributing?
Is there any tools that can help me out further to this? Sieve reported alot of empty divs being made when the postback occurs? bit I've never used sieve before so maybe this always happens?
alt text http://rodh.org/images/Programming/sievnodes.png
Is there some sort of code analysis I can do, or something that at least lets me see the new DOM nodes created each time...
I'm thinking hte problem might be to do with my code behind hackery to get the client id's, it stores them in an array, and then recreates taht array on each postback, perhaps something is going wrong there?
I've uploaded my JS file which does that hackery, and also the code behind in case anyone needs more info.
http://rodh.org/images/Programming/javascript.txt
http://rodh.org/images/Programming/codebehind.txt
So I guess my question is:
- Can anyone think of anything immediately that would be causing this?
- what are some common causes of increased DOM usage on UpdatePanels (using Jquery too btw)
- what tools can I use to debug?
I can tell you first hand Microsoft knows about the IE problem(KB 2000262) with UpdatePanels. Its a DOM parser issue. I had a site that ran fine up until a certain page content size and then IE(all versions) had a fit. FF and other browsers handled the same pages with ease.
Things I did to make my pages faster:
Use UpdateMode=Conditional wherever possible
Implement the KB 2000262 fix
UpdatePanel Async Postsback slow in IE…Part 3