IE Debugger inaccessible - javascript

I am trying to simulate showModalDialog behavior with window.open function.
To block access to parent window, I used a while loop :
while(resultPopup && !resultPopup.closed){
resultPopup.focus();
}
This, technically works fine, make parent window unreachable but whenever I try to debug the popup in IE, the focus stays on the popup and the debugger became unreachable too.
Is there anyway to make IE Debugging Tool reachable with JavaScript?

That creates an endless loop and there is no chance for the browser to breath -- to refresh or do anything.
I can't test it, but if anything will work, it would be something like this:
// Raw, untested code
function tryIt() {
if (resultPopup && !resultPopup.closed){
setTimeout(function() {
resultPopup.focus();
console.log("Retrying...");
tryIt();
}, 10);
}
}

Related

Why Chrome don't allow change variables in debug

I run in Chome devtools next code
(function() {
var a = 5;
debugger; // when I stop here I evaluate `a = 9`
console.log(a);
})(); // and got 5
but if I use
(function() {
var a = { a: 5 };
debugger; // when I stop here I evaluate `a.a = 9`
console.log(a.a);
})(); // and got 9
Why?
PS
also why it doesn't work in FF / Safari (it even didn't stop in debugger line )
This is behavior is simply a bug, and will be fixed in an upcoming release.
If you want a "why" deeper than that, you'll need to know a lot about Chrome's debugger and JavaScript implementation. According to the diff of one file in the fix, the debugger formerly used a context_builder.native_context but now it uses a context_builder.evaluation_context. Apparently the native_context created by the old debugger code had trouble resolving (or not treating as read-only) local-scope variables. If you really wanted more, you could contact the author of the fix.
As for why the debugger does not appear in Firefox: it will appear if you are running code from a <script> and have your dev tools open. When running code from the console, it appears that you must have the debugger tab open specifically. Obviously, this is not possible if you have the console open to type in your code, but you can wrap it in setTimeout and quickly switch to the Debugger tab:
setTimeout(function() { debugger; }, 5000)
It is a matter of how the variables are used. Objects are used by reference. So changing a.a will effectively change the value at the proper memory address. Though, changing a itself in any of your test version won't do anything because a new memory address is created for the variable evaluated in the console.
For FireFox not breaking at debugger line, it states in this page (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/debugger) : "If no debugging functionality is available, this statement has no effect.". So, you have to ensure FireBug is installed I presume.

Why does this simple login script work in Tampermonkey but not Greasemonkey?

I have this tiny little script that I run inside Chrome using Tampermonkey and works great.
However, when I use it in Firefox with Greasemonkey, it shows up on the active list, meaning its matching the page but it doesn't actually execute the code. I know it has to be a simple something I am overlooking but its not hitting me.
var myVar=setInterval(function(){myTimer();},100);
function myStopFunction()
{
clearInterval(myVar);
}
function myTimer()
{
var p1 = "Login";
var p2 = "mode=login";
var x = document.body.innerHTML;
if (x.match(p1) && x.match(p2)){
document.documentURI = "/ucp.php?mode=login";
}
myStopFunction();
}
Script Logic/Function
I am using a timer to prevent the script from triggering over and over in a permanent loop.
It simply detects if I am logged into a phpBB forum or not, if not send me to the login page so I can log in.
I am using document URI so that the location of the original is preserved so upon login, it takes me right back to it.
Often phpBB when you log in, it will take you back to the index page so this preserves my original intent of going to the actual link.
This script works perfectly and as expected on Chrome using TM but on Firefox using GM it doesn't trigger, am I missing something here?
From the Firefox spec:
(document.documentURI)
Returns the document location as string. It is read-only per DOM4 specification.
And, indeed, the latest spec still specifies that this attribute must be read only.
If Chrome lets you write this property, then that is non-standard behavior and maybe a bug.
Use location.assign(), or location.replace(), or just programmatically click the login button -- which often preserves the target page.

Javascript variable undefined in IE until console displayed

