Fighting with browser popup block


Recently in our project, we have a need of refactoring some old struct actions to rest based pages. This way we avoid multiple page navigation for our user so that all the stuff can be done in a single page.

One example is file download. Previously in the struts based app, if a page have 12 files. What user have to do is click the download link in the main page, if available, user will be taken to the download page where the real download link is, then download. if not available, user will be taken to a request page for confirmation and then once confirmed, to the download page to wait. So to download all the files, user have to constantly navigate between different pages with a lot of clicks which is kind of crazy. In the coming single page application, everything(request/confirm/download) is in the same page which is much better.


However, we hit one issue. When user click the download link, the same as the above flow, we first need to make an ajax call back to server to check, if not available, a modal will show up for confirming request. otherwise get the download id and open a new tab for download the stream. The problem comes from this point where the browser(chrome/FF, safari does not) will block the download tab from opening. Tried it both form submit and window open. What is really bad is in chrome the block notification is really not noticeable, which is a tiny icon on the upper-left where user can barely see.

check status

        this.requestDetail = function (requestObj, modalService) {
                function success(res) {
                    var status =;
                    switch (status) {
                        case 'AVAIL_NOT_REQ':
                            that.createNewRequest(requestObj, modalService);
                        case 'NO_DATA':
                            $.bootstrapGrowl('No data available!', {type: 'info'});
                        case 'EXISTING_RPT':
                        case 'PENDING':
                            //add user to notify list then redirect
                                function success(res) {
                                    var DETAIL_RUN_INTERVAL = 3;
                                    var minute = DETAIL_RUN_INTERVAL - % DETAIL_RUN_INTERVAL;
                                    $.bootstrapGrowl('Your detail data file will be ready in ' + minute + ' minutes.', {type: 'info'});
                        case 'ERROR':
                            $.bootstrapGrowl('Error Getting Detail data! Contact Admin or Wait for 24 hour to re-request.', {type: 'danger'});
                            $.bootstrapGrowl('Error Getting Detail data, Contact ADMIN', {type: 'danger'});
                function error(err) {
                    $.bootstrapGrowl('Network error or Server error!', {type: 'danger'});

with form

        this.downloadFile = function (requestId) {
            //create a form which calls the download REST service on the fly
            var formElement = angular.element("
            formElement.attr("action", "/scrc/rest/download/detail/requestId/" + requestId);
            formElement.attr("method", "get");
            formElement.attr("target", "_blank");
            // we need to attach iframe to the body before form could be attached to iframe(below) in ie8
            //call the service

With window

        this.downloadFile = function (requestId) {
            $'/scrc/rest/download/detail/requestId/' + requestId);


Turns out the issue is: A browser will only open a tab/popup without the popup blocker warning if the command to open the tab/popup comes from a trusted event. That means the user has to actively click somewhere to open a popup.

In this case, the user performs a click so we have the trusted event. we do lose that trusted context, however, by performing the Ajax request. Our success handler does not have that event anymore.

Possible Solutions

  1. open the popup on click and manipulate it later when the callback fires

      var popup = $'','_blank');
      popup.document.write('loading ...');
        popup.location.href = '/scrc/rest/download/detail/requestId/' +;
        // other:

    this will work but not elegant since it opens a tab and close instantly but still create a flash in browser that user could notice.

  2. you can require the user to click again some button to trigger the popup. This will work because we could update the link if existing then user click again, we init the download so popup is triggered by user directly. But still not quite user friendly

  3. Notify user to unblock our site.
    This is eventually what we do. So we detect on the client side if popup is blocked. If so, we ask user to unblock our site in setting. The reason we use this is the unblock/trust action is really a one time thing that browser will remember the behavior and will not bother user again.

            this.downloadFile = function (requestId) {
                var downloadWindow = $'/scrc/rest/download/detail/requestId/' + requestId);
                if(!downloadWindow || downloadWindow.closed || typeof downloadWindow.closed=='undefined')
                    $.bootstrapGrowl('Download Blocked!<br\> Please allow popup from our site in your browser setting!', {type: 'danger', delay: 8000});

Long Text Wrapping in ie9/10 inside table td

Both IE 9 and 10 seem to have problem wrapping long text inside table td element, even we explicitly set the the word-wrap CSS property.

Turns out the solution is we also have a set with and table-layout css to the wrapping table.

/* Both of them are Necessary.*/
.long-text-table {  


<table class="long-text-table">
   <div class="long-text-wrapper"> REALLY LONG TEXT NEED TO WRAP</div>

execution time of JavaScript code in page load processde

In that short period of time between you wanting to load a page and your page loading, many relevant and interesting stuff happen that you need to know more about. One example of a relevant and interesting stuff that happens is that any code specified on the page will run. When exactly the code runs depends on a combination of the following things that all come alive at some point while your page is getting loaded:

  • The DOMContentLoaded event
  • The load Event
  • The async attribute for script elements
  • The defer attribute for script elements
  • The location your scripts live in the DOM

Don’t worry if you don’t know what these things are. You’ll learn (or re-learn) what all of these things do and how they impact when your code runs really soon. Before we get there, though, let’s take a quick detour and look at the three stages of a page load.

Stage Numero Uno

The first stage is when your browser is about to start loading a new page:

the first stage

At this stage, there isn’t anything interesting going on. A request has been made to load a page, but nothing has been downloaded yet.

Stage Numero Dos

Things get a bit more exciting with the second stage where the raw markup and DOM of your page has been loaded and parsed:

the DOM is loaded

The thing to note about this stage is that external resources like images and stylesheets have not been parsed. You only see the raw content specified by your page/document’s markup.

Stage Numero Three

The final stage is where your page is fully loaded with any images, stylesheets, scripts, and other external resources making their way into what you see:

the final stage

This is the stage where your browser’s loading indicators stop animating, and this is also the stage you almost always find yourself in when interacting with your HTML document.

Now that you have a basic idea of the three stages your document goes through when loading content, let’s move forward to the more interesting stuff. Keep these three stages at the tip of your fingers (or under your hat if you are wearing one while reading this), for we’ll refer back to these stages a few times in the following sections.

The DOMContentLoaded and loadEvents

There are two events that represent the two importants milestones while your page loads. The DOMContentLoaded event fires at the end of Stage #2 when your page’s DOM is fully parsed. The load event fires at the end of Stage #3 once your page has fully loaded. You can use these events to time when exactly you want your code to run.

Below is a snippet of these events in action:

document.addEventListener("DOMContentLoaded", theDomHasLoaded, false);
window.addEventListener("load", pageFullyLoaded, false);
function theDomHasLoaded(e) {
    // do something
function pageFullyLoaded(e) {
    // do something again

You use these events just like you would any other event, but the main thing to note about these events is that you need to listen to DOMContentLoaded from the document element and load from the window element.

Now that we got the boring technical details out of the way, why are these events important? Simple. If you have any code that relies on working with the DOM such as anything that uses the querySelector or querySelectorAllfunctions, you want to ensure your code runs only after your DOM has been fully loaded. If you try to access your DOM before it has fully loaded, you may get incomplete results or no results at all.

A sure-fire way to ensure you never get into a situation where your code runs before your DOM is ready is to listen for the DOMContentLoaded event and let all of the code that relies on the DOM to run only after that event is overheard:

document.addEventListener("DOMContentLoaded", theDomHasLoaded, false);
function theDomHasLoaded(e) {
    var images = document.querySelectorAll("img");
    // do something with the images

For cases where you want your code to run only after your page has fully loaded, use the load event. In my years of doing things in JavaScript, I never had too much use for the load event at the document level outside of checking the final dimensions of a loaded image or creating a crude progress bar to indicate progress. Your mileage may vary, but…I doubt it 😛

Scripts and Their Location in the DOM

In the Where Should Your Code Live tutorial, we looked at the various ways you can have scripts appear in your document. You saw that your script elements’ position in the DOM affects when they run. In this section, we are going to re-emphasize that simple truth and go a few steps further.

To review, a simple script element can be some code stuck inline somewhere:

var number = Math.random() * 100;
alert("A random number is: " + number);

A simple script element can also be something that references some code from an external file:

Now, here is the important detail about these elements. Your browser parses your DOM sequentially from the top to the bottom. Any script elements that get found along the way will get parsed in the order they appear in the DOM.

Below is a very simple example where you have many script elements:

<!DOCTYPE html>
        console.log("inline 1");
        console.log("inline 2");
        console.log("inline 3");

It doesn’t matter if the script contains inline code or references something external. All scripts are treated the same and run in the order in which they appear in your document. Using the above example, the order the scripts will run is: inline 1, external 1, inline 2, external 2, and inline 3.

Now, here is a really REALLY important detail to be aware of. Because your DOM gets parsed from top to bottom, your script element has access to all of the DOM elements that were already parsed. Your script has no access to any DOM elements that have not yet been parsed. Say what?!

Let’s say you have a script element that is at the bottom of your page just above the closing body element:

<!DOCTYPE html>
        Quisque faucibus, quam sollicitudin pulvinar dignissim, nunc velit
        sodales leo, vel vehicula odio lectus vitae mauris. Sed sed magna
        augue. Vestibulum tristique cursus orci, accumsan posuere nunc
        congue sed. Ut pretium sit amet eros non consectetur. Quisque
        tincidunt eleifend justo, quis molestie tellus venenatis non.
        Vivamus interdum urna ut augue rhoncus, eu scelerisque orci
        dignissim. In commodo purus id purus tempus commodo.
    <button>Click Me</button>
    <script src="something.js"></script>

When something.js runs, it has the ability to access all of the DOM elements that appear just above it such as the h1, p, and button elements. If your script element was at the very top of your document, it wouldn’t have any knowledge of the DOM elements that appear below it:

<!DOCTYPE html>
        Quisque faucibus, quam sollicitudin pulvinar dignissim, nunc velit
        sodales leo, vel vehicula odio lectus vitae mauris. Sed sed magna
        augue. Vestibulum tristique cursus orci, accumsan posuere nunc
        congue sed. Ut pretium sit amet eros non consectetur. Quisque
        tincidunt eleifend justo, quis molestie tellus venenatis non.
        Vivamus interdum urna ut augue rhoncus, eu scelerisque orci
        dignissim. In commodo purus id purus tempus commodo.
    <button>Click Me</button>

By putting your script element at the bottom of your page as shown earlier, the end behavior is identical to what you would get if you had code that explicitly listened to the DOMContentLoaded event. If you can guarantee that your scripts will appear towards the end of your document after your DOM elements, you can avoid doing the whole DOMContentLoaded approach described in the previous section. Now, if you really want to have your script elements at the top of your DOM, ensure that all of the code that relies on the DOM runs after theDOMContentLoaded event gets fired.

Here is the thing. I’m a huge fan of putting your script elements at the bottom of your DOM. There is another reason besides easy DOM access that I prefer having your scripts live towards the bottom of the page. When a script element is being parsed, your browser stops everything else on the page from running while the code is executing. If you have a really long-running script or your external script takes its sweet time in getting downloaded, your HTML page will appear frozen. If your DOM is only partially parsed at this point, your page will also look incomplete in addition to being frozen. Unless you are Facebook, you probably want to avoid having your page look frozen for no reason.

Script Elements, Defer, and Async

In the previous section, I explained how a script element’s position in the DOM determines when it runs. All of that only applies to what I call simple script elements. To be part of the non-simple world, script elements that point to external scripts can have the defer and async attributes set on them:

These attributes alter when your script runs independent of where in the DOM they actually show up, so let’s look at how they end up altering your script.


The async attribute allows a script to run asynchronously:

If you recall from the previous section, if a script element is being parsed, it could block your browser from being responsive and usable. By setting the asyncattribute on your script element, you avoid that problem altogether. Your script will run whenever it is able to, but it won’t block the rest of your browser from doing its thing.

This casualness in running your code is pretty awesome, but you must realize that your scripts marked as async will not always run in order. You could have a case where several scripts marked as async will run in a order different than what they were specified in your markup. The only guarantee you have is that your scripts marked with async will start running at some mysterious point before the load event gets fired.


The defer attribute is a bit different than async:

Scripts marked with defer run in the order in which they were defined, but they only get executed at the end just a few moments before the DOMContentLoadedevent gets fired. Take a look at the following example:

<!DOCTYPE html>
    <script defer src="external3.js"></script>
        console.log("inline 1");
    <script src="external1.js"></script>
        console.log("inline 2");
    <script defer src="external2.js"></script>
        console.log("inline 3");

Take a second and tell the nearest human / pet the order in which these scripts will run. It’s OK if you don’t provide them with any context. If they love you, they’ll understand.

Anyway, your scripts will execute in the following order: inline 1, external 1,inline 2, inline 3, external 3, and external 2. The external 3 and external 2 scripts are marked as defer, and that’s why they appear at the very end despite being declared in different locations in your markup.


In the previous sections, we looked at all sorts of factors that influence when your code will execute. The following diagram summarizes everything you saw into a series of colorful lines and rectangles:

summary of when your code will run

Now, here is probably what you are looking for. When is the right time to load your JavaScript? The answer is…

  1. Place your script references below your DOM directly above your closingbody element.
  2. Unless you are creating a library that others will use, don’t complicate your code by listening to the DOMContentLoaded or load events. Instead, see the previous point.
  3. Mark your script references with the async attribute.
  4. If you have code that doesn’t rely on your DOM being loaded and runs as part of teeing things off for other scripts in your document, you can place this script at the top of your page with the async attribute set on it.

That’s it. I think those four steps will cover almost 90% of all your cases to ensure your code runs at the right time. For more advanced scenarios, you should definitely take a look at a 3rd party library like require.js that gives you greater control over when your code will run.


Another good discussion on the sequence of rendering html

My another post also has some detail on the browser side

form submit on enter when one input text

Got an odd behavior today when dealing with a form which has only one input.

The input binds to a js function to judge if it is key==13, we do tweak the input params and submit. However everytime we hit enter, even before executing the js function, the form has already been submitted to the server.

Turns out:

In the HTML 2.0 specification, in the section entitled Form Submission, logically enough:

When there is only one single-line text input field in a form, the user agent should accept Enter in that field as a request to submit the form.

So to prevent this. a easy way is to put a hidden input box in the form.

<input class="hide"/>

Hide is just a bootstrap class which has

display: none!important;

angularjs bootstrapui print iframe modal

1. Print modal fit in one screen

If the content of the modal is in one screen, we could just put a css in the modal template to hide all other content

/*general styles*/
/* print styles*/
@media print {
 .printable {display:block;}
 .screen {display:none;}

Or put a wrap to the parent content and assign an id to it then in the print css, use the id and set it as display: none

2. Print modal with long iframe

If we load a iframe with long content in the modal, the above print will just print the on-screen part content which is not desirable since we definite want to print the whole iframe.

2.1 add a function in the modal controller

	$scope.printIframe = function (iFrameId) {
		var frame = window.frames[iFrameId];
		if (!frame) {
			console.log('No iFrame found for id: ' + iFrameId);

2.2 assign id to the iframe and call the print function from the template

      <iframe ng-src="{{request.url}}" frameborder="0" style="overflow-x:hidden; height: 100%; width: 100%;" id="modalIframe" name="modalIframe"></iframe>


<button class="btn btn-primary" ng-click="printIframe('modalIframe')">Print</button>

The other part is just regular setup

//popup for detail data
$scope.openDetail = function (mmid) {
//	$event.preventDefault();
	var detailUrl = '/someurl?rptid=' + $scope.rptId + '&firmname=' + $scope.reportData.firmName + '&mmid=' + mmid;
	$scope.detailRequest = {url:detailUrl};
		templateUrl: 'detailModalContent.html',
		controller: 'ModalInstanceCtrl',
		resolve: {
			request: function () {
				return $scope.detailRequest;
		// set width to 900px(bootstrap);
		size: 'lg'

3. Print modal with long content(no iFrame)

The problem here is if the content is longer than the modal view port, then we can only see the viewable area in the print.
The only CSS that works for me when the modal is LONGER than the view port is:

@media print {
    .modal {
        position: absolute;
        left: 0;
        top: 0;
        margin: 0;
        padding: 0;
        overflow: visible!important;

Note: position:absolute and overflow:visible are MUST have.

version compress css js with maven

One problem in release is the user still caches our resources that our new look/feel can not be presented unless user hard refresh the browser.

To overcome this, several ways:

1. append a query string(like UUID) to the resource

This is good if you want to user download a fresh copy each request. If we randomize the query string with every request, this will defeat caching entirely. This is rarely/never desirable for a production application’s CSS.

Add a <%@ page import=”java.util.UUID” %> to the head of jsp and append the uuid to the resource by adding:

<script type=”text/javascript” language=”javascript” src=”dir/gwt_whatever.nocache.js?<%=UUID.randomUUID().toString()%>“></script>

2. use a new name each build

The yuicompressor-maven-plugin has a <suffix> option to let you add suffix to the resource after compression.

3.append a query String (like build date) to the resource

This is actually the way i used. The good part is it still keeps the file name, user could still get a new version for the each release. To achieve this.

3.1 add a property in the pom. This way we have a timestamp var available.


3.2 add resource in the war plugin to filter the web.xml so that we could replace variables

    <!--compressed resources, see yuicompressor-maven-plugin below for detail-->
    <!--this is to replace the ${...} with our maven properties. For example the timestamp property replacement in the web.xml-->

For the yuicompress maven plugin config:

        <!--maven war plugin will overwrite the file we compressed, so we add a 'webappDirectory' here to put them into the /min directory and
					    then in the maven-war-plugin define this /min directory as a <resource> to make sure they could be included-->

3.3 Add an init-param in the web.xml. Note the ${timestamp} will be replaced by the maven time stamp because of the filtering config we have in 3.2 and the property definition in 3.1


3.4 now the ‘buildTimeStamp’ is available for us in the jsp context, we just need to include it:

<link rel="stylesheet"
href="/css/whatever.css?build=<c:out value='${initParam.buildTimeStamp}'/>"


A fun day with IE8

I had a previous post describing how to export html to excel/pdf with angularjs and servlet(spring mvc)

When our qa was testing in IE8, the whole thing does not work. Spent almost a day to figure out all the issues:

IE8 does not work with Angularjs 1.3

I was previously using Angualrjs 1.3.2. Now I have to downgrade to 1.2.28.

IE8 Iframe  cannot append element

Basically i got:

‘ error:unexpected call to method or property access’

when trying to append my form to the hidden iFrame.

It turns out in IE8, you cannot append element to the iframe before the iframe is explicitly appended to the dom. So i have to change the order of appending: body.append(iframe) first, then iframe.append(form).

IE8 does not send parent url as referrer from iFrame

We have some referrer check on the server side, my rest call fails due to lack of referrer. You can overcome this either by manually adding referrer OR just change the server side code to ignore REST paths.

 does not give you xhtml when innerHTML() is called

This is hilarious! when you call innerHTML of an element, IE8 will remove the surrounding quotes of ‘class’ if it only contains 1 classname. For example: class=”ng-binding” becomes class=ng-binding. This may looks trivial, but for flying sourcer which uses iText as rendering engine, XHTML is required!  Hence I have to use jTidy to clean the html to the Xhtml:

        Tidy tidy = new Tidy();
        // we do not need the DocType which would cause error(in iText) which is due to the Struts' dependency on xalan 2.5.1
        ByteArrayOutputStream outputStream = new ByteArrayOutputStream();
        tidy.parseDOM(new ByteArrayInputStream(sb.toString().getBytes(Charsets.UTF_8)), outputStream);

        String xhtmlResult = outputStream.toString();

Since our app is still using Struts1 as server side mvc, i have to omit the DocType, otherwise the xalan 2.5.1 will complain.

NAMESPACE_ERR: An attempt is made to create or change an object in a way which is incorrect with regard to namespaces.

You can also exclude it in the POM’s Struts dependency and use the new version of xalan.

IE8 cannot download file without explicitly set Pragma header or remove it

I tested the download in the IE9 using IE8 mode. But when it comes to real IE8, The following error pops up :

IE : Unable to download * from *. Unable to open this Internet site. The requested site is either unavailable or cannot be found

It turns out you have to remove the Pragma:nocache from the header or change it to something else like cache/token… So

Solution 1: remove the ‘pragma’ header and set the ‘Cache-Control: no-store, no-cache, must-revalidate’

Solution 2: set the pragma to cache/token or anything other than no-cache and set the  Cache-Control:private’ .This allows certain caching and might not fit with your security needs, then use solution 1.

ie1 ie2 ie3