fPrivacy:在 Google Chrome 下調整 Facebook 應用程式可用權限

fPrivacy 的說明「Makes Facebook permissions optional.」把功能說明的很清楚,就是在授權 Facebook 權限的時候,把應用程式可用權限調低。

Plurk 為例,當 Plurk 需要 Facebook 權限時,提出需要這些權限:

你可以發現上方多了一條東西。這時候你可以把 publish_actions 勾勾拿掉 (看這個意思應該是「以我的名義貼文」的權限),按下 Update 按鈕後:

按下 Update 按鈕後,就把需求變少了。甚至你可以再拔掉 email 這組,再按 Update 按鈕:

就什麼權限都不給他了,這拿來對付過度要求權限的應用程式還蠻好用的...

在 Ubuntu 的 Chrome (Chromium) 看 PDF 的方式

由於 PDF Viewer 不是 free software (參考「Why doesn't Chromium have "Chrome PDF Viewer" plugin?」),所以 Ubuntu 下的 Chromium 並沒有包進去,需要自己手動安裝。

方法可以參考「Chrome PDF Plugin in Ubuntu – How To Enable」這篇:

Mozilla Firefox 與 Google Chrome...

我家裡與公司的 Mozilla FirefoxGoogle Chrome 都是在 Ubuntu 上面跑,至於家裡的 Mac Mini 就沒換了,還是跑 Chrome。來講一下我對這兩個瀏覽器的的感覺。

從安裝開始,在 Ubuntu 下面我是透過 ppa 裝 release 前一個 channel (兩個都叫做 beta)。安裝的方式很簡單,設好 ppa 後 apt-get update; apt-get dist-upgrade 就會把系統的 Firefox 與 Chrome 升級到新版。

對於套件的相容性,Firefox 有很明顯的改善,現在從 Release 升級到 Beta 的時候不會直接把所有的套件標成不相容,會有一些機制處理,這方面算是跟 Chrome 有得玩。

另外一方面 Chrome 也支援更多 API 讓套件使用,現在套件可以做很多網路層的操作,接下只要 Chrome 把 UI API 設計完整一點就可以了... (Chrome 上面套件的設定畫面相較於 Firefox 是有需要再改善的,瀏覽器對 UI API 支援太陽春算是原因之一...)

同步的問題因為 Chrome 可以綁定 Google 帳號,就算是 Two-Factor 時也可以用 application password,而 Firefox 的同步功能我試了三次都沒成功過...

效能方面,可以發現兩個瀏覽器的效能都很好了,Twitter 算是 script 很多,可以感覺到比較頓的網站 (參考「bandwidth」這篇),兩個瀏覽器用起來都不會有明顯的不順暢。

操作方面是還是可以感覺到 Firefox 在某些地方卡住:

  • focus 在 Flash 時,Ctrl-W 無法關閉視窗 (因為 Ctrl-W 被 Flash 抓走了)。
  • Firefox 的 Firebug (yeah,跟 Firefox team 無關,但這剛好對應於 Chrome 內建功能) 沒辦法用 Ctrl-W 關閉。
  • 在 address bar 輸入 url 有時會被 suggestion 卡到 lag,這之前有提過了,在 bugzilla 上也有 ticket 在追這個問題...

最後要談的是穩定性,兩者的穩定性都已經可以接受,只是很明顯 Firefox 遇到複雜的 script 還是不太穩,無論是 Facebook 還是 Twitter,偶而會出問題,這時候把 browser 關掉再開就好了...

Firefox 大概還會再用一陣子吧... 算是測試不同的 browser。

Chrome 的 webRequest...

在變成標準前又改了一次...

Google Chrome 17 後,「Web Requests」從 Experimental API 變成正式的 API,有不少地方在這次轉成正式 API 後需要修改:

  • 本來 chrome.experimental.webRequest 都改成 chrome.webRequest
  • 需要加上 webRequest permission,如果有 blocking 行為則要再加上 webRequestBlocking permission。
  • API 呼叫的參數可能會不一樣,參考官方的文件的說明比較清楚。我遇到的是使用 onBeforeRequest.addListener 時需要多加上 urls 參數。
  • 不再需要 expiermental permission,不過沒拿掉不影響運作。

Chrome Web Store 上面已經可以看到一些跟控制 Referrer 有關的延伸套件了...

Google Chrome Extension 內攔截所有的 url request...

之前寫了一個處理 Referer header 的 extension,使用 chrome.experimental.webRequest.onBeforeSendHeaders.addListener 攔截所有的 url 然後處理 Referer header。

之前只需要在 manifest.json 裡面加上 experimental 就可以使用,但是前陣子發現失效。剛剛在「onBeforeSendHeaders listeners aren't triggering」這個 issue 裡面找到解法:現在需要多加上 <all_urls> 這組權限。

關掉 Mac OS X 上的平滑捲動...

起因是想要關掉 Google ChromeMac OS X 上的平滑捲動,找了半天都沒看到,後來被人提醒,Mac 系統有選項提供平滑捲動,Google Chrome 有平滑捲動可能是由作業系統提供,而非 Google Chrome 自己實作:

關掉後問題就解決了...

Mac 下 Google Chrome 的 textarea 預設字型...

要編輯維基百科的時候發現字寬好像不太熟悉,多看了幾個站台,發現 Google Chrome 在 Mac 下面對 textarea 預設的字型不是等寬字... 而且預設的套件沒辦法修改 :o

知道問題後,就是要找解法了... 目前的解法是裝 Stylish,對所有站台的 textarea 加上 font-family: monospace;,這樣就可以避免當網站沒有對 textarea 指定 font-family 時看起來很突兀...

Google Chrome 的 user script 與 Greasemonkey 的不同...

實在是睡不著,來整理一些資料...

不知道「User Scripts - The Chromium Projects」這份是否 outdated 了,但至少發現在 Google Chrome 裡面推薦用 @match 設定 url,不過原先的 @include 還是可以用:

Support for Greasemonkey-style @include patterns is also implemented for compatibility, but @match is preferred.

在 Greasemonkey 的「Metadata Block - GreaseSpot」說明中則是用 @include 設定,直到 0.9.8 (2011/08/01 release) 以及之後的版本才同時支援 @include@match

之後改寫 script 的時候再更新好了...