Develop Reference

Bypassing The pop-up blocker for window.open() in javascript

I have a text file with some lines containing some key words. My exercise is to extract info from that file and create a html document inserting the liens in the text file with appropriate tags.
for example:
This is the text file:
This should be in a html tag with START as class name
THIS SHOULD BE IN A HTML TAG WITH CAPITALS AS CLASS NAME
This should be in a HTML tag with CODE as class name
Now writing a javascript program to insert those lines into HTML is very easy. I just used some string handling like this:
if(contents[i].indexOf(" CODE")!=-1){
w.document.write("<p class='code'>"+lines+"</p>");
}
I am writing all these into a new window.open object. The main problem is that pop-up blockers do not allow this functionality. So, is there any other way I can do this? I can't generate the html file physically, I need to generate it on the fly, so window.open is the only method I could think of. Are there any other ways I can accompolish this?
(I can bypass the pop up blocker by just using
w=window.open("somefile.html")
w.document.opne("somefile.html")
where somefile.html is any file. But I do not want to do it, it hardly seems a clean way.)
More over, For me to access the file, I have to host it on a server (I am currently using http-server offered by node for this) Is there any other alternative to this?
I do not want to use Jquery, I wish to accomplish all of this with vanilla javascript. But if there is a possibility of doing this with Jquery, please let me know.
Thank you very much :)

On principle, pop-up windows are blocked by all modern browsers. They'll ask you if you want to allow them, but otherwise they'll not allow them.
If it has to be another document, perhaps an iframe could be useful?
Here's a bunch of extra solutions:
Have a fake pop-up. Just a div with all the data which floats above your regular content. You can add an 'x' button to it for closing it and implement some drag-and-drop functionality. The visual effect is much the same, but the user can't treat it as an OS-level window.
Try to somehow integrate the content into the regular page. Either an iframe or just regular content. Modern design has passed the stage of needing pop-ups and other content outside of a single plane. Furthermore, on mobile it's unclear how pop-ups would work.
Open the content in a new tab. This is basically just using an <a> tag. You can put the content you wish to have in the fragment for the link, and the page you open can decode the fragment and show the info you want. Might not work with huge content.
Have a better flow for allowing pop-ups. Inform the user that your site needs pop-ups and make them disable it. One good way is to provide some button which triggers a pop-up, which will be blocked. Then inform them to tell the browser to allow the pop-up since most of them will show something about how the pop-up was blocked. Then you can show your regular pop-up without the risk of the user missing out on the data.

link to website automatically inserting text into textarea

On my website I want to link to a web-app, automatically inserting some text into a textarea.
Is it possible to link to the website doing something like this?
www.website.com/#document.getElementById('textarea').value ='inserted text';
This bookmarklet is working code, I just want to use a link to the website and somehow get it to run the bookmarklet automatically.
javascript:{document.getElementById('textarea').value = 'inserted text'; void(0)}
Any suggestions/ideas?

On my website I want to link to a web-app, automatically inserting some text into a textarea.
You cannot, unless that web-app provides a means for you to do so (for instance, passing information on a query string or otherwise as part of the URL). You can't create a link that runs JavaScript on the page after loading it, not without the page's cooperation.
On the off-chance that the target web-app is also under your control: You could, of course, add a feature to the web-app to do it. If so, be sure you just accept a value and don't allow executing arbitrary JavaScript code passed to you on the URL, that would be a Very Bad Idea unless the target page never shows anything user-specific (and probably even if it doesn't).

Multipage vs Single Page and Unobtrusive Javascript

I have a section of a site with multiple categories of Widget. There is a menu with each category name. For anybody with Javascript enabled, clicking a category reveals the content of the category within the page. They can click between categories at will, seeing the DOM updated as needed. The url is also updated using the standard hash/hashbang (if we are being Google-friendly). So for somebody who lands on example.com/widgets, they can navigate around to example.com/widgets#one, example.com/widgets#two, example.com/widgets#three etc.
However, to support user agents without Javascript enabled, following one of these category links must load a new page with the category displayed, so for someone without javascript enabled, they would navigate to example.com/widgets/one, example.com/widgets/two, example.com/widgets/three etc.
My question is: What should happen when somebody with Javascript enabled lands on one of these URLS? What should someone with Javascript enabled be presented with when landing on example.com/widgets/one for example? Should they be redirected to example.com/widgets#one?
Please note that I need a single page site experience for anybody with Javascript enabled, but I want a multi-page site for a user agent without JavaScript. Any answer that doesn't address this fact doesn't answer the question. I am not interested in the merits or problems of hashbangs or single-page-sites vs multi-page-sites.

This is how I would structure it:
Use HistoryJS to manage the URL. JS pushstate browsers got full correct URLs and JS non-pushstate browsers got hashed urls. Non-JS users went to the full URL as normal with a page reload.
When a user clicks a link:
If they have JS:
All clicks to other pages are handled by a function that prevents the default action, grabs the HREF and passes the URL to an ajax request and updates the URL at the same time. The http response for that ajax request is then parsed and then loaded into the content area.
Non JS:
Page refreshed as normal and loads the whole document.
When a page loads:
With JS: Attach an event handler to all your links to prevent the default so their href is dealt with via Ajax.
Without JS: Nothing. Allow anchors to work as normal.
I think you should definitely have all of your content accessible via a full, correct URL and being loading it in via ajax then updating the URL to reflect the address where you got your content from. That way, when JS isn't running, you don't have to change anything.
Is that what you mean?

