You have blockUI block the page with the message being an element a div with id #dialog for example. Inside that div there is a button that does the following:
Unblocks the page
Executes some functionality which may result to an error. For example a failed ajax call.
On that ajax failure callback you update an observable array with the error(-s) that occurred.
On that observable array there is a subscription that when the length of the array is > 0 it will block the page and have as block message a div with an id #errorDialog.
So far the flow seems logical.
But what is happening is this : While the unblock (reset function) is being executed within a setTimeout, the subscription notifier has been fired which invokes again the block. At this moment and before the new block is executed the blockUI.history has the #dialog element. The block continues execution and replaces the blockUI.history with the #errorDialog element. The reset function for the first unblock is being executed but because the $el.data('blockUI.isBlocked') = 1 the #dialog element will is never restored.
So the second time you try invoke the #dialog you get an error because the node does not exist anymore.
I had this same issue and was able to patch it. Diff patch is below
The code mostly attempts to account for everything. When you show a new block, and previous block that has not completed it's fadeout jumps to the end of the fadeout and runs the reset method. Then the reset is smart enough to see that a new block is in progress, so it doesn't reset all of the wrapper elements (which would mess up the new block). The only thing it fails to do is execute the code the restores the element to it's prior place in the DOM. I didn't see any dependencies on the order of which piece of code goes first, so I just moved the restore code to the top. That seems to fix it for me