Develop Reference

How to navigate to a different website with tampermonkey

A while ago reddit changed their notification system to be worse. However the old, better version is still accessible through /message/inbox. I wanted to create a tampermonkey script, that allowed me to use the old version, without manually having to switch to it. I managed to make this:
var $ = window.jQuery;
function changeLink(){
if(window.location.href=='https://www.reddit.com/notifications'){window.location.assign('https://www.reddit.com/message/inbox');}
}
$(document).click(function()
{
setTimeout(changeLink,1);
});
Which does work, but is extremely inelegant, and obviously leads to the page being a bit slower to load, because it needs to go to the wrong page first, before then switching to the right one. Ideally it wouldn't even go the wrong one in the first place. Is there any way to accomplish this?

How to find a rare bug?

My application contains a bug, which makes script run infinitelly long. When I force script to stop, all jQuery UI elements don't answer to my actions, nor application answers to keypresses.
If I choose to open Firebug, it requires reloading page and all current application state is lost.
The thing is I can't reproduce this bug and it's kinda driving me crazy. How to find and fix such slick bug?
UPDATE. Thanks all of you for the advice. But the problem is that I can't figure out when bug happens and, hence, can't reproduce it. That's why standard procedures won't work in my case.
I have examined every while loop and recursive function calls, but haven't figured out the problem yet.
Publishing the code isn't a good idea — code listing is huge and rather complicated (a game).
POSSIBLE SOLUTION. I'll follow one of the published hints and will try to consolelog all functions that might be causing the problem. Hope it helps.

There are two main approaches for dealing with this:
Set break points and step through your code
Start commenting out certain sections of code. Once you comment out a section that eliminates the bug, start commenting out smaller pieces of that section until you arrive at the line of code that is causing the issue.
It might also help to know what you are looking for. An infinitely running script will generally result from one of two things:
A loop that never terminates.
A function that calls itself
Keeping an eye out for these things might help the debugging process go a bit more quickly. Good luck!

break your code into chunks and determine which one causes failure. like for example, if you have a form with several fields that have date-pickers and auto-completes, take them apart one by one. zero-in on who causes it.
use the debugger timeline. cruise around your site with the timeline recording your page performance. you will see in the timeline which task it taking too long. the browser may crash when you find the bug, but you will at least see a glimpse of what happened when.
try to recreate your actions. do some step-by-step checklist on how you navigate through. this way, you can trace in the code the possible path your script took when you did your move. if only JS had a back-trace like PHP, this would be easier.
try to review your code. things like loops, recursions or even two functions calling each other can cause this never-ending loop.
if you could, use a VCS tool like SVN or GIT. you can easily build n' break your code without the worry of losing a working version. you can revert easily if you use VCS.

Infinite long time, means,
I think some function is getting called recursively or some event is getting fired recursively. To track it down,
Try to put console.log in all the functions, which are getting called from window.onload or document.ready (if you are using jquery).
Use Firebug's profile, which will tell you every function call that is happening.

I always look for functions that might be being called too often or loops that never stop looping. Then, keep track of how many times your suspected functions/loops execute. Example:
var runCount = 0;
function guiltyLookingFunction(params)
{
runCount++; //increase by 1 every time this function runs
if (runCount>1000) //if this has run some insane number of times
alert("this function is the that's running wild!");
//the rest of your function's code
//same thing with loops within functions:
var loopCount = 0;
while (0!=1) //this will always be true, so the loop won't stop!
{
loopCount++;
if (loopCount>1000)
alert("this loop is to blame!");
//the rest of your loop
}
}
(replace "this function/loop" with some specific identifier if you're monitoring multiple suspects)

A) Use WebKit's (Safari, Chrome, Chromium) inspector instead of firebug - No more reload, yay!
B) Set some debug output along the way that will help narrow your problem down to the perpetrator.

Firebug. Reloading? Didn't you try to open Firebug before page loading?

Sometimes FCKeditor doesn't load in Firefox

I am unable to replicate the problem when I want to but it seems like every now and then, my site using FCKeditor will load the interface but not the content (Clicking the buttons don't do anything). No javascript errors show and once it starts doing it, it usually is tough to get back to normal. The way I found to work best is to click the refresh button multiple times in a row, then the FCKeditor loads correctly. I have only seen this in Firefox
Has anyone else run into this problem or know a solution. It is a little annoying for me but I am afraid my client would be really confused

I have experienced the phenomenon you describe in FCKEditor's successor, CKEditor. Somehow, the IFRAME that contains the WYSIWYG content doesn't get loaded. What always helps is switching to source code view and back, but that's no solution.
I have seen the problem described on the Internet but with no solution.
Caching is not the problem, I think. Sometimes, if you press "reload" 20 times, it will break at the 21th time, and work again on the 22nd time.
What minimized the number of occurrences for me was to activate the thingy to the editor's bottom that shows the element path (body > p > span, I forgot it's name). I don't now why but since I turned it on, it very rarely breaks any more.

