Skip to main content

3 posts tagged with "devtools"

View All Tags

· 11 min read

2017/9/22 我和 Ricky Chien 在台灣第一次舉辦的Mozilla Developer Conference中，一起為大家介紹 Firefox 開發者工具，也就是 Devtools 的近期進展和新功能7。

Devtools 架構的大幅改進，是過去一年中所有 Devtools 貢獻者共同努力的成果。在這講題中，我們可以看到 Devtools 如何持續改進，並提供各種新的工具，讓開發網頁的過程變得更有效率。

透過在 Firefox 57 新版的統一選單介面上開啟 Web Developer Tool，我們可以開啟 Devtools 的各種工具分頁分頁 (Panel)。

Devtools 簡單來說，就是各式各樣網頁開發者工具的集合。這些工具以一個個分頁（Panel）的形式組織在開發者工具區域中，我們稱這個區域為Toolbox，也就是工具箱。

Devtools 的過去

Devtools 的前身叫做 Firebug1。在 2006 年時，Firefox 的創始者之一 Joe Hewitt 寫出了 Firebug 這個 Firefox 的網頁開發工具 addon2。 使用者可以利用它除錯、編輯、刪改任何網站的 CSS、HTML、DOM 與 JavaScript。也可以透過 addon 再次擴展它的功能。現在各家瀏覽器的網頁開發者工具都參考了 Firebug 功能。

過去的 Web 相關技術遠遠沒有今天成熟，Mozilla 發明了一些特有的技術 (XUL, XBL) 來製作瀏覽器的介面與呼叫特殊的 API (Addon API) 來和作業系統互動。因為原有的 addon 架構無法支援 FIrefox 新的多執行緒 (multiple process) 架構，因此 2016 年 Firebug 開發團隊決定將 Firebug 直接整合進 Devtools 中3，原有的 Firebug 開發團隊也大多加入了 Firefox Devtools 團隊繼續貢獻，也因此我和 Ricky 有了和原 Firebug 維護者 Honza 直接共事的機會，在過去半年中我們合作開發 Network Monitor，透過 Daily Meeting 同步進度，也在合作的過程中得到許多難得的經驗。

Devtools 的現在

Devtools 繼承 Firebug 的開發目標，也就是協助網頁開發者更有效率的製作網站。同時作為網頁開發者工具，我們希望開發者工具工具本身，也能用和網頁開發者使用的排版與框架來撰寫。

於是在 Mozilla Web Summit，大家可以看到我們的成果。我們已經在使用 HTML 和 Web Standard API 來製作 Devtools 開發者工具！

使用 HTML 與 Web Standard API 只是第一步。我們進一步評估，選用了 React 和 Redux 作為前端 UI 介面與狀態管理框架。經過 react 改寫後，我們有了可在不同工具間中重用的元件庫。透過 redux，每個工具也都有了清晰的 App 狀態管理機制。

我們將許多 Devtools 核心的專案放到 Github 上以方便開發者，並且將可以重用的元件，放到 Devtools-Core 專案中，將可以獨立運作的Debugger.html，Perf.html專案也放到 Github 上，讓參與專案變得更容易。

如果想開發自己所需的的開發者工具。現在也可以使用 Web Extension API 來製作新的開發者工具面板。面板中也可以重用Devtools-Core專案提供的 React 介面元件，更快地打造自己的開發者工具。

使用者介面的改進

Firefox 57 上的 Devtools 分頁變得更美觀了。當然這些都已包成 React component，喜歡還可以拿去用。

對於新配色的選擇，我們的 UX 團隊有做過可用性 (Assessibility) 測試5。即使是辨色有障礙的人，也可以容易地分辨不同色塊的差異。

Inspector 工具的改進

Inspector 工具是最常被使用的開發者工具。透過 Inspector，可以查看或修改 HTML。選到任一個 Element 時，可以查看並修改這個 Element 目前所有套用的 Style。

