Develop Reference

Chrome Bookmarklet to Check URL

I am creating a chrome javascript bookmarklet with reference to:
this question
My code:
javascript:(function NoOverrideAction(t){this.currentWindow=t,this.urlMatchPattern=/https:\/\/.*visual\.force\.com\/apex\/.*/,this.urlMatchPattern1=/https:\/\/.*visualforce\.com\/apex\/.*/,null!=this.currentWindow.location.toString().match(this.urlMatchPattern)||null!=this.currentWindow.location.toString().match(this.urlMatchPattern1)?this.isPageValid=!0:this.isPageValid=!1,this.recordId} NoOverrideAction.prototype={getId:function(){this.currentWindow.location.search.substr(1).split("&").forEach(function(t){var i=t.split("=");"id"==i[0]&&(this.recordId=i[1])},this)},run:function(){this.getId(),console.log(this),this.isPageValid&&void 0!==this.recordId&&(this.currentWindow.location.href="https://"+this.currentWindow.location.hostname+"/"+this.recordId+"?nooverride=1")}};var noAction=new NoOverrideAction(window);noAction.run();)();
However, I get following error:
Uncaught SyntaxError: Unexpected identifier
This works well in console but not as a bookmarklet.
I am trying to verify the URL of my current page and replace the URL

Part I.
Several reasons why js-code might work in console, but not work as a bookmarklet.
1 - You don't use the established way of making bookmarklets, i.e. IIFE-functions.
javascript:(function(){
alert('hi');
/*code here*/
})();
2 - If you do use this structure, there might be the problem with comments.
Use /*multi-line comment*/ instead of //single-line comment (because bookmarklet is a one-liner, so you cannot close your comment)
3 - Some problems with semicolons ;.
Don't confuse statements (need semicolon) and assignments (do not need them).
Console has its "automatic semicolon insertion", but it is a problem for a one-lined bookmarklet.
You should read a bit more here: https://stackoverflow.com/a/2717956/5410914
Part II
Since there is no HTML-code to test, it might be hard to check. Moreover, you could have made it easier to read by making it multi-lined (it will still work as a bookmarklet when you paste it as a bookmark). But anyway.
The main reason it might not work is that you don't use IIFE-format (Immediately Invoked Function Expression).
Your code has function NoOverrideAction(t) and, moreover, there is };var noAction=new NoOverrideAction(window);noAction.run();)(); at the end. It is not IIFE.
Read more: https://developer.mozilla.org/ru/docs/Glossary/IIFE
To debug a bookmarklet on your own, since there is no HTML provided, you might try to make your code simplier (even with alert('hi'); at first, and verify the reason it won't start) and then make it more complicated once you figure out that it works.

Firefox Bookmarklet: Exposing functions to the global namespace

I'm working on a moderately-complex Bookmarklet that works just fine in Chrome, but I can't get it to work in Firefox. When I run my Bookmarklet in Firefox it redirects to a new page that only says true on it.
I've narrowed the cause down to a very specific thing: Firefox doesn't seem to like when you expose new functions to the global namespace.
If this is the case, might you know more about it? Is this documented anywhere, such that I can learn more about it? Resources on the nuances of bookmarklet-building seem scarce, and I can't find anything relevant. A second question would be if there are there any known workarounds.
And for some examples (remember, to test them simply copy these lines of code into a bookmarklet in Firefox. Then run them on any page).
Redirecting bookmarklets
javascript:!function(){window.okay={test:function(){}}}();
The project I'm working on
A Non-redirecting bookmarklet
javascript:!function(){window.okay={test:!0}}();
Any thoughts? Thanks!
For now, I plan to use manual subscriptions in Knockout to get the functionality I need. It'd still be nice to know the answer to this question, though.

It has nothing to do with exposing globals. It has everything to do with the final evaluated value of your bookmarklet.
Any JS code that is evaluated always returns a value which comes from the last line of code or the last block.
For me, in Firefox, both of your examples redirect because both return true. You can test this by pasting the code directly into Firefox console.
Furthermore...
javascript:!function(){...}();
This is weird. I've never seen this pattern.
This is the most common bookmarklet pattern these days:
javascript:(function(){...})();
As long as you don't end that anonymous function with a return, that pattern evaluates to undefined, and no redirect happens.
The older way of achieving the same result was to always use void(0); as the last line of code. That evaluates to undefined also, and if it is the last line, then the entire script evaluates to undefined, and no redirect happens.

angular ngRoute breaks when using base tag

Can anyone tell me what is wrong with my code? I put up a simple webpage to show you: http://plnkr.co/edit/TkADpfgchYVdvNTqRPFT?p=preview
I'm using base tag with a sub dir along with html5mode and the beta version

I don't think you're really doing anything wrong. I think its a bug in the new release candidate. You're not really even doing anything special. Its just in your $locationProvider.html5Mode(true); call. That function calls angular's beginsWith function, which calls .indexOf on the url string, which is apparently undefined. I would suggest creating a bug for it on angular's github page. You can do that here. I would simply post this issue and the link to your plunker and they should be able to handle it.
That's precisely why they ask us to test the rc's. Good find. I'm not actually using HTML5Mode, so I hadn't found this particular bug yet.

You are trying to call a method of an undefined variable. You should probably add a check such as:
if (typeof variable ==="undefined")

'Invalid Argument' Error in IE, in a line number that doesn't exist

I'm getting the following error in IE 6:
Line: 454
Char: 13
Error: Invalid Argument
Code: 0
URL: xxxxx/Iframe1.aspx
and I can't for the life of me find what's causing this.
This only happens in a situation where I have a main page that has several IFrames, and it only happens when I have one particular IFrame (the one pointed to by the URL in the error message), and that IFrame is invisible at the time of loading.
I've narrowed it up to there, but I still can't find anything more specific...
The IFrame in question doesn't have 454 lines in its HTML, nor do any of the JS files referred by it.
I tried attaching VS to iexplore.exe as a debugger, and it breaks when the error occurs, but then tells me "There is no source code available for the current location"...
Any suggestions on how I can go about chasing this one?
UPDATE: I found this problem through brute-force, basically, commenting everything out and uncommenting randomly...
But the question still stands: what is the rational way to find where the error is, when IE reports the wrong line number / file?

IE's Javascript engine is disgusting when it comes to debugging. You can try enabling script debugging in the Advanced Options, and then if you have Visual Studio installed it will jump to the place of error... if you're lucky. Other times you don't get anything, especially if the code was eval()'ed.
Another thing about these line numbers is that it doesn't reflect which file the error is happening in. I've had cases where the line number was actually correct, but it was in a linked .js file, not the main file.

Try using the Microsoft Script Debugger or DebugBar (http://www.debugbar.com) which may give you some better IE6 debugging tools. They always help me with IE6.
Also, does this happen in any newer versions of IE or just in IE6?

It's virtually impossible to debug this without a live example, but one thing that often causes an "Invalid Argument" error in Internet Explorer is trying to set an incorrect value for a style property.
So something like:
document.getElementById("foo").style.borderWidth = bar + "px";
when "bar" has the value null, or undefined, or is the string "grandma", will cause it, as "grandmapx" isn't a valid value for the borderWidth style property.

IE9 has a browser mode.
Open up Developer Tools, then select the version you want to emulate in the console, reload the page with errors, and the console will show you line numbers and the correct file where the error is.

I run into this problem a lot too, and I've also resorted to commenting everything out until I find the problem. One thing that I find to be useful is to add a try/catch block to every javascript method. Sometimes I add an alert to tell what method the error came from. Still tedious, but easier than trial and error commenting. And if you add them every time you write a new method it saves a lot of time in the event errors like those occur.
function TestMethod()
{
try
{
//whatever
}
catch (ex)
{
ShowError(ex.description);
//alert("TestMethod");
}
}

A note to other readers: I recently had this "Invalid argument." error reported in IE7-9 and eventually found that it was down to the way I was using setTimeout/setInterval.
This is wrong, in IE:
var Thing = {};
Thing.myFunc = function() { ... };
setTimeout(Thing.myFunc, 1000);
Instead, wrap the callback in an anonymous function like so:
var Thing = {};
Thing.myFunc = function() { ... };
setTimeout(function() { Thing.myFunc(); }, 1000);
and no more "invalid argument" errors.

Another possibility:
I do a lot of dev between two computers, at home and at work, so I often email myself or download pages from the server to work on. Recently I realised that Vista has a habit of unilaterally applying blocks to certain files when they are downloaded in certain ways, without notifying me that it is doing this.
The result is that, for example, an HTML page wants to access the .js file in its header, but it doesn't have permission to access local files. In this case, it doesn't matter what you write in the .js file, the browser will never even read it, and an irksome Line: 0 error will result.
So before you comb your code for an error, check your HTML page's properties, and see if it hasn't been blocked by the OS....

Like NickFitz pointed out, styling was an issue with my code.
document.getElementById('sums<%= event.id %>').style.border='1px solid #3b3b3b;'
I removed the border style and my IE issues were gone.

IE Operation Aborted - None of the regular fixes work

First of all, I've been researching this "Operation Aborted" error / bug for what seems like weeks, so here are a couple related questions and good articles if you are not familiar with it:
Why does ASP.NET cause the “Operation Aborted” Error in IE7? (so question)
Detecting cause of IE’s Operation Aborted Issue (so question)
Official Microsoft Knowledge base
Official IE Blog
Now here's my problem:
First I tried moving all my <script> elements to the end of my body tag. Didn't work. Then I refactored all my js functions to an external file that is linked in the <head>, all of my js functions are called from onclick or onkeypress anyway. Still getting the error. The last line of one of my .js files is
document.onload = setTimeout("foo()",500);
so I moved that to <body onload="setTimeout('foo()',500);">. I'm still getting this error. I don't know what to do. The only place I'm editing DOM elements is in foo(). Please help!
About my setup:
Java, Hibernate, Struts, JSPs ... I think that's all that is relevant.
What am I missing here?
Thanks in advance.

There are several causes for this. Two of the most common are:
1) scripts attempting to modify the DOM before the document has completely loaded
2) Trailing commas in object or array declarations
Number two is usually relatively easy to find, while number one is much tougher. Generally the best way to track down IE Javascript problems is to install Microsoft Script Debugger, so at least you can see what lines are causing the problem. With Script Debugger, IE will halt execution inside the browser and kick the script to a Script Debugger console, which will show the problem line. Much more informative than regular IE error messages.

Please see my answer to this question in another thread. I love this little trick and it has never failed me (when the cause is DOM manipulation before IE is ready, I mean). And as written, it doesn't affect the DOM-compliant browsers.

That problem can be a bear on a large page. Beyond the advice in the articles you already have, the only thing I can suggest from here is to remove wide swaths of the page in a dev environment until the problem goes away. Keep refining what is/is not on the page until you know which piece of content is causing the problem.
I've actually seen a confluence between two unrelated page elements cause this problem. I don't remember excisely why but the above approach, although painstaking, still worked.