就我所知 目前的borwser對於每一段script 都是先parse (js特殊的hoist現象就是這裡發生的) 之後執行top-level應該執行的東西(load完後馬上要執行的) 接著開始listen event 每一段script block都是一起parse 然後執行 接著繼續下面的HTML Parse (script blocking就是這樣產生的 所以要放下面) 在這個parse過程 他會調整你的code 像是一個context裡的變數會幫你拿到最上面幫你宣告好之類的(hoist) 在之前的例子裡 一個iframe只有一行code 我想有99.99%的機率是ABCD 不管哪個browser應該都是這樣 第一個iframe parse完就開始 run了 第二個iframe說甚麼也不會比較快 (CDAB) 然後只有兩個log間也是不太可能被插隊 (ACDB)(ACDB)..etc alert(confirm prompt等等)的例子為甚麼混淆視聽 是因為這和browser本身UI的實作有關 而和他對Javascript的實作關聯不大 (像是跑出來時 不接受你按按鍵 這是browser的UI問題 而不是js問題) 在我的FF中 有看到alert A一閃 然後被C蓋住 我想他就是會讓後來出現的alert蓋住前面 CD按完就可以看到下面的A了 A按了當然就跑出接下來的B 而IE的例子中 好像不可以同時有兩個alert 我甚至不知道他有沒有multi-thread 因為第一個alert A出現之後 如果有multi-thread 緊接著alert C應該也蠢蠢欲動才是 但也有可能 他的alert出現時 整個HTML parse thread也停下來了 實驗是在你alert後面放html 按下去前看不到 (但rende和parse又是不一樣的東西 時間也不會一樣 所以這無法證明) 所以A按完後 為甚麼是B而不是C 這我目前就不知道了 只能說和他的alert實作有關 所以用alert去看這種thread的問題 我覺得是會有很多誤導的 ※ 引述《tyx (?????????????????)》之銘言： : 在同一個 page 裡 只有一個 thread 在執行 : 不管有幾個 iframe 都一樣 (但 Opera 不是 推文有連結) : 那為何有不同的行為 : 我以 senser 的範例作說明 : 1. FireFox : 當 FF 執行 $('ifa').src = 'javascript:alert("A");alert("B")'; 時 : 會先 parse 這段 javascript 但並不會立刻執行此 js : 而是產生一個 '要執行此 js 的 event'（暫時稱為 event1） 在 event queue 裡 : 之後執行下一行 $('ifb').src = ... 並產生 event2 : 然後 thread 回去 event queue 取到 event1 並執行 alert("A") : 此時會看到 alert("A") 的 dialog : 此 dialog 出現時 除了此 dialog 以外 page 的 input 都會被 disabled : 所以不會有其他 UI events : 當 alert("A") dialog 執行時 內部也有個 event loop 在取 event 出來執行 : 所以會取到 event2 並執行 alert("C") : 當你按掉 alert("C") 之後 會立刻執行 alert("D") : 再按掉 alert("D") 又會回到 alert("A") 的內部 event loop : 再按掉 alert("A") 之後 會執行 alert("B") : 所以會看到 alert("A") 出現後 立刻出現 alert("C") : 然後結束 alert("C") 立刻出現 alert("D") : 然後結束 alert("D") 回到 alert("A") : 然後結束 alert("A") 立刻出現 alert("B") : 2. IE : 當 IE parse 完 js 之後會立刻執行 所以才會 : 出現 A 按掉A之後出現 B 按掉 B 之後出現 C 按掉 C 之後出現 D : ps: 至於 console.log("A") 會依序出現 : 是因為執行 console.log("A") 時 : 並不會偷偷跑 event loop : 所以 C D 不會偷跑囉 : ※ 引述《senser (彷彿曾經一起死過)》之銘言： : : alert在不同thread下(iframe)到底會怎樣我倒是沒有研究過 : : 我把您的code改成 : : var $ = function(id){return document.getElementById(id);}; : : $('ifa').src = 'javascript:alert("A");alert("B")'; : : $('ifb').src = 'javascript:alert("C");alert("D")'; : : 我剛剛試的結果 : : 意外發現FF下會先出現A(很快來不急按) 然後被C蓋住 之後D 回到A 最後B : : 這有點兩個alert一起出現的味道(只是被蓋住了) : : IE的結果就是同一時間只有一個alert 然後ABCD : : 這跟browser的實作有關 : : 我只能推斷 FF的alert出現時 容許其他的thread的alert也出現 : : (不確定是 出現兩個 一個被"蓋住" 或是同一個alert box然後內容被取代 : : 在我的FF中沒辦法用滑鼠移動alert box) : : 而IE的UI不容許這種情況出現 : : 然後回到問題 : : 在兩個thread併行下 ACBD交叉出現我覺得是有可能的 : : (但我不知道哪個browser可以 也沒試著去製造出來過) : : 但是在一個event-driven 的single thread中(前篇文章) 是不會發生的 : : 一個callback只會執行完在去執行下一個 不會互相跳來跳去 : : ============== : : 各家瀏覽器對alert的實作略有不同 : : 一般當alert出現時 產生alert那段程式會暫停 直到按了之後在繼續 : : 然而有些瀏覽器在alert出現時 會繼續dispatch的動作 : : dispatch進去的handler中 如果是UI trigger的 他不會執行 : : 但如果是non-UI 的event handler 像是ajax的callback : : 在某些browser中是會同時執行的 即使你的alert還掛在那裏 : : 所以用alert debug的習慣是非常不好的 : : 在你還沒按下時 可能有東西就跑起來了 : : 以致於你alert出來的變數也有可能被影響 而看到錯的值 : : 真的用在application中更是有可能造成錯誤 (confirm,prompt等等都一樣) : : 根據你甚麼時候按下去 你的那段程式才會繼續跑 : : 但是你的non-UI event在背後一樣的dispatch然後fire (如page load,timeout) : : 所以希望大家改掉直接用這種東西當UI的習慣 避免不必要的timing issue : : 全部的UI都要自己兜出來比較好 : : === : : 這裡就有現成的例子 : : 剛剛用FF看 好像是CDAB (按掉CD時A或若隱若現) : : 如果你沒有注意那個若隱若現的A 你就會以為他的順序真的是CDAB這樣 : : 然而如果你改成console.log("A") : : 就會知道他的真正的順序是ABCD : : 給大家參考:D --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 71.107.60.113