透過重構 Inspector，我們把原本使用的 XUL 與 addon SDK 替換為 HTML 和 web API。並使用 React + Redux 來組織程式的內部架構。

在整理所有 devtools 新增功能的時候，我最先注意到的就是 "Find Useless Rules" 這個超實用的功能。

過去在 Inspector 裡只會在不合法的樣式旁顯示警告標誌，現在我們也會在「合法，但無用」的樣式旁也顯示警告標誌。 比如在 grid 或 flex layout 中使用 float 屬性的話沒有作用，Inspector 就會在 float 屬性旁顯示警告標誌。

此外，Inspector 的 Box Model 會列出所有影響的這個元件位置，大小，或形狀的屬性。透過新的 box model 介面，可以更容易地查看並調整上下左右 position 參數，快速地將版面調整到理想狀態。

Firefox Devtools 也是最先支援 Grid Layout 4的開發者工具。我們可以看到，在 Rules side panel 中的任何修改，都會直接反映到頁面上。

在 Layout Side panel 上會列出了頁面上所有的 Grid Layout。右側則可以選擇要顯示輔助線號碼，區塊名稱，或是要不要延長 Grid 格線以便排版。

不僅如此，在畫面上也可以見到，開發者也可以在 Layout Side panel 中快速的查看對應的網格。我們可以透過這些選項更好地查看頁面上的 Grid Layout。

Ｗeb Console

Web Console 應該是 Javascript 開發者最常用的網頁工具吧。除了查看頁面上的 Javascript 錯誤，印 log 外，Web Console 可以即時執行 javascript，或是存取頁面上的 Ｇlobal Object。

去年 Web Console 也經過改寫。使用 React + Redux 來組織程式的內部架構。

我們在 console 中可以即時執行 javascript 並取得執行結果。不管是哪種類型的變數，無論是 boolean, array, object 都會用 Object logs 來顯示。

在 rewrite web console 的過程中，我們也將 Object logs 包裝起來變成一個可以重用的 React Component。

這個元件被大量地運用在 Debugger, Network 等其他 panel 上。

如果你想要開發自己的開發者工具或剛好需要類似的元件，reps 可以在 github 上找到。或是透過npm install devtools-reps命令來安裝到你的專案中。

https://github.com/devtools-html/devtools-core/tree/master/packages/devtools-reps#readme

Web console 近期也透過 tree 和 reps 元件，支援了 console group 功能 https://developer.mozilla.org/en-US/docs/Web/API/Console/group

現在透過 web console 實驗 XMLHTTPRequest 或 fetch 時，也可以透過 HTTP inspector 來即時查看 http request 的內容。整套 HTTP inspector 元件是來自 Network Monitor，只經過一點點修改就能完整套用。因此在 web console 中可以直接看到與在 network panel 中一樣的資訊，非常方便。

Perf.html 網頁效能監測工具

最後我想介紹的是 Perf.html 這套工具。

要提升網頁的效能是相當考驗技術的。 透過 profiling，也就是量測的結果，我們可以更直觀地找出網頁效能的瓶頸並做出針對性地改善。perf.html 就是這樣的量測工具。

去年 perf.html 也經過改寫。使用 React + Redux 來組織程式的內部架構。有自己的網頁，可以脫離 devtools 獨立運作。程式碼 host 在 github 上。

perf.html 使用前需先到網站上安裝 addon，在要量測前後按下 start/stop，就可以得到量測的 profile。

perf.html 最棒的點是，量測好的 profile 可以透過 addon 直接上傳到網站上，我們是在一般網站的介面上查看量測的結果。可以直接分享這個網址，或是標註出關注的時間區間後分享。和其他人一起 trace 效能瓶頸。

經過 photon 更新後，perf.html 介面風格將變得更加簡潔，配色變得更大膽，用起來更舒服。

以上是我分享的部分。若您對 Devtools 感興趣，可以到firefox-dev.tools網站查看所有與 Firefox Devtools 相關的資訊。

參考資料

· 5 min read