I have had this problem. I solved it by pre-loading FCKeditor in a hidden iframe during the login process so that when it got to the pages where it was used it was already in the cache.

i would strongly advise to upgrade to CKEditor which can not only be spelled out verbally without offending anyone, but also optimizes the loading time to minimal. I find it much more responsive than his F- friend.

I encountered this problem with firefox (not reproducible) and chrome (reproducible).
The solution that worked quite well in both cases was to wait for some milliseconds before initializing CKE :
setTimeout(function() {textarea.ckeditor({customConfig : 'custom/schnonfig.js'})} , 100);

Safari issues with javascript + css

I have some strange behavior going on with safari, im using the jQuery.GridLayout plugin and css for styling.
Just for some context, this website layout is a simple header followed by the content which are a collection of blocks (each block is a div) positioned by the javascript and rearranged every time the window is re-sized.
When I direct safari to the website url all the blocks overlap to some degree (like 50%) but as I re-size the window if they have to move, automatically all goes to the correct place and only breaks if I refresh the page.
So it seems that loading the page is messing it up either because something fails to register or because something does not happen until I re-size the window.
As anyone experienced such behavior within safari?
It works perfectly in firefox and opera, its an valid html 4.01 transitional page and the css is also validated (wc3 wise that is).
I know that publishing the code is invaluable to sort this kind of issues but this is a production project and I'm obliged not to it.
Either way I appreciate any advice on were to start looking?
How do one goes about debugging this issues in safari?
Thank you.

Safari fires DomReady before linked resources are loaded. This race condition regarding calculating sizes of elements defined in CSS can usually be avoided by loading your CSS resources before any JavaScript (eg: make sure the tags appear in the before ANY tags (which are blocking, but give a change for CSS to load asynchronously). Worse case scenario, move your blocks to the last element in , leaving your tags above.
CSS concatenation of multiple files (if you have them) is also recommended.

If you aren't able to post the actual code of the page for us, you might find your solution while trying to reproduce the problem without your specific content. In the past, I've solved some of my own problems while trying to generate a page that shows the problem to post on IRC / SO. If you are able to reproduce the problem without your content, post it for the community, and an answer will be much easier to find.
My shot-in-the-dark guesses lead towards:
You may find that one of your content blocks is causing the issue.
You may find that a different library you are using is causing the issue.
Some javascript code for your layout may be running before everything is ready / filled in. From my memory, Safari is quick to display pages before images are loaded for instance.
Perhaps you need to specify the an exact width/height of some of your Grid Containers.

Small update:
(new update at bottom)
http://www.howtocreate.co.uk/safaribenchmarks.html
And also something that is working is this small script:
<script language="JavaScript">
// CREDITS:
// Automatic Page Refresher by Peter Gehrig and Urs Dudli www.24fun.com
// Permission given to use the script provided that this notice remains as is.
// Additional scripts can be found at http:
//www.hypergurl.com
// Configure refresh interval (in seconds)
var refreshinterval=20
// Shall the coundown be displayed inside your status bar? Say "yes" or "no" below:
var displaycountdown="yes"
// Do not edit the code below
var starttime
var nowtime
var reloadseconds=0
var secondssinceloaded=0
function starttime() { starttime=new Date() starttime=starttime.getTime() countdown()
} function countdown() { nowtime= new Date() nowtime=nowtime.getTime() secondssinceloaded=(nowtime-starttime)/1000
reloadseconds=Math.round(refreshinterval-secondssinceloaded) if (refreshinterval>=secondssinceloaded)
{ var timer=setTimeout("countdown()",1000) if (displaycountdown=="yes")
{ window.status="Page refreshing in "+reloadseconds+ " seconds"
} } else { clearTimeout(timer) window.location.reload(true) } } window.onload=starttime
</script>
I find it odd that a refreshing script solves the issue in safari, but if i manually refresh the page the page havoc ensues...
########UPDATE##########
Well I finally got some more time to work on this and after doing some reading a rather obvious thing came to my mind, let the content load and then format it, so for now all of my js sits between </body> and </html>.
Its not perfect since now you can catch a glimpse of the content without being properly placed when the page first loads.
Maybe ill try calling the js a second time after a few ms have passed of loading.
I know this was proposed a bit upper the thread I just needed time to get my hands dirty thanks all, Ill keep updating till I get it solved in a more proper fashion :)

How can I debug this memory usage / dom usage increase in my JS/Update panel site

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