I have a small piece of code for a template project I'm working on. There are three separate buttons, that point to three separate locations. In order to make it easier for content providers, I have these buttons calling minimal routines to load the next page.
The code is as follows:
/* navigation functions here for clarity and ease of editing if needed */
prevURL = 'ch0-2.html';
nextURL = 'ch2-1.html';
manURL = 'ch1-2.html';
function prevPage() {
window.location = prevURL;
}
function nextPage() {
window.location = nextURL;
}
function goManager() {
window.location = manURL;
}
This works perfectly in Firefox and Chrome, but seems to fail in Internet Explorer.
I open up the developer tools in IE (F12) and am presented with the message:
SCRIPT5009: 'manURL' is undefined
The location information (line 43, character 13) points to the "window.location = manURL" part of the code.
However, once the developer tools are open, if I hit F5 to reload the page, the button works without error until I close IE and reopen it, where it once again fails to respond and gives the same "undefined" error.
I'm baffled. Anyone have any ideas?
UPDATE
I know the variable declaration is poor, and that I can use window.location.href instead. What is relevant here is that the other two pieces of code, which are identical in all of these significant ways, work perfectly either way.
epascarello has put me on the right track. by removing all console.log commands, everything starts working. I'm just wondering why this happens, and would like to be able to give epascarello credit for helping me.
IE does not have console commands when the developer window is not open. So if you have them in there the code will not run. It will error out.
You can either comment out the lines or add in some code that adds what is missing.
if (typeof console === "undefined") {
console = {
log : function(){},
info : function(){},
error : function(){}
//add any others you are using
}
}
Try setting
window.location.href
instead of just window.location.
Source:
http://www.webdeveloper.com/forum/showthread.php?105181-Difference-between-window.location-and-window.location.href
Always define variables before using them ,being explicit (expressing the intention) is a good practice,
so define your variables like this,
var prevURL = 'http://google.com';
var nextURL = 'http://msn.com';
var manURL = 'http://stackoverflow.com';
You can try using
window.location.href
refer to this post for difference
Suggestion:
Make a jsfiddle.net for us so we could guide you easily

Accessing the window object in Firefox addon content script?

I can't seem to access the window object in a content script. Is this normal?
For example, this does nothing:
window.onload = function() {
console.log("Hello from the onload");
};
Instead, I have to use the unsafeWindow object.
unsafeWindow.onload = function() {
console.log("Hello from the onload");
};
I must be missing something simple right?
Don't use window.onload, instead write:
window.addEventListener("load", function() {
console.log("Hello from the onload");
}, false);
window.onload has the limitation that there can only be one event listener, setting a different listener replaces the existing one - that's already a reason why you should never use it. In case of the Add-on SDK things get more complicated because the content script has a different view of the DOM then the web page. So just use addEventListener.
Oh, and please don't use unsafeWindow - it is (as the name already says) inherently unsafe.
The window object available to you in a content script is actually a proxy - hence unsafeWindow works and window does not. I did some tests and document.addEventListener does not work either:
https://builder.addons.mozilla.org/package/150362/latest/
jQuery seems to work fine though, I imagine there is some magic they do to ensure that they fire no matter what.
The workaround is simply set contentScriptWhen to 'end' and run your code immediately - this should always work as the content script is attached when the document is finished loading.
I did log this bug regarding what I like to think of as the 'wtf?' aspect of this behaviour - I think the result is surprising to web developers and we should try to be less surprising:
https://bugzilla.mozilla.org/show_bug.cgi?id=787063

What causes the error "Can't execute code from a freed script"