Update: Full instructions are avaiable on Netmonitor Readme to run the Network Monitor in the browser tab.

Firefox Devtools is in progress of modernizing its infrastructure to use the same toolset that modern web developers are familiar with. When talking about modern web developers toolset, I mean React, Redux, Immutablejs, and npm modules.😎

What Firefox Devtools team did last year

Firefox Devtools was no different from Firefox itself. The Devtools panels are written in XUL, an HTML-like syntax language, and use several Firefox internal API called XPCOM or Chrome privileged API(Nothing related to Chrome Browser) to make the browser works.👽

In last year(2016), Firefox Devtools team's main goal is to convert the code base from XUL to pure HTML. The second goal is convert each tool with React/Redux structure for maintenance. Debugger, Inspector, Web Console are the first batch in the conversion progress. Debugger.html is the very first attempt from Firefox Devtools team to embrace the modern web developers' toolset. Now new Debugger and Web Console are available in Firefox Nightly🍸

Debugger.html, Perf.html(Performance) has their standalone repository hosted on Github. A developer could use git clone to get the repository, and then do yarn install, yarn start(similar to npm command) to debug the debugger.html/perf.html with any browser's devtools!🚅

graph LR clone[git clone] --> install[yarn install] install --> start[yarn start]

What Run on the Browser tab means?

Run on the Browser tab is a term versus Run inside of the developer panel. Traditionally Devtools are running inside of the browser's developer panel. But some of new Firefox Devtools support run as normal web pages. Those pages can be opened in a browser tab by any modern browser such as Chrome, Safari, or Edge. The benefit is we can improve Firefox Devtools with any Browser's Devtools, its an unfair advantage.🚀

graph LR Firefox -- debugging --> netmonitor(Netmonitor.html) netmonitor -- mozilla-rdp --> Firefox Chrome -- debugging --> netmonitor Edge -- debugging --> netmonitor Safari -- debugging --> netmonitor

We are going to make more Devtools easy to debug and can be used for cross-browser debugging.

Current Status

To replacing the jet engine while still flying is a challenging engineering work. To make it happen, we take several engineering experiments around Devtools.

Here are the projects in progress and where they are hosted from:

graph LR debugger(Debugger.html) --> Nightly perf(Perf.html) --> Nightly webconsole(WebConsole.html) --> Nightly standalone[Github] --> debugger standalone --> perf refactor[mozilla-central] --> webconsole inspector(Inspector.html) --> Release netmonitor(Netmonitor.html) --> Release refactor --> inspector refactor --> netmonitor

What we have done in Netmonitor.html

Ricky Chien and I joined the effort of convert Object Inspector from XUL to HTML. Object Inspector is a more complicated tool to convert, so Object Inspector is still half React and without Redux in the playground.

When the Object Inspector is fully converted to HTML, we shift our focus on convert the next important Devtool: Netmonitor. With Honza, Janda, Steve Chung, and other contributors' help, at the end of Feb we have reached our first phase tangible goal: Converted the whole Netmonitor panel from XUL to HTML, with React, Redux, and Immutablejs. Now we have confidence that the code base is easy to read and contribute.🤗

Imgur Picture: How current Netmonitor looks like

What we plan to do next

We just finished the Netmonitor workweek (Fred, Honza, Ricky) in Taiwan, plenty of discussions have occurred, and we have good progress for what should be going on for the Netmonitor.

Here they are:

  • We’ve triaged all new Netmonitor bugs and identify good-first-bugs
  • We have Prove-Of-Concept branches to prove we can run netmonitor on the browser tab
  • We decide to keep using mozilla-central(The gecko) repo. Beside the current workflow, a developer would able to run yarn start command to debugging Netmonitor on the browser tab with any browser's devtool.
  • We stop Netmonitor.html phase I work immediately (convert XUL to HTML, MVP 100% completed)
  • We'll start Netmonitor.html phase II (To run Netmonitor on a browser tab so that we can debug Netmonitor with any browser's devtool)
    • All phase II bugs are filed in the Meta-bug

