我寫的一個網頁採用BlockUI的方式顯示一個嵌在IFrame裡的子網頁，以進行一些額外的資料輸入操作，操作完成後則以$.unblockUI()收掉子網頁，將控制權交回原網頁。
起初有一個使用者跟我抱怨，IFrame子網頁裡的Textarea，在重覆開啟關閉後，子網頁的Textarea、Textbox就都無法輸入文字(點選後不會顯示文字輸入游標)。試著在自己公司的電腦上進行過同樣的操作，並沒有發生無法輸入的狀況，加上其他使用者都無人回報類似錯誤，因此被我判定為少數Client環境問題怪異的個案，未再深究。
不料，今天在家裡寫網頁時，家裡的Vista x64+IE8也冒出同樣狀況: 重覆開啟子網頁後，Textarea、Textbox便無法再取得焦點輸入文字。使用FF、Chrome開啟該網頁操作，並不會有任何問題... orz
媽呀，這個設計模式已被我應用在好幾個專案裡，要是IE用起來有問題，對我來說將是一埸災難。更何況，網頁其他操作正常，就只有TextArea、TextBox在搞自閉，這是什麼鳥狀況，虧IE8可以搞出來。
且慢，李組長眉頭一皺，覺得案情並不單純...
深入做了幾個實驗，發現無法輸入的Textarea，click事件是活著的，disabled/readonly屬性也未被設定；而同網頁上的Button、Checkbox、Radio Button盡皆正常，這實在太詭異了。
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title></title>
<script src="../js/jquery.js" type="text/javascript"></script>
<script src="../js/jquery.blockUI.js" type="text/javascript"></script>
<script type="text/javascript">
function ShowIFrame(url) {
var frmHtml =
"<iframe style='width: 100%; height:100%;' src='" + url + "'></iframe>";
$.blockUI({
css: { width: '200px', height: '200px' },
message: frmHtml
});
}
$(function() {
$("#btnShow").click(function() {
ShowIFrame(location.href + "?x=2");
});
$("#btnClose").click(function() {
parent.eval("$.unblockUI();");
});
if (parent.window != window)
$("#btnShow").hide();
else {
$("#btnClose").hide();
$("#ta").hide();
}
});
</script>
</head>
<body>
<input type=button value='Open SubWin' id="btnShow"/>
<input type=button value='Close SubWin' id="btnClose"/>
<textarea id="ta"></textarea>
</body>
</html>
Skype? 我的網頁被Add-on加料了! 會不會TextArea的問題也與Add-on有關? 要驗證這個問題最快的方法就是開啟Accessories/System Tools/Internet Explorer (No Add-ons)，在沒有Add-on的狀態下開啟IE，再試了一次問題網頁，欄位無法輸入的症狀不藥而瘉。如此，便可確定問題出在Add-on身上。
換句話說，在本次事件中，IE無罪，問題出在Add-on上；若沒有李組長明察秋毫(遠目)，IE恐怕會承受這不白之冤。不過我想，IE此刻的心情應該像被罵慣了的何大人，山西布政司放的屁算他頭上也懶得辯解吧... (話雖如此，IE常跟其他瀏覽器行為不同，還是讓我很想揍它)
原本提供擴充應用空間的Add-on設計美意，隨著各家廠商開發出五花八門的外掛，安裝在各式各樣的環境組合中，常演變出難以預期的結果。依微軟自己的統計，有很大的比例，IE的Crash主因常出在外掛上，而非IE本體，這也是為什麼程式集中會特別提供一個IE無外掛執行模式的原因。