I thought I'd found the solution a while ago (see my blog):
If you ever get the JavaScript (or should that be JScript) error "Can't execute code from a freed script" - try moving any meta tags in the head so that they're before your script tags.
...but based on one of the most recent blog comments, the fix I suggested may not work for everyone. I thought this would be a good one to open up to the StackOverflow community....
What causes the error "Can't execute code from a freed script" and what are the solutions/workarounds?
You get this error when you call a function that was created in a window or frame that no longer exists.
If you don't know in advance if the window still exists, you can do a try/catch to detect it:
try
{
f();
}
catch(e)
{
if (e.number == -2146823277)
// f is no longer available
...
}
The error is caused when the 'parent' window of script is disposed (ie: closed) but a reference to the script which is still held (such as in another window) is invoked. Even though the 'object' is still alive, the context in which it wants to execute is not.
It's somewhat dirty, but it works for my Windows Sidebar Gadget:
Here is the general idea:
The 'main' window sets up a function which will eval'uate some code, yup, it's that ugly.
Then a 'child' can call this "builder function" (which is /bound to the scope of the main window/) and get back a function which is also bound to the 'main' window. An obvious disadvantage is, of course, that the function being 'rebound' can't closure over the scope it is seemingly defined in... anyway, enough of the gibbering:
This is partially pseudo-code, but I use a variant of it on a Windows Sidebar Gadget (I keep saying this because Sidebar Gadgets run in "unrestricted zone 0", which may -- or may not -- change the scenario greatly.)
// This has to be setup from the main window, not a child/etc!
mainWindow.functionBuilder = function (func, args) {
// trim the name, if any
var funcStr = ("" + func).replace(/^function\s+[^\s(]+\s*\(/, "function (")
try {
var rebuilt
eval("rebuilt = (" + funcStr + ")")
return rebuilt(args)
} catch (e) {
alert("oops! " + e.message)
}
}
// then in the child, as an example
// as stated above, even though function (args) looks like it's
// a closure in the child scope, IT IS NOT. There you go :)
var x = {blerg: 2}
functionInMainWindowContenxt = mainWindow.functionBuilder(function (args) {
// in here args is in the bound scope -- have at the child objects! :-/
function fn (blah) {
return blah * args.blerg
}
return fn
}, x)
x.blerg = 7
functionInMainWindowContext(6) // -> 42 if I did my math right
As a variant, the main window should be able to pass the functionBuilder function to the child window -- as long as the functionBuilder function is defined in the main window context!
I feel like I used too many words. YMMV.
Here's a very specific case in which I've seen this behavior. It is reproducible for me in IE6 and IE7.
From within an iframe:
window.parent.mySpecialHandler = function() { ...work... }
Then, after reloading the iframe with new content, in the window containing the iframe:
window.mySpecialHandler();
This call fails with "Can't execute code from a freed script" because mySpecialHandler was defined in a context (the iframe's original DOM) that no longer exits. (Reloading the iframe destroyed this context.)
You can however safely set "serializeable" values (primitives, object graphs that don't reference functions directly) in the parent window. If you really need a separate window (in my case, an iframe) to specify some work to a remote window, you can pass the work as a String and "eval" it in the receiver. Be careful with this, it generally doesn't make for a clean or secure implementation.
If you are trying to access the JS object, the easiest way is to create a copy:
var objectCopy = JSON.parse(JSON.stringify(object));
Hope it'll help.
This error can occur in MSIE when a child window tries to communicate with a parent window which is no longer open.
(Not exactly the most helpful error message text in the world.)
Beginning in IE9 we began receiving this error when calling .getTime() on a Date object stored in an Array within another Object. The solution was to make sure it was a Date before calling Date methods:
Fail: rowTime = wl.rowData[a][12].getTime()
Pass: rowTime = new Date(wl.rowData[a][12]).getTime()
I ran into this problem when inside of a child frame I added a reference type to the top level window and attempted to access it after the child window reloaded
i.e.
// set the value on first load
window.top.timestamp = new Date();
// after frame reloads, try to access the value
if(window.top.timestamp) // <--- Raises exception
...
I was able to resolve the issue by using only primitive types
// set the value on first load
window.top.timestamp = Number(new Date());
This isn't really an answer, but more an example of where this precisely happens.
We have frame A and frame B (this wasn't my idea, but I have to live with it). Frame A never changes, Frame B changes constantly. We cannot apply code changes directly into frame A, so (per the vendor's instructions) we can only run JavaScript in frame B - the exact frame that keeps changing.
We have a piece of JavaScript that needs to run every 5 seconds, so the JavaScript in frame B create a new script tag and inserts into into the head section of frame B. The setInterval exists in this new scripts (the one injected), as well as the function to invoke. Even though the injected JavaScript is technically loaded by frame A (since it now contains the script tag), once frame B changes, the function is no longer accessible by the setInterval.
I got this error in IE9 within a page that eventually opens an iFrame. As long as the iFrame wasn't open, I could use localStorage. Once the iFrame was opened and closed, I wasn't able to use the localStorage anymore because of this error. To fix it, I had to add this code to in the Javascript that was inside the iFrame and also using the localStorage.
if (window.parent) {
localStorage = window.parent.localStorage;
}
got this error in DHTMLX while opening a dialogue & parent id or current window id not found
$(document).ready(function () {
if (parent.dxWindowMngr == undefined) return;
DhtmlxJS.GetCurrentWindow('wnManageConDlg').show();
});
Just make sure you are sending correct curr/parent window id while opening a dialogue
On update of iframe's src i am getting that error.
Got that error by accessing an event(click in my case) of an element in the main window like this (calling the main/outmost window directly):
top.$("#settings").on("click",function(){
$("#settings_modal").modal("show");
});
I just changed it like this and it works fine (calling the parent of the parent of the iframe window):
$('#settings', window.parent.parent.document).on("click",function(){
$("#settings_modal").modal("show");
});
My iframe containing the modal is also inside another iframe.
The explanations are very relevant in the previous answers. Just trying to provide my scenario. Hope this can help others.
we were using:
<script> window.document.writeln(table) </script>
, and calling other functions in the script on onchange events but writeln completely overrides the HTML in IE where as it is having different behavior in chrome.
we changed it to:
<script> window.document.body.innerHTML = table;</script>
Thus retained the script which fixed the issue.

Categories