We Keep Coding

Changing Window.prototype.open in a way that isn't detectable/reversible

I am looking into ways to extend Firefox pop-up blocking from an extension. One option is replacing window.open() (or rather Window.prototype.open()) in the webpage by a wrapper function. An important requirement is that this manipulation cannot be detected or reverted by the webpage. For example, if I simply do this:
Window.prototype.open = wrapper;
The webpage can easily revert the change by doing:
delete Window.prototype.open;
Instead I can use Object.defineProperty() to set advanced property flags:
Object.defineProperty(Window.prototype, "open", {value: wrapper, configurable: false});
The webpage can no longer revert this change but it can still detect it: delete Window.prototype.open normally changes the value of Window.prototype.open (different instance of the same function it seems), here delete won't have any effect at all. Also, Window.prototype.open = "test";delete Window.prototype.open; will produce inconsistent results (different ones depending on whether writable: false flag is specified for the property).
Is there anything else that I can do to emulate the behavior of the original property (short of using binary XPCOM components which has way too many issues of its own)?

You might try using the nsIWindowWatcher interface to register your own window creator (nsIWindowCreator). That way you can control whether a new window is opened without affecting the window object itself (and thus remaining invisible to web sites).
I'm not sure whether the inability to change the implementation of window.open() without this being detectable is a bug. Perhaps it's just not considered an important requirement for methods like Object.defineProperty. But it might be worth filing a bug to see what others think about making this an option in the future. After all, ad blocking is a major use case.

In the end I had to give up on using JavaScript proxies for the job. Even though with some effort I can create a wrapper for window.open() that behaves exactly like the original (bug 650299 needs to be considered), there doesn't seem to be a proper way to replace the original window.open() function. The changed property will always behave differently from the original one, too bad.
So I decided to go with a different approach as a pop-up blocking solution: listen for content-document-global-created notification and have a look at the subject (the new window) as well as its opener. Windows with a non-null opener are pop-up windows of some kind. One can look at the URLs and decide whether the pop-up should be blocked. To block one would call window.stop() (stops all network activities before any network requests are sent) and window.close(). The latter has to be called asynchronously (with a delay) because it will cause a crash otherwise as the initialization of the window continues. Some notes on this approach:
For pop-ups opening in a new window the window will still show up but disappear immediately. This seems to be unavoidable.
For the web page it looks like its pop-up window opened but was closed immediately - this isn't how the built-in pop-up blocker works, more like an external pop-up blocking application.
New windows always load about:blank first before changing to their actual destination. For same-origin pop-ups the latter won't send a new content-document-global-created notification which is unfortunate.
All in all: not perfect but usable. And it is very simple, nowhere near the amount of code required for JavaScript proxies.

Web browsers intentionally prevent this behavior, it's for maintaing the security of web e.g. when you use iFrame you don't want that iFrame to mess up or hack your page.
But instead of manipulating the window object properties why not to create a wrapper for the window object and override window by the wrapper locally?
Example:
// Copy window object to wraper
var wrapper = {};
for(prop in window) {
wrapper[prop] = window[prop];
}
wrapper.open = function yourNewOpenFunction() {
/// do your custom code here
}
(function fakeScope(window){
window.open(); // this is wrapper.open
}(wrapper));
BTW this affects only the body inside fakeScope() function, and cannot be applied globally.

it striked me this morning: you can use Object.freeze(Window.prototype); !
test have shown, that methods protected with this cannon be deleted, but they can be easily detected.
old answer:
What about ES:Harmony Proxies ?
http://brendaneich.com/2010/11/proxy-inception/
Of course, they are unstable, but they are working in Firefox 4+, and you are not the man, who is afraid of difficulties ;)

Firefox sidebar calling javascript functions in main browser window

I'm trying to put together a quick Firefox sidebar for internal use only.
I'm struggling a bit in understanding how sidebar and main browser window communicate. What I want to do exactly is call existing javascript functions that reside in the main browser window only.
My code looks like this;
ff-sidebar.xul
<checkbox label="Button hover" checked="false" oncommand="add_enhance(this)"/>
ff-sidebar.js
function add_enhance(cb){
if (cb.checked) {
// this bit is wrong I know
window.content.document.NEWSTYLE.buttonHover();
}
}
So the question is, how do I call a function called NEWSTYLE.buttonHover() that lives in the main window?

