Block & content caching causes incorrect email address substitutions (JavaScript replacement method)

filter.module caches strings passed through check_markup() by default, so nodes or custom blocks with emails in them will have their markup cached. This means that if that node body or block is displayed on a page that includes other email addresses formatted by invisimail (such as Views), the $counter variable may cause sha1() to generate the same ID twice causing an incorrect substitution.

I can reproduce this reliably by configuring the 'Full HTML' input format to use invisimail's JavaScript replacement filter and then creating a custom block (Full HTML) with an email address in it. Configure that block to appear above the content region on a Views page that also includes some invisimail-formatted email addresses. The first time this page loads all emails are substituted correctly because invisimail_encoder_js_entities_encode() was called both the block and each field in the Views. However on subsequent page views, check_markup() will have cached the result of invisimail_encoder_js_entities_encode() so it effectively always uses $counter = 1, but the Views isn't aware of this and it will also output the first field with $counter = 1 resulting in a HTML ID collision. Thus the email from the first Views field is placed in to the block.