I'm seeing an odd bug in IE that I'm not seeing in Chrome. Specifically, this involves some JS code not firing when a (Telerik) wizard is navigated back to it's first step.
When the user clicks their "Previous" button, some data isn't being properly loaded. Hitting F12 and bringing up the developer console has shown me the following Warning:
DOM7011: The code on this page disabled back and forward caching. For more information, see: http://go.microsoft.com/fwlink/?LinkID=291337
Ok, so I go to the link provided and I noticed the documentation states:
In order to be cached, webpages must meet these conditions:
...
- The F12 Developer tools window isn't open
This is a problem, because when I use the navigation buttons within my wizard WHILE the dev window is open, it behaves properly, just as it does in Chrome.
How can I debug my related Javascript so I can figure out what's going on? Also, I understand what caching is but I'm not exactly sure what this is about and I have no idea why Chrome behaves differently. Is there a way that I can force IE to behave like chrome and cut on (or off) whatever features that are causing this issue?
Yuck. Back to old school debugging for you.
Short of putting the whole browser into a Windows debugger, you can pretty much forget about setting breakpoints. All you can do is log.
If you are lucky and your problem isn't too deep, you can use a sprinkling of simple alert() statements to let you know the state of things at various stages in your code. One nice thing is that you can serialize objects now pretty nicely; for example, you can do JSON.stringify(this), which will probably give you a giant output, which you can copy and paste into your IDE and unpack. A major upside to doing this is that the alert will block, so you can take your time studying the output. A major downside to this is that race conditions are now much more likely.
Alternatively, you can add a <textarea> to the page and throw your JSON.stringify(this) results into that. Because this means extra DOM mutations, it also increases the odds of race conditions, but not by much. (If race conditions are a possibility, you can do this:
(function () {
var currentState = JSON.stringify(this);
setTimeout(function () {
document.querySelector('textarea').value = currentState;
}, 1000);
})()
Even though these are now asynchronous, if you use this multiple times in sequence, these will execute in that same sequence (unless you change the timeout period).
If you are doing actual page navigations (and not just changing the URL with pushState()), then actually reading those logs is going to be a problem. The solution is to put the page in a frame and write the content out to a sibling frame. As long as both frames are running on the same domain, you will have no problem pushing the data into the sibling frame. If you can't put them on the same domain, you are kind of screwed.
Related
I have a link that opens a new window using window.open. The pop up works fine, however the normal web page stops loading objects (images, scripts, ajax scripts) and sometimes the page doesn't load at all.
Here is my code:
MyWindow=window.open('player.php','Player','width=500','height=300'); return false;
Is there anything I am doing wrong?
Thanks,
Peter
First of all, please be more specific: tell us more about your browser and which version, and possible your OS. It could be more related to the browser than to the web content.
Then on to the possible problem; you start with saying "I have a link that ...".
To me that sound like you use <a href="javascript:DoSomething()">. Or perhaps <a href="#" onclick="DoSomething()">.
I tried both in some modern browsers: Chrome v37, IE v11. Both browsers did not produce what you describe:
- Chrome v37 will happily keep on loading, even if I immediately click a "window.open()"-link on top of a (huge) webpage;
- IE v11 will someshow show "false", which is strange, but still not what you got.
In some cases I also got to deal with the popup blocker.
A general tip might be to NOT USE <a href> for things like this. Behaviour seems inconsistent across browsers, also these days there are better alternatives, such as <span onclick="">...</span> and <button onclick="">...<button> or by using JQuery or other frameworks (which I do not know much about).
Although this many not be a conclusive answer, maybe this can help you experiment on your own, and think about possible causes or alternative ways of doing things.
The behaviour you describe should definitely NOT normally happen. This is confirmed by robbmj's JSFiddle, that fails to reproduce the problem. That's evidence that something is going on in the main page that is not plain vanilla page loading, or your "link opening" has something unusual to it. Apart from the syntax error (you use four parameters, not three).
Since you do not supply information on either of these points (how do you load the main page? How do you trigger the popup-opening code?), we do not even know if the problem
might be browser-related; I'd start and try to test things in IE, Chrome and Mozilla to see
whether anything changes; this might provide some useful insights.
One possibility
A very strong possibility is that your inadvertent fourth parameter goes into the window.open() "replace" parameter, which is a boolean, and triggers undefined behaviour or simply an error that stops everything. You should have things somewhat working in IE and not working at all in Firefox.
You should also be able to see whether this is the case by using Firefox and the Firebug extension, or the Web Developer Console in Chrome.
Another possibility
A more esoteric possibility is that the way you define the link might make the browser believe you've actually moved on to another page, so that there's no point in continuing loading the current page. Depending on the browser, this might have to do with how the link is defined and could be remedied by defining it some other way.
For example it could conceivably happen if you had
...
which I suspect is what led user Tomzan to ask, "is the link something like javascript:...?"
So if this is the case, try with this instead (this works for me in IE9/Chrome/FF):
link
function openPopup() {
MyWindow = window.open('player.php', 'Player', 'width=500, height=300');
// Also try the following. You won't probably like the results (it should send the
// popup window behind), but if it works, it proves we're dealing with a browser
// issue there.
// Blur and refocus
// MyWindow.blur();
// window.focus();
// Just focus
// window.focus();
return false;
}
Workaround
A possibly acceptable workaround could be to disable the link altogether (or hide it via CSS), and only reactivate/show it upon main document being ready. This sidesteps the problem, even if user experience could be somewhat worse due to a longer wait.
But if it's so likely that a user clicks on the link before waiting for the whole page to load, I'd also consider not automatically loading the rest of the page at all, and reorganize information to provide a more streamlined navigation. Or maybe distribute it on two sequential pages. Again, unfortunately you did not supply enough information to do more than guess.
As you probably know, JavaScript is single threaded. Every event is queued until there is idle time for it to be executed.
In the case of window.open, both windows must share a single context to keep it thread-safe because the opened window can access to it's parent using window.opener.
I don't know how browsers implements it, but we can guess two possibilities:
Idle time is shared between the two windows. It means if the popup does many blocking statements, it can freeze the main window's events.
Only one of the two windows can be active, which depends on which one has the focus. In that case, all events may be paused in the main window when you're using the popup.
If you want a more precise answer, I need more details about your code.
document.addEventListener("DOMContentLoaded", function () {
//whatever the code
MyWindow=window.open('player.php','Player','width=500','height=300'); return false;
}, false);
Try to wrap the code in SetTimeout
setTimeout(function () {
window.open( .. )
}, 0);
Your document should be loaded first, then popup should be open, So write your javascript code in the scope of $(document).ready().
enter code here
$(document).ready(function(){
$("#clickme").click(function(e){
MyWindow=window.open('player.php','Player','width=500','height=300'); return false;
});
});
I have a php page that hangs for 3-10 seconds after the page loads, you can't even scroll up or down, or close the tab when this happens. (the chrome loading gif still loops tho) Happens in Chrome and IE.
Chrome Timeline: http://imgur.com/wF5Pioz,KRbnxIm#0
Shows ContentVeil.js repeating over and over. I think it is client side(?), I did a grepWIN to search for ContentVeil, with no luck, and it doesn't show up in Chrome Network tab.
Chrome Profile: Second image, from above link.
I think this shows the issue at the anonymous function from meta-boxes.min.js, ln 1.
meta-boxes.min.js: http://pastebin.com/yqtJyqB1
Unfortunately line one is a function that encapsulates the whole script. I don't know js very well, I tried to just remove each function one by one but that just created more errors.
Any ideas on how I could find the source of the problem would be much appreciated.
It's part of the Evernote web clipping extension, and it's hooks DOM events, causing massive slowdowns if you are doing large amount of dom changes.
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 :-)
Disclaimer before the uppity types start in: This is not to be deployed "in the wild". This is for local, personal use by a Chrome add-on only. I am not trying trick visitors to my sites or do anything else unsavory. I've seen a bit of chastising of those wanting to hook onbeforeunload.
Some Background
Far and away my biggest gripe with Chrome (at least on Mac OS) is its tab close buttons which, when I have several tabs open (as I usually do), results in my frequently closing tabs unintentionally as the tabs themselves become fairly small and thus the click target area that isn't covered by the tab close button is very small. On certain tabs with news stories, blog posts, documentation, etc. it's annoying but not a huge inconvenience. I just CMD+T to reopen the tab and there's no real harm done. However, certain tabs, in particular Gmail, have definite downsides to being closed. I frequently have one or more chat dialogs with coworkers open and reopening a tab does not restore the chat dialog, and initiating a new chat loses me the current chat history (yes, it's saved, but it's not conveniently accessible by scrolling backwards in context). There are a handful of requests for Google to add the option to simply remove tab close buttons (I prefer to use CMD+W myself), but I'm not holding my breath on that.
A Partial Solution
A while back a friend pointed me towards the dotJS Chrome add-on which allows per-domain custom JavaScript execution, akin to GreaseMonkey, but slightly different. At any rate, it gave me a means to "fix" issues/wants on a number of sites I visit regularly, and I've found it to be very helpful thus far. The other day it occurred to me that I could probably keep my Gmail, et al tab(s) open with a bit of JavaScript. I threw together a small script that based on a regular expression would prompt you before closing a tab. The gist of the code is as follows:
var unloadHandler = function(e) {
if (/(mail.google.com|google.com\/reader|gmail.com)/.test(location)) {
return 'Are you sure you want to close: ' + location.host;
}
};
window.onbeforeunload = unloadHandler;
Lo and behold, this did the trick for most of the sites I tried it on; except one: Gmail. Let me correct that: it worked, insofar as it prompted me to confirm the closing of the Gmail tab, and if I opted to not close it, it would keep the tab open, but before the dialog prompted me, the page had gone completely white. Element inspector shows that the markup is all still there (so far as I can tell), and the styles on the elements shouldn't be hiding things (i.e. display: none; visibility: hidden; etc) and the elements' positioning is still correct (e.g. they're within the viewable area). I went through one-by-one removing elements to see if anything was obscuring the Gmail interface, but was never able to reveal it on screen. I cannot for the life of me figure out what's going on. I'm not sure if Gmail is hooked into some event I'm unaware of (an on*before*beforeunload?), or if Google's browser is doing something special with their Gmail page, or what is causing the strange behavior. Google Reader is unaffected by this oddity (I can prevent close and retain the contents of the page) as are all of the other sites I've tested with.
Does anyone know what might be causing this issue?
For the record, I am running the following: Mac OS X 10.6.5, Google Chrome 10.0.648.205, and dotJS 1.3.
I appreciate any feedback, but I am not looking for solutions that involve: pinning tabs, changing my workflow/usage (e.g. not selecting tabs with the mouse), etc. I really want to figure out what, specifically, Gmail (or perhaps Chrome?) is doing that is sabotaging my efforts here. Thanks in advance.
I think Gmail's own code causes this behavior. I can reproduce your problem (on linux machine) with subscribing for this event from the console with this function
window.onbeforeunload = function(e) {
return "Hey what\'s wrong with you?!";
};
After it I've started the developer tool profiler, the last call after closing the window (and choose the 'stay on this page' answer for the question) is a removeChild function call, which removes some content from the <iframe id="canvas_frame" />. So the content elements are not there anymore.
function Fc(b) {
return b && b.parentNode ? b.parentNode.removeChild(b) : m
}
I've found some 'traces' in the obfuscated code for subscribing for the beforeunload event, but it's hard to be sure :)
function It(b, a) {
this.Qc = jCa++;
this.ea = b;
this.ka = new J(this);
this.Qa = a;
this.Ka = [];
this.Za = !1;
this.ka.ya(this.ea, "unload", this.Da);
this.ka.ya(this.ea, "beforeunload", this.ab);
Ypa(Zd(a), this);
this.ia()
}
I tried to reproduce this behavior in Firefox but I think google ships different javascript codes for different browsers so I can't reproduce it.