Theoretically, this should work:
window.content.NEWSTYLE.buttonHover();
window.content points to the browser content window and the variable NEWSTYLE is defined on this window. In reality things are a bit more messy due to security mechanisms - privileged code cannot access objects of unprivileged code directly. Instead you get to access them through XPCNativeWrapper (see https://developer.mozilla.org/en/XPCNativeWrapper). Technical details changed somewhat in Firefox 4 but essentially it is still the same.
The easiest way to do what you want without introducing security issues is changing the location of the content window to a javascript: URL. Like this:
window.content.location.href = "javascript:void NEWSTYLE.buttonHover()";
You won't be able to get the result of this function but it doesn't look like you need it.

How to open a window in asp:updatepanel

I have a pop-up CustomControl which I use in a large-scale web application. The pop-up works well everywhere other than when used inside an asp:UpdatePanel, the problem arises when controlling the visibility of the pop-up (the pop-up is nested in a table) with other controls:
When I click the button to open the window I get Error: Object expected and when I try to debug the error with IE 8 JSEditor I get ``Source Code is not available for this location.
I believe that the code of the pop-up is not being initialized completely, but it is just my guess and I don't know how to resolve this issue.
Any help or ideas will be appreciated.

While I can't get to see that question title has a lot to do with the subject at hand,
Most (if not all) Object Expected error occurs when you add a reference on your page to a JavaScript file which doesn't exist or cannot be opened.
When you run your website in debug-mode, VS will put another pseudo-project in solution explorer, navigate through the files there and you will find the already loaded-version of JS, you can set breakpoints there and see what code exactly is "not available".
Note: This is for Web Applications, I'm not sure if it applies to Project-less Websites.

Does this work in other browsers? Have you tried Firefox and Firebug to investigate the issue or is this specific to IE.
Having code in an ASP:UpdatePanel means that the Microsoft Ajax javascript include will be loaded and come an interfere with the object model you are normally expecting to get. Are you certain of the id or name you are trying to find as this might not be returning an Object hence the error.
I have used jQuery and classes and styles to add behaviour after the page loads to avoid id issues. The $jQuery.live() function is useful to ensure handlers get bound to items delivered to the page with MS Ajax.

Is it alright to use target="_blank" in HTML5?

I recall reading somewhere that in HTML5 it was no longer okay to use target="_blank" in HTML5, but I can't find it now.
Is it alright to continue to use target="_blank"?
I know it's generally considered a bad idea, but it's by the easiest way to open a new window for something like a PDF, and it also doesn't require you to rely on JavaScript.

It looks like target="_blank" is still alright. It is listed as a browsing context keyword in the latest HTML5 draft.

It is ok to use target="_blank"; This was done away with in XHTML because targeting new windows will always bring up the pop-up alert in most browsers. XHTML will always show an error with the target attribute in a validate.
HTML 5 brought it back because we still use it. It's our friend and we can't let go.
Never let go.

Though the target="_blank" is acceptable in HTML5, I personally try never to use it (even for opening PDFs in a new window).
HTML should define meaning and content. Ask yourself, “would the meaning of the a element change if the target attribute were removed?” If not, the code should not go in the HTML. (Actually I’m surprised the W3C kept it… I guess they really just can’t let go.)
Browser behavior, specifically, interactive behavior with the user, should be implemented with client-side scripting languages like JavaScript. Since you want the browser to behave in a particular way, i.e., opening a new window, you should use JS. But as you mentioned, this behavior requires the browser to rely on JS. (Though if your site degrades gracefully, or enhances progressively, or whatever, then it should still be okay. The users with JS disabled won’t miss much.)
That being said, neither of these is the right answer. Out there somewhere is the opinion that how a link opens should ultimately be decided by the end user. Take this example.
You’re surfing Wikipedia, getting deeper and deeper into a rabbit hole. You come across a link in your reading.
Let’s say you want to skim the linked page real quick before coming back. You might open it in a new tab, and then close it when you’re done (because hitting the ‘back’ button and waiting for page reload takes too long). Or, what if it looks interesting and you want to save it for later? Maybe you should open it in a new background tab instead, and keep reading the current page. Or, maybe you decide you’re done reading this page, so you’ll just follow the link in the current tab.
The point is, you have your own workflow, and you’d like your browser to behave accordingly. You might get pretty frustrated if it made these kinds of decisions for you.
THAT being said, web developers should make it absolutely clear where their links go, what types and/or formats of sources they reference, and what they do. Tooltips can be your friend (unless you're using a tablet or phone; in that case, specify these on the mobile site). We all know how much it sucks to be taken somewhere we weren't expecting or make something happen we didn't mean to.

it's by the easiest way to open a new window for something like a PDF
It's also the easiest way to annoy non-Windows users. PDF open just fine in browsers on other platforms. Opening a new window also messes up the navigation history and complicates matter on smaller platforms like smartphones.
Do NOT open new windows for things like PDF just because older versions of Windows were broken.

Most web developers use target="_blank" only to open links in new tab. If you use target="_blank" only to open links in a new tab, then it is vulnerable to an attacker. When you open a link in a new tab ( target="_blank" ), the page that opens in a new tab can access the initial tab and change its location using the window.opener property.
Javascript code:
window.opener.location.replace(malicious URL)
Prevention:
rel="nofollow noopener noreferrer"
More about the attribute values.

While target is still acceptable in HTML5 it is not preferred. To link to a PDF file use the download attribute instead of the target attribute.
Here is an example:
<a href="files/invoice.pdf" download>Invoice</a>
If the original file name is coded for unique file storage you can specify a user-friendly download name by assigning a value to the download attribute:
Invoice
Keep in mind that while most modern browsers support this feature some may not. See caniuse.com for more info.

It sure is!
http://www.w3.org/TR/2010/WD-html5-20100624/text-level-semantics.html#the-a-element

I think target attribute is deprecated for the <link> element, not <a>, that's probably why you heard it's not supposed to be used anymore.

You can do it in the following way with jquery, this will open it in a new window:
<input type="button" id="idboton" value="google" name="boton" />
<script type="text/javascript">
$('#idboton').click(function(){
window.open('https://www.google.com.co');
});
</script>

Is there any window management library in JavaScript?

I have many browser windows, opened from JavaScript. And I want to manage them - place cascade, tile and resize them all at the same time. Are there any libraries that can help me?

In the past I would have just used the DOM standards documentation to figure out what I can do as a starting place. www.w3.org/TR/Window/
If you are looking for a simple library that you can use, which will work well across browsers I would take a look at jquery. http://jqueryui.com/

I really don't know if JavaScript is allowed to access anything besides the window it is currently running in. Just think about the different browser implementations e.g. when a browser always opens a new tab instead of a window (you can't resize and place them), or opens it as a child window inside the application (as Opera does) etc. Just because of that I don't think it is possible in a proper way.
If you really need a more sophisticated JavaScript window manager you might want to take a look at ExtJS. It generally gives you move control over your entire user interface.