瀏覽器裡同一個節點上 JavaScript 的事件觸發順序

瀏覽器裡 JavaScript 的事件觸發順序是先 capture 再 bubble,這個在「Event order」這邊就有一些歷史解釋,IE8 以前只有 capture 模式,到了 IE9+ 才支援,在「Event API: bubbles」這邊也可以看到。

但如果是同一個節點上面的事件觸發順序 (假設同樣是 capture 或是同樣是 bubble),在「Are event handlers in JavaScript called in order?」這邊有些整理資料。

2000 年的「Document Object Model (DOM) Level 2 Events Specification」這邊提到沒有定義順序:

When the event reaches the target, any event listeners registered on the EventTarget are triggered. Although all EventListeners on the EventTarget are guaranteed to be triggered by any event which is received by that EventTarget, no specification is made as to the order in which they will receive the event with regards to the other EventListeners on the EventTarget.

在早期的 draft「Document Object Model (DOM) Level 3 Events Specification」裡面可以看到:

Next, the implementation must determine the current target's candidate event listeners. This must be the list of all event listeners that have been registered on the current target in their order of registration. [HTML5] defines the ordering of listeners registered through event handler attributes.

但在最新的「UI Events」(要注意這還是 draft,在 2016 年更新的) 則是拿掉了這段。

所以在設計架構時,正常還是得保守的假設沒有保證執行順序...

uBlock Origin 1.48.0 的改善

Hacker News 上看到「uBlock Origin 1.48 adds readiness status, code viewer, and other fixes (github.com/gorhill)」這則消息,uBlock Origin 在 1.48 有個蠻重要的 UI/UX 改善 (Readiness status at browser launch)。

uBlock Origin 預設會搭配「工人智慧」維護的列表,這些列表通常都不小,在剛開瀏覽器,還在讀取的過程中去看網站會遇到阻擋不完整的情況。

先前沒有辦法知道這個問題,在這版加上了對應的 icon color 來解決,黃色表示還在讀:

這時候跑去逛網站的話會出現驚嘆號:

讀取完後 icon 會變成標準的紅色,但驚嘆號仍然會留著,表示這個頁面未必有完整過濾:

正常有阻擋的則是這樣:

理論上可以減少 bug report XDDD

To reduce the number of reports caused by this issue which is outside of uBO's control, uBO's toolbar icon will now reflect its readiness status at browser launch.

如果把 OpenSSL 包裝成 GUI 版本

Hacker News Daily 上看到這則,蠻有趣的嘗試,如果幫 OpenSSL 包裝成 GUI 版本的話,可能會長的樣子:「If OpenSSL were a GUI」,而 Hacker News 上對應的討論在「If OpenSSL were a GUI (smallstep.com)」這邊可以看到。

要注意的是這是 mock 出來的圖,而不是真的有人這樣幹了一個版本出來。主要是在帶出 OpenSSL 這個工具極度複雜的問題,另外也因此帶出 GUI application 的取捨問題,在 Hacker News 上的討論都有人提出來。

不過讓我吸引的點反而是 mock UI 的選擇上,看起來作者選了 Platinum 風格 (Mac OS 8 & Mac OS 9),在維基百科的「Appearance Manager」這個頁面有提到:

The default look and feel of the Appearance Manager in Mac OS 8 and 9 is Platinum design language, which was intended to be the primary GUI for Copland.

是個讓人懷念的風格,而且意外的看起來反而讓 GUI 柔和不少,而且其實就功能性來說還蠻不錯的?

Firefox 的 UI/UX 歷史

Hacker News 首頁上看到「Firefox UI/UX History (github.com/black7375)」這篇,整理了 Firefox 的 UI/UX 歷史,裡面也試著分析各個不同版本的優缺點。

話說看到這個最早的版本的 screenshot 讓人懷念 (還叫做 Phoenix 的版本):

裡面也提到了一些 fork,像是「Early (v1 ~ v3)」這個 UI 版本的 fork 還可以在 SeaMonkey 看到。

到了「Classic (v4, 2011.3)」這個版本,目前還有在維護的 fork 則是 Pale Moon,不過核心的部份沒有跟上,很多網站的新功能是沒辦法用的。

