I have a longpoll running but when I open a new tab in Firefox, or minimize the browser the longpoll seems to time out!? However if I leave the tab selected, or make a new dedicated window with Firefox open it won't time out.
Does anyone have any thought or insight on this weird behavior? When minimzied/alternate tab does Firefox stop running JavaScript in those tabs?
By the way I'm using Firefox 3.6.
No, it does not stop running JavaScript. And It does not block you from modifying the DOM. I have an app that runss a poll on server (I have both synchronous and async transmission) and then updates the dom based on results. And if I am looking at the tab or nor, and even if the firefox 3.6 is minimized - it just works. I have just tested it (again), before posting this answer.
Even the javascript test tools like selenium (in javascript) that are manipulating the DOM are working without focus.
So please check your code, it probably does require focus on some tab or on some element (like syockit suggested). I belive that you have the firebug, and you can easily analyze and debug your javascript (if it is not obfuscated).
Related
I'm using an iPhone 11 Pro with iOS 15.3.1.
I'm trying to figure out why when visiting my website, Safari is freezing most of the time when the page loads. Sometimes the page loads the first time I visit it, but on reload it basically freezes with no interaction.
When I connect the iPhone to a Mac and use the Safari inspector to connect to the webpage on the iPhone, the inspector is basically blank on all screens. If I go to the "Elements" tab, nothing shows. If I go to the "Console" tab and try to execute some Javascript, nothing happens when I press enter.
On OSX, I can see similar behavior, except I can actually open the inspector before I visit the page. In this case, when it freezes I can see a few elements in the "Elements" tab, but that's about it. Any sort of interaction I try to do in the inspector results in nothing happening.
I'm at kind of a loss. How can the development experience for such a popular OS/Browser be so terrible, and how do I work around the inspector itself not working? I can't replicate this freezing on anything besides Safari.
To be absolutely clear on my question:
What is your process to debug a webpage in Safari when it is in a state where the inspector no longer interacts with the webpage?
I did a broad divide and conquer of my app, commenting out top level code and working my way down uncommenting until I found the exact line that causes the freeze.
It seems calling HTMLInputElement.setSelectionRange() inside an onfocus event handler function caused an infinite synchronous loop in Safari, perhaps Safari synchronously blurs the input and refocuses for some reason when that function is called. And on page reload Safari was trying to focus on an input with that code automatically. That is my guess at least, removing the setSelectionRange() resolves the freezing problem.
Luckily, the freezing was fairly consistent so the divide and conquer approach worked. Unluckily, the inspector really should have done its job and picked up on the fact that the page was hanging and told me which function code execution broke at when Javascript was forced to stop, like Chrome or Firefox would.
If anyone has any better ideas for debugging these kinds of issues in Safari besides the programming equivalent of a short circuit test, I'll gladly accept the answer.
I thought I may have found the solution under this post:
Why does JavaScript only work after opening developer tools in IE once?
But my problem is I have to close/open developer mode to get the js functions running. The function will not run when I just have the developer mode open. Rather, it waits until I clicked open/close developer mode window, then it will run.
It seems to hold the function in a queue and runs it after I have opened/closed developer mode.
Any possible idea of what is happening would be greatly appreciated.
Thank you all.
EDIT:
The specific function call has the 2 lines below:
parent.document.getElementById('frameset_id').cols = '60%, *'
parent.window.frame_id.location.href='asp_file.asp?passID=' + ID
Again, the code will run when I open/close developer mode, so I do not believe it is a syntax error. I may need to explore alternatives to adjusting the cols size and assigning the frame location.
Probably because you have console.log somewhere in your code. console does not exist at all in IE when the dev tools are closed, and it silently stops your JS from running.
What is changed, from the point of view of running AJAX application, when the IE Developers Tools are opened?
I'm tracing now some Schrödinger bug. It's about dropdown lists from PrimeFaces in IE. They are sometimes not opening after click, and they got 'unblocked' after one maximizes browser or unzooms the content. Because those dropdowns are realized on the basic of normal input, with attached div, I supposed it's something with wrongly calculating the place to show that dropdown popup. I've also supposed AJAX errors.
But after opening IE Developers Tools it's hardly possible to reproduce the error. No error is showed in console, no AJAX request hangs, and, what's more, everything seems to function more.
The error is only for IE, so the developers tools are the only way to debug it. However, when they are opened, it seems that the observation changes the state somehow, like in quantum mechanics...
So, I need to know, what could be changed by opening those developers tools, that prevents the bug from showing up?
--edit--
It has nothing to do with console.log. It is the problem with calculating the size of invisible elements. The problem was solved by adding scroll to the body. However, the question is open, how the IE Developers Tools were influencing those calculations.
If you really want to always include using console, I suggest using a polyfill for it:
(function(b){
var a=0;
var c=function(){};
var d=["log","assert","clear","count","debug","dir","dirxml","error","exception","group","groupCollapsed","groupEnd","info","profile","profileEnd","table","time","timeEnd","timeStamp","trace","warn"];
b.console=b.console||{};
for(;a<d.length;a++){
b.console[d[a]]=b.console[d[a]]||b.console["log"]||c;
}
})(window);
This a minified example that I tried to make readable. It's something I found awhile ago and modified some. I think the main thing I modified is that if you call a method that wasn't originally implemented by the browser's native console, it will call console.log. If console.log wasn't natively implemented, it just calls an empty function. The original version of this code didn't include this fallback to console.log.
This will "guarantee" that console calls will not fail. You can change the d variable to only include calls you are sure you will use, otherwise there's some extra unnecessary processing.
I am troubleshooting some slow jquery code on a drupal module. After the page loads on a configuration form, you click on an area to expand out a fieldform. However, this expansion takes forever, and most browser give a warning "The script has become unresponsive, do you want to stop it?"
I'm looking for a profiler that will give output like that from xdebug, where I can see the statistics of the entire execution path, just for that one javascript event.
The debugger in firebug will drop me in on the exact line where firefox decides that the script is taking too long; but there is no single line that is the problem (at least I don't think so at this point). I believe that the slowdown comes from some poorly-architectured looping or iteration that spans multiple lines, which is why I want the profiler stats to show me in what parts of the code its spending most of the time.
The Firebug add-on has a profiler built into it. I don't have Firebug installed on the machine I'm using right now, but if I recall it's accessed from a pull-down menu in the "Console" view. (I could be wrong; it's there somewhere.) I can't say that I'm super-fond of it, but you might want to give it a try.
Chrome's developer tools also has a profiler, which is a little fancier.
For IE, there's a product called dynaTrace AJAX edition, which has a really fancy profiler. Of course it only works with IE, but you're going to have to test in IE anyway — if you've got a page that's slow in other browsers, it's going to be even worse in IE :-)
Got this page which has some javascript on it (very heavy) and I am trying to see what happens when I click a certain element. However looking at the code there is no onclick function - the javascript is several JS files so take far to long to browse.
Is there a way with Firefox (firebug), Chrome or even IE to view whats / log what is happening when I click on an element in the browser?
In firefox (and this is also available in chrome and IE in another form) install addon firebug (if not installed). Go to Tools->Birebug->Open Firebug. Click on Left Icon and ask for tracing.
You can then trace your program.
Another way is to cause a breakpoint when you start, and you manually follow the execution of the script.
Chrome Developer Tools shows all attached event handlers for an element. See the section on Event Listeners towards the end.
#wizzard, try this: firebug - profiling button
ff only, but there is a lite version for chrome for example