不管你是不承認為彈出窗戶似的一種現代方式的黑死病，就猶如若蟲和布蘭妮的CD同樣，實事是，他們作惡已經有時候期了。很多基於網絡的應用都seo運用彈出窗戶做一點無用的事物，從顯露幫忙頁面到顯露各種不一樣商品圖片不等於。不幸運的是，假如客戶端的瀏覽器安裝了阻擋彈出窗戶的插件，況且拿獲了，那末，對於商家來說，對他們運用彈出窗戶就是在做無用功。

一種行得通的解決方案就是在你的網站滿眼都寫滿『此網站運用了彈出窗戶，請保證您沒有運用彈出窗戶阻截功能』的消息兒。不過這麼做，期望讓用戶在瀏覽你的網頁的時刻不運用彈出窗戶的功能仿佛好象不太事實。你需求做的就是檢驗測定用戶是否運用了阻截彈出窗戶的功能，使你的網站適合瀏覽需要。

運用一個彈出窗戶來阻擋彈出窗戶
我所挑選完成這個功能的方法就是打算去敞開一個彈出窗戶。當然，這就意味著在我編程過程中務必十分的謹慎，由於假如我不這樣做，在客戶端中或許便會顯露出來不正確。維持著這種心態，我安裝了Google Toolbar ，況且運用一個裝載事情處置器（onload event handler）來對頁面施行編碼，這個裝載事情處置器可以檢驗測定到阻擋彈出窗戶的軟件。這麼做的最後結果如Listing A和Listing B所示。

在Listing A中顯露的辦法是那一個裝載事情處置器（叫做setEvents）被擊中，它打算敞開一個在Listing B中顯露的popupChild.html頁面。這麼看起來這種方法足夠可以確認阻擋彈出窗戶的功能是否在運作，不過事物不老是這麼。這倚賴於這個中途阻擋功能安裝的沒有問題。我們需求的就是使子窗戶彈出來顯露『Hello，world！』還是啥子其他的物品。這個頁面運用了setTimeout辦法來延時調小曲用checkChild辦法；這就給彈出窗戶留出了變更父窗戶的一個掩飾的輸入對象況且關閉它自個兒所需求的時間。一朝這個辦公完成，checkChild辦法便會查緝掩飾輸入對象，明確承認子窗戶是否變更了它的內部實質意義。假如它的內部實質意義已經被改動過了，那末彈出窗戶功能便會發生效力，這就意味著客戶沒有運用中途阻擋功能。

在整個兒測試過程中，有兩個最難的局部，就是過訪父窗戶的掩飾輸入對象和估計彈出窗戶敞開的時間。第1個問題經過運用文檔對象板型的window.opener就很容易解決了。第二個局部就更艱難一點，畢竟在我運用這些個例子的時刻，瀏覽器和服務器都在同一臺機器上。所以，縱然這些個例子在我這處運行正常，可是，他們對於別人或許就不舒服合使用了。務必還要找到一條更好的方法。

一個更好的方法
對於JavaScript而言，有一件有趣兒的事物，就是它不受瀏覽器影響，它是相對完全一樣的。假如一個狀態在一個瀏覽器上顯露出來了，奇怪的是，在其他瀏覽器上顯露出來這個狀態的有可能性會細小。例如，運用對象編著警告代碼，在微軟的Internet Explorer 中會顯露『[object]』而在Mozilla中會顯露『[object Window]』。額外一個趣味的事物就是上面所說的的問題只會在對象開創了往後纔發生。大家可以參看Listing C的例子。我們需求注意上面所說的的問題，由於我們僅只是查緝是否敞開了阻擋彈出窗戶的功能，它僅只是一個空頁面。

我之所以編著這段代碼，是由於近來有一點研發者和技術支持擔任職務的人消耗的錢了三個鍾頭，在會展室中解決這個問題。遠端客戶堅決保持說他們沒有運用彈出窗戶的中途阻擋功能；一直到大家都沒精打采的時刻纔有人提出要查緝一下子客戶安裝的軟件。在靠近列表的最末端有一個給客戶電子郵件添加令人喜愛的笑臉兒的手續。只經過簡單的查緝就發覺，這個手續不止只有給電子郵件添加笑臉兒的功能，它同時還可以中途阻擋彈出窗戶。用戶安裝了這個物品，卻一丁點兒沒有醒悟，這就是我編著代碼所期望防止的問題。