接著是「Australis (v29, 2014.04)」這個版本,目前已經沒有在維護的 fork 了,2021 年年底 Basilisk 宣佈停止維護。

然後是「Photon (v57, 2017.11)」這個版本,目前還有在維護的 fork 是 Waterfox 的 G3 系列。

目前最新的一個是「Proton (v89, 2021.06)」這個版本。

網頁的死亡線

是一篇 2017 年的文章,前幾天在 Hacker News 上重新被提出來:「The Line of Death (2017) (textslashplain.com)」。

文章開頭在講瀏覽器 UI 的信任區,這條線以上是 native UI,以下是網站可以任意操控的內容:

所以 UI 上面有些小細節讓你區分,但這其實對不是專精 phishing 的人很不友善:

另外當然就會提到 browser-in-a-browser (以及 picture-in-picture) 類的 phishing 了:

另外提到了 Fullscreen API,這使得信任區間變成 0:

提到 Fullscreen API 所以就去翻資料,意外發現 IE11 居然支援這組 API,雖然是帶 ms 的 prefix,而且不支援一些輔助性的功能 (像是傳回 Promise object)。

這些 UI 與 security 類的問題,主要還是得考慮到使用者未必那麼熟悉,以及就算有經驗的人也很有可能不小心中獎...

jQuery UI 與 jQuery Mobile 進入維護模式

OpenJS Foundation (先前的 jQuery Foundation) 宣佈 jQuery UIjQuery Mobile 進入維護模式:「jQuery maintainers update and transition jQuery UI as part of overall modernization efforts」、「jQuery maintainers continue modernization initiative with deprecation of jQuery Mobile」。

jQuery UI is in maintenance-only mode. Users should not expect any new releases, though patches may be issued to resolve critical security, interoperability, or regression bugs.

The team announced that the cross-platform jQuery Mobile project under its umbrella is fully deprecated as of October 7, 2021.

應該就是沒有足夠的動能繼續開發了,維持個窗口在有 security issue 時處理...

Google Chrome 的顯示完整 URL 的方式又改了...

剛剛更新 Google Chrome 後發現 address bar 又被動手腳了 (我是 beta channel 的版本),在網址列上的 Protocol (Scheme) 與 www subdomain 不見了,而本來裝 Suspicious Site Reporter 可以讓 URL bar 恢復的方式也失效了。

翻了一下老問題「Chrome address bar no longer shows protocol or www subdomain」,裡面有提到新的解法 (他寫的當下) 是「The current solution in Chrome 83+」這個,直接在網址列上選右鍵,可以看到 Always show full URLs 這個選項,這是整個 Google Chrome 的選項,而非單一站台選項,選下去後就生效了:

而本來的 Suspicious Site Reporter 也可以拔掉了 (沒有用處了)。

Google Chrome 又要對 URL 搞事了...

上個禮拜鬧的頗兇的話題,Google Chrome 又要對 URL 搞事了:「Google resumes its senseless attack on the URL bar, hides full addresses on Chrome 85」。

這次是打算把整個 path 藏起來:

A few new feature flags have appeared in Chrome's Dev and Canary channels (V85), which modify the appearance and behavior of web addresses in the address bar. The main flag is called "Omnibox UI Hide Steady-State URL Path, Query, and Ref" which hides everything in the current web address except the domain name. For example, "https://www.androidpolice.com/2020/06/07/lenovo-ideapad-flex-5-chromebook-review/" is simply displayed as "androidpolice.com."

來繼續等 3rd-party browser 成熟...

Google Chrome 78 又要搞事把 www 開頭拿掉了...

剛剛改回用 beta channel 的 Google Chrome (78 版),結果發現網址列裡的 www 被拿掉,而且本來可以關掉的方式 (omnibox-ui 系列的設定) 從 chrome://flags 裡面也拔掉了,代表你現在關不掉了...

搜了一下資料,發現在 Reddit 上有人討論過 78 版的這個問題 (當時還在 dev channel):「Chrome 78 dev hide 'www' again」。

裡面有人提到可以安裝 Suspicious Site Reporterwww 重現,當初看到還半信半疑,結果裝了發現真的會動,WTF...

看了一下 extension 的 source code 發現好大一包,以後應該會有人生一個小的 extension 出來專門做這件事情?