Apparently your question already contains the answer. You say:
I need a single page site experience for anybody with Javascript enabled
and then ask:
What should someone with Javascript enabled be presented with when landing on example.com/widgets/one for example? Should they be redirected to example.com/widgets#one?
I'd say yes, they should be redirected. I don't see any other option, given your requirements (and the fact that information about JavaScript capabilities and the hash fragment of the URL are not available on the server side).
If you can accept relaxing the requirements a bit, I see another option. Remember when the web was crowded with framesets, and we landed on a specific frame via AltaVista (Google wasn't around yet!) search? It was common to see a header saying that page was supposed to be displayed as a frame, and a link to take the user to the frameset version.
You could do something similar: when scripting is available, detect that you're at example.com/widgets/one and add a link to the single-page version. I know that's not ideal, but it's better than nothing, and maybe better than a nasty client-side redirect.

Why should you need to redirect them to a different page. The user arrived at the page looking for an answer. He gets the answer even if he has javascript enabled. It doesn't matter. The user's query has been fulfilled.
But what would happen if the user lands on example.com/widgets#one ? You would need to set up an automatic redirect to example.com/widgets/one in that case. That could be done by checking the if javascript is enabled in the onload event and redirect to the appropriate page.

One way for designing such pages is to design without javascript first.
You can use anchors in the page so:
example.com/widgets#one
Will be a link to the element with id 'one'
Once your page works without javascript, then you add the javascript layer. You can prevent links to be followed by using the event.preventDefault.
(https://developer.mozilla.org/fr/docs/DOM/event.preventDefault), then add the desired javascript functionality.

vulnerabilities of letting user define innerHTML

Let's say I have a <textarea> and <div> element, and when the user puts html, CSS, or whatever they want), into the textarea, then their input is set as the innerHTML of the <div> element, using javascript.
What are the vulnerabilities of letting the user define the content of a <div> element?

If the content they enter does not leave the page, there is no more risk than them editing the DOM through firebug or the chrome inspector. If you take their input and then display it as is, that is a huge security risk especially when other users are on your website.

Well if you encode the contents so that any javascript that is in there won't execute then it should be safe.
If you don't then a user could upload javascript that would execute the next time another user views that page.
I want to modify my response to take into account #Brigham comments. Escape only works reliably if you are dealing with the the innerHTML of something like a div tab, if you are dealing with using a user generated value as a attribute or within a script tag then escaping/encoding won't work.
I'll refer you to the OWASP XSS guidance (that #Brigham originally brought to my attention) for more information: https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet#Untrusted_Data

The user can do cross-site scripting. It can inject malicious client-side code
Take a look at http://en.wikipedia.org/wiki/Cross-site_scripting

Whatever they want could include a <script> tag which pulls a .js file from their own server. Then if you show that content to another user, the script could do all kinds of things to extract information from the unsuspecting user.

How to display a form in any site's pages using a bookmarklet (like Note in Google Reader)?

In Google Reader, you can use a bookmarklet to "note" a page you're visiting. When you press the bookmarklet, a little Google form is displayed on top of the current page. In the form you can enter a description, etc. When you press Submit, the form submits itself without leaving the page, and then the form disappears. All in all, a very smooth experience.
I obviously tried to take a look at how it's done, but the most interesting parts are minified and unreadable. So...
Any ideas on how to implement something like this (on the browser side)? What issues are there? Existing blog posts describing this?

Aupajo has it right. I will, however, point you towards a bookmarklet framework I worked up for our site (www.iminta.com).
The bookmarklet itself reads as follows:
javascript:void((function(){
var e=document.createElement('script');
e.setAttribute('type','text/javascript');
e.setAttribute('src','http://www.iminta.com/javascripts/new_bookmarklet.js?noCache='+new%20Date().getTime());
document.body.appendChild(e)
})())
This just injects a new script into the document that includes this file:
http://www.iminta.com/javascripts/new_bookmarklet.js
It's important to note that the bookmarklet creates an iframe, positions it, and adds events to the document to allow the user to do things like hit escape (to close the window) or to scroll (so it stays visible). It also hides elements that don't play well with z-positioning (flash, for example). Finally, it facilitates communicating across to the javascript that is running within the iframe. In this way, you can have a close button in the iframe that tells the parent document to remove the iframe. This kind of cross-domain stuff is a bit hacky, but it's the only way (I've seen) to do it.
Not for the feint of heart; if you're not good at JavaScript, prepare to struggle.

At it's very basic level it will be using createElement to create the elements to insert into the page and appendChild or insertBefore to insert them into the page.

You can use a simple bookmarklet to add a <script> tag which loads an external JavaScript file that can push the necessary elements to the DOM and present a modal window to the user. The form is submitted via an AJAX request, it's processed server-side, and returns with success or a list of errors the user needs to correct.
So the bookmarklet would look like:
javascript:code-to-add-script-tag-and-init-the-script;
The external script would include:
The ability to add an element to the DOM
The ability to update innerHTML of that element to be the markup you want to display for the user
Handling for the AJAX form processing
The window effect can be achieved with CSS positioning.
As for one complete resource for this specific task, you'd be pretty lucky to find anything. But have a look at the smaller, individual parts and you'll find plenty of resources. Have a look around for information on modal windows, adding elements to the DOM, and AJAX processing.