What could expect in the future

Currently, Debugger.html have supported both Firefox and Chrome remote debugging protocols, so Debugger.html could be used to debug Firefox, Chrome, or even Node.js!😮

graph LR Firefox -- debugging --> netmonitor(Netmonitor.html) netmonitor -- mozilla-rdp --> Firefox Chrome -- debugging --> netmonitor netmonitor -- chrome-rdp --> Chrome netmonitor -- chrome-rdp --> Node[Node.js] Safari -- debugging --> netmonitor Edge -- debugging --> netmonitor

Since Debugger.html's pure web stack nature, you can imagine one day the debugger.html can be embedded into some editors(Atom, Visual Studio Code) as plugins, or even in other browsers!😇

graph LR debugger(Debugger.html) --> Firefox debugger --> browsertab[Browser Tab] debugger --> Editor debugger --> other[Other Browser]

Run with different remote debugging protocols is the next step once we make Netmonitor.html run on the browser tab.

· 3 min read

Not like previous article about general workflow on Mozilla Gecko project, This article is like a cookbook that I encountered during debugging Firefox devtools (mostly around inspector and network monitor).

Remote debugging

According to MDN, first of all you need to go through Developer > Toggle Tools > Toolbox Options > Advance settings to check 2 options:

  • Enable browser chrome and add-on debugging toolboxes
  • Enable remote debugging

Then use Shift+Option+Command+i on Mac or Ctrl+Shift+i on linux to open the remote debugger.

Disable autohide in popup

Once I'm developing toolbar web extensions or any popup windows, I feel very appreciate this feature.

https://developer.mozilla.org/zh-TW/Add-ons/WebExtensions/Debugging#Disable_autohide

Boost build time via set mozconfig artifact

Add these settings in mozconfig file

# Enable debug version of the pre-build binary artifact
export MOZ_DEBUG="1"

# Automatically download and use compiled C++ components:
ac_add_options --enable-artifact-builds

# Write build artifacts to:
mk_add_options MOZ_OBJDIR=./objdir-frontend-debug-artifact

If you just develop frontend UI(JS, CSS, XUL, HTML), the artifact build prebuild the C++ and the static part of the code so you can download and link it automatically during mach build, it saves you tremendous build time and helps you move quicker.

You can use the command

./mach build faster

to further boost the build time.

Enable React and other JS debugging message

Add these settings in mozconfig file

ac_add_options --enable-debug-js-modules

It will turn on React and other JS debugging message. Note that will influence performance while running.

Open devtools and chrome debugger with website

You may not know its possible to open a website with opened devtool with the command:

./mach run --devtools --jsdebugger www.yahoo.com.tw

Test on Try server

Mozilla Try Server let you run tests on all supported platforms. You can pick which test set and which platform to run by providing command arguments. Here's what I used for test devtools related bugs on Windows, Mac, and Linux.

try: -b do -p linux64,macosx64,win64 -u mochitest-dt,mochitest-e10s-devtools-chrome -t none --artifact

Add --artifact argument will both save total running time and computing resources.

Tracing Code

Via global search in editor

Many modern editor ex sublime, visual studio code provide great support of global search. Ctrl + Shift + f is your good friend.

Via DXR or searchfox

DXR and searchfox is a code search and navigation tool for large projects like Mozilla-center. It supports full-text and regex searches as well as structural queries.

http://dxr.mozilla.org/

ES6 nits

Do not use forEach with yield

forEach is a good way to loop array, but is not compatible with the generator(because the need of implement iterator interface), so if you use yield inside of forEach loop, it will not behave as you expect. The better choice is use for..of loop or map instead.

Try to be functional

The powerful => arrow syntax sugar is not just for replacing bind(this), it gives the developer a clear way to write more compact code.

For example 

promise.then(function(a , b) {
  return a + b;
});

can be written as 

promise.then((a, b) => a + b);

Misc