xiplus

First status is not resolved if you request for **unprotection**. 

A simple workaround: https://github.com/wikimedia-gadgets/twinkle/blob/cbde9a53f9f92ed6c1a3e2350cfe528f8ad119a9/modules/twinkleprotect.js#L1487-L1491 Add the following code here. ```javascript var statusElement2 = rppPage2.getStatusElement(); statusElement.info('done'); statusElement2.info('done'); ```

I can reproduce it on 1.39.0-wmf.17. So I think it's not due to the API changes.

1. 確實這樣修改能夠處理 #50 中提到的情況，但對於已知封鎖狀況且仍要警告的使用者，會收到不必要的提醒 2. fetchBlockInfo 可以重用 block 模組的，不必寫新的 3. 在 Twinkle.warn.callback.evaluate 裡面檢查封鎖狀態就不會導致重複的程式碼

@hamishinyuu 應該調整xfd中各編輯的執行順序，即可解決該問題。

@hamishinyuu 如果先檢查歷史再標記，那麼自然就不會檢查到標記這筆編輯。「Twinkle目前會先嘗試尋找非重定向的版本當成建立者」是一個功能，因為有原本是重定向，後來改成條目的頁面，這時把非重定向版本當成建立者會比較好，當然也會有你說的問題存在，有好有壞，就看選擇哪個

@hamishinyuu 目前邏輯： - 第一個版本非重定向 -> 第一版本為建立者 - 所有版本為重定向 -> 第一版本為建立者 - 第一版本為重定向，後來為條目 -> **第一個非重定向版本**為建立者 morebits層面就是這麼做的

@hamishinyuu 調整檢查歷史與標記的執行順序才是真正的解方，你的方法在執行順序不穩定的情況下會導致新的問題，即若還沒標記就檢查歷史，對於後來不為重定向的頁面，將導致誤判第一版本(重定向版本)為建立者

還有 3. 在可檢查目標命名空間的前提下，直接`alert()`並中止提刪

產生視窗的時候不會檢查頁面內容，若要這樣做會有額外的API請求。