Mozilla Flux

Mozilla関係の情報に特化したブログです。

Windows版Firefox Quantumではてなブックマーク拡張の日本語入力がおかしくなる問題の一時的な回避策

2017年10月18日にはてなブックマークFirefox拡張がバージョン3.0.0へとアップデートされ(最新バージョンは3.0.2)、Firefox Quantum以降に対応するようになった。ところが、Windows版Firefox Quantumで日本語入力がおかしくなる問題が発生している。

具体的には、ツールバー上のアイコンをクリックすると表示される、コメントの入力領域にIMEで入力する際、候補ウィンドウが常に画面の左上隅に出現する(Bug 1419285)。IMEの種類には関係がなく、Microsoft IMEはもちろん、ATOKやGoogle日本語入力でも現象は共通だ。候補を確定してしまえば文字列が入力領域に現れるとはいえ、拡張機能の使い勝手が損なわれることおびただしい。

実は、この問題はWebExtensionsベースの拡張機能が表示するパネルであれば、どこでも起きうるもの。はてなブックマーク拡張側の不具合ではない。Windows版Firefox 56においてWebExtensionsベースの拡張機能にはまとめて1つのプロセスを割り当てたのだが、この状態だとIME入力時にパネルにうまくフォーカスが当たらず、上記の現象が発生してしまうようなのだ。拡張機能の別プロセス化はマルチプロセス機能(e10s)の有効化が前提であり、e10sが全面有効化されてかつ拡張機能がWebExtensionsに限定されたFirefox Quantumで、問題が一挙に顕在化したというわけ。

現在Mozillaの開発者が対処にあたっており、Firefox 58では修正される見通しである。それまでは、拡張機能の別プロセス化を解除することで問題を一時的に回避できる。about:configの画面からextensions.webextensions.remoteの設定をfalseに変更すればOK。ただ、拡張機能の別プロセス化は、拡張機能がFirefox本体を巻き込んでクラッシュしたり、本体の応答性を低下させたりするリスクを減らすために導入されたものなので、上記の設定変更によってそうしたリスクが高まることに注意してほしい。

Firefox Quantumでトラッキング防止機能の全面有効化が可能に

トラッキング防止の新設定

Firefox 42以降、プライベートブラウジングモードではトラッキング防止機能有効化されるようになっているが、Firefox Quantumでは通常モードでもこの機能を有効化する設定が追加された(Bug 1393627)。トラッキング防止機能を有効化した場合、たとえばGoogleアナリティクスなどもブロックされるが、目に見える効果として大きいのは、一部の広告が出なくなる点だろう。

設定を開くには、まずFirefoxのウィンドウの上部右隅からメニューパネルを開き、歯車のアイコンがついた「オプション」をクリックする。次いで南京錠のアイコンがついた〔プライバシーとセキュリティ〕をクリック。画面を下にスクロールさせていくと、トラッキング保護*1の欄が出てくる。初期設定は「プライベートウィンドウのみ」になっているが、これを「常に」に変更するとトラッキング防止機能が有効化される。

f:id:Rockridge:20171119210643p:plain
Firefox Quantumの新しいトラッキング防止設定画面

ちなみに、『ブロックリストを変更』というボタンを押すと、リストの選択画面に移る。初期設定は簡易ブロックだが、より強力な広範ブロックを選ぶことも可能だ。*2

f:id:Rockridge:20171119211140p:plain
ブロックリストの選択画面

トラッキング防止機能の効果を確かめるため、同一のWebページで有効・無効を切り替えてみよう。本機能が無効(初期設定)の場合、記事の上側や右側に広告が表示されるのは、よくあることだ。本機能を有効化するとそうした広告が除去され、これに伴ってページの読み込みも高速化される。

f:id:Rockridge:20171119211853p:plainf:id:Rockridge:20171119211922p:plain
左:初期設定 右:トラッキング防止機能有効

トラッキング防止機能が働いているときは、アドレスバーに盾のアイコンが表示される。サイト単位で有効・無効の切り替えを行うこともできるので、ふだんは有効化しておき、表示が崩れる場合だけ機能を無効化するといった使い方も可能だ。機能を有効化した直後にチュートリアルが出るようになっているので、内容を覚えておこう。

f:id:Rockridge:20171119212712p:plainf:id:Rockridge:20171119212728p:plainf:id:Rockridge:20171119212740p:plain
トラッキング防止機能のチュートリアル

Polarisイニシアティブの到達点

Firefoxのトラッキング防止機能は、提携先であるDisconnectトラッキング防止リストを使用している。追跡者のリストはオープンにされており、見直されることもある。また、すべての追跡者がシャットアウトされるわけではなく、Do Not Track(DNT)の設定を尊重するWebサイトが除外されるほか、ユーザーの利便性も考慮されているようだ。

Mozillaは、ユーザーのオンラインプライバシーの保護向上を目的とするPolarisイニシアティブの一環として、2014年11月にこの機能の開発をアナウンスし、前述のとおりFirefox 42で製品版に取り込んだ後も、全面有効化に向けた研究・開発を続けてきた。Firefox Quantumに導入された設定画面も、2016年1月にFirefox Nightly 46(開発版)で実装されていたものだ。

2016年9月下旬にはTracking ProtectionがFirefox Test Pilotの実験に追加され、2017年2月中旬まで実験が続けられた。そこで得られた知見は、"Test Pilot Tracking Protection Graduation Report"という記事にまとめられている。実験の際、ユーザーがトラッキング防止機能を無効化したWebサイトは少なかったようだが、ユーザーからのフィードバックを受けたMozillaがDisconnectと協議し、たとえばTwitterに投稿された画像がブロックされないように調整したそうだ。

その後も1万9000人以上を対象にした詳細な実地試験を経て、2017年8月にはトラッキング防止機能を有効化しても、恐れていたほどWebサイトの表示は崩れないとの結論が得られた。この結論がFirefox Quantumにおける設定追加の前提となっているとみられる。

Firefox Quantumでトラッキング防止機能の全面有効化が可能となった背景には、こうした過去の研究・開発の積み重ねがある。Polarisイニシアティブの1つの到達点と言えるだろう。拡張機能を入れなくても、設定を変更するだけで実効性のあるプライバシー保護の措置を講じられるというのは、素晴らしいことではないだろうか。

(17/11/23追記)
本記事掲載後、Firefox Private Browsing vs. Chrome Incognito: Which is Faster? - The Mozilla Blogが速度向上に焦点を当ててトラッキング防止機能を紹介している。速くなったと評判の「Firefox Quantum」をもっと速く使う方法が明らかにされる - やじうまの杜 - 窓の杜がこれを比較的詳しく取り上げているが、要するにMozillaに調査によれば、ページの読み込みに要する時間が半分以下になったという。

また、Tracking Protectionの公式な訳語が、「トラッキング保護」から「トラッキング防止」に変更されることになった。関係者の迅速な対応に感謝したい。

*1:本記事ではあえて公式とは違うトラッキング「防止」の呼称を用いている。通常、プライバシー保護といえばプライバシー「を」保護することを指すが、ここでいうトラッキング保護機能は、トラッキング「から」ユーザーを保護するものだ。プライバシー保護のためのトラッキング保護機能という呼び方は、どうも据わりが悪い。

*2:リストの切り替えには本体の再起動を要するが、Firefox 58では不要になる(Bug 1363969)。

旧式拡張機能からの移行例

新形式の長所と短所

Firefox Quantumでは旧式の拡張機能が一切使えないようになっており、サポートされるのはChromeの拡張機能と共通する部分の多い新形式(WebExtensions)のものだけだ。Firefox 56以前で使用していた拡張機能が既にこの新形式に移行している場合はいいが、そうでなければ同じような機能を提供する別の拡張機能を探す必要がある。

もっとも、新形式の拡張機能は従来よりも制約が大きい。旧式拡張機能の時代に、Firefox本体を大幅に書き換えることさえ許容していた結果、さまざまなバグの温床となったうえ、拡張機能の互換性を維持することが重荷にもなっていたことに対する反省を踏まえ、新形式では拡張機能ができることを絞ったのだ。特に、Firefox本体のユーザーインターフェイス(UI)にはごく限定された範囲でしか介入できないようになっている。そのため、従来のようなオールインワン型の拡張機能(Tab Mix Plusなど)は作成が極めて難しくなっている。

新旧の差は相当なもので、旧式拡張機能の新形式への移行は同じコンセプトの拡張機能を作り直すのに等しいという意見が出るほどだ。しかも、Firefox 56までの間に新旧のハイブリッド形式に移行しておかないと、設定の受渡しもできない。

その代わり、拡張機能のインストール・アンインストールや有効・無効の切り替えの場面で、Firefox本体の再起動が例外なく不要となった。これによって、新しい拡張機能を気軽に試すことができるし、一部の拡張機能をふだんは無効にしておいて、必要になったら有効化するといった使い方でも支障がなくなる。それに、拡張機能がFirefox本体の速度や応答性を低下させる度合いは、かつてと比べ大きく軽減されている。

新形式の長所はそれだけにとどまらない。拡張機能の互換性が重視されているので、たとえば今インストールした拡張機能が2年後にも正常に動作している可能性は高いだろう。安定性の面では、今のところWindows版のみだが、拡張機能全体に1つの独立したプロセスを割り当てているため、Firefox本体を巻き込んで落ちるケースも少なくなるはずだ。加えて、Firefox Syncを利用して拡張機能が設定を同期させることも容易になった。

筆者のケース

今まで使っていた拡張機能がバージョンアップしないとか、バージョンアップしても機能が限定されてしまったという場合、前述のとおり新形式の拡張機能には仕様上の限界があるので、好みの環境を作り上げていくには、単機能の拡張機能を新たに見つけ出して、うまく組み合わせる必要がある。

Firefox Quantum以降、本体のアドオンマネージャーには〔旧式の拡張機能〕欄に「代わりのアドオンを探す」というボタンが付いており、新しい拡張機能を見つける際の助けになってくれる。また、英語が前提ではあるがExtension Finderというツールもある。

筆者の場合、Firefoxの開発版を常用しているので、早い段階から旧式拡張機能の廃止という問題に取り組まねばならなかった。現在も試行錯誤の途中ではあるが、インストールしている拡張機能は、ひとまず次のようなリストに落ち着いている。

Adblock Plusは言わずと知れた広告ブロッカーだ。uBlock Originも新形式に対応しているので、どちらを取るか迷うところではある。新規にインストールするのであれば、ABP Japanese filtersの設定が簡単なuBlock Originのほうがよいかもしれない。

Chrome Store Foxifiedは当ブログで過去に紹介したことがある。Chromeウェブストアに登録されている拡張機能を、いわば強引にFirefoxで動かすためのツールだ。"Feedly はてブ"はこのツールを用いてFirefox版に変換したものを使っているが、ブックマーク数は問題なく表示されている。

Close Tabs to the Leftは左側のタブをすべて閉じる機能を追加するもの。個人的にはそこそこ使うので、オプションとしてFirefox本体に取り込んでほしい。

Font Finder (revived)はWebページ内で用いられているフォントを調べる際に使う。できればChrome向け拡張機能であるWhatFontのようなものが欲しいところ。あるいは、ウェブ開発ツールのインスペクターにこの機能が入っているべきなのかも。

Gesturefyはジェスチャー機能を追加してくれる。作り込まれた設定画面を備えており、マウスジェスチャーやホイールジェスチャーのカスタマイズも可能だ。筆者はホイールジェスチャーにタブの切り替えを当てていて、コンテンツ内でマウスの右ボタンを押したままホイールを回すことによって、タブの切り替えが行われるようにしている。

HoldTabは現在のタブ以外のタブについて、読み込みを保留しておけるので、たくさんのブックマークを一気に開く場合に重宝する。ただ、リンクを新しいタブで開くだけでも保留になってしまうため、ふだんは無効にしている。

In My Pocketは、かつて存在していた公式拡張機能のように、Pocketに保存した記事をリスト表示し、保存済み記事のURLを開いたときはアイコンの色が変わって知らせてくれる。これらの機能もFirefox本体に備わっているべきだと思う。

Neat URLはWebページのURLにくっついているパラメータを自動的に除去する。設定画面で対象パラメータを指定できる点もポイントが高い。余計なものを取り払うことで、そのページがはてなブックマークに登録済みかどうかの判別もしやすくなる。

Open in Google Chrome BrowserとOpen in MS Edge™ Browserは、文字通り現在開いているURLを他のブラウザで開き直すものだが、利用の前にNode.js製のネイティブクライアントをインストールしておかないといけない。各OS用のものが用意されていて、Windows版だとバッチファイルがあるので、インストール・アンインストールは難しくない。が、外部のアプリケーションと連携する際にこうした手間がかかるのは、新形式の拡張機能のデメリットだ。

Selection Context Searchは選択した文字列を既定以外の検索エンジンで検索可能にする。ユーザー側で検索用のURLを指定せねばならず、コンテクストメニューに表示される項目を調整する手間もかなりかかるため、不満もあるのだが、既定のGoogle以外に「英辞郎」と「Wikipedia」と「Bugzilla@Mozilla」を検索に含めたいというマニアックな要求を満たす方法としては、今のところこれしかない。

Tab Saverは特定のウィンドウにおけるタブ列のURLを一括して保存するツールだ。タブ列には年月日と日時(分単位)によって構成された表題が自動的に付加される。OneTabをシンプルにした感じで、Webページのタイトルやセッション情報も保存されないし、1分あたり1つしかタブ列を保存できない欠点もあるものの、操作の手軽さが気に入っている。

Tampermonkeyはユーザースクリプトの管理と実行を担う。Greasemonkeyが新形式に移行する際にスクリプトの互換性を犠牲にしてしまったので、乗り換えた。といっても、組み込んでいるスクリプトはDirect GoogleTwitter原寸びゅーくらいだが。

Translate Nowは指定した翻訳エンジンによって翻訳されたWebページを別タブで開く。ドイツ語で書かれたsoeren-hentzschel.atの記事をGoogle翻訳で英語に変換して読むのに使っているが、本当はChromeのように自動翻訳機能をFirefox本体に実装してほしい。

uAutoPagerizeは次のページを自動的に読み込んで、現在のページに継ぎ足してくれる。設定画面で実行しないページを指定することも可能だ。旧式拡張機能の時代には同種のものがいくつかあったと記憶しているが、新形式に対応したものは今のところこれだけではないか。

"URL をクリップボードにコピー"は、主にドキュメント自体のURLをHTML形式でクリップボードにコピーしたいときに使う。テキストをあらかじめ選択しておくと、リンクの内容に反映される点もよい。

"ZoomImage - 画像拡大"はページ内画像の拡大だけでなく縮小・回転もこなす。画像を浮かせる機能もある。ただ、筆者の環境ではGesturefyのホイールジェスチャーとキー設定が衝突してしまう。

"テキストリンク (Text Link)"は、リンクになっていないURLをダブルクリックすることで、そのURLが新しいタブに読み込まれるというもの。信頼と実績のPiroブランドである。

"はてなブックマーク"は、はてなブックマークの公式拡張機能であり、Chrome版を移植したため従来のものとは使い勝手が大幅に変わっている。タブを切り替えるとブックマークコメントの入力ウィンドウが閉じてしまう仕様だけは何とかならないものか。

お役御免となった拡張機能

前記の新環境となった結果、FireGesturesはGesturefyに、GreasemonkeyはTampermonkeyに、image-resizerは"ZoomImage - 画像拡大"に、Load Tabs Progressively FixedはHoldTabに、Make Linkは"URL をクリップボードにコピー"に、Open WithはOpen in Google Chrome BrowserとOpen in MS Edge™ Browserに、それぞれ置き換えられた。

また、長らく使用してきたSave Sessionについては、「以前のセッションを復元」の項目がFirefox Quantum以降メニューパネルの最上位の階層に配置されるようになったこともあり、Tab Saverに道を譲ってもらうことにした。

他方で、移行ができなかった拡張機能もある。Clear Fields(フィールドの消去)、Configuration Mania(本体設定のチューニング)、FEBE(拡張機能のバックアップ)、IME自動無効(アドレスバーのフォーカス時にIMEを無効化)、Menu Wizard(コンテキストメニュー等の項目の並べ替えや隠蔽)は、Firefox本体のUIや設定をいじらせないというMozillaの方針により、機能的に実現不可能となった。新形式への移行はもちろん、代替拡張機能も存在しない。

マルチプルタブハンドラ (Multiple Tab Handler)についても、ツリー型タブ (Tree Style Tab)との連携にフォーカスされて使い勝手が変わってしまったので、移行を見送った。Firefox Quantumだとタブの複製機能は本体に実装されているし、左側のタブをすべて閉じる機能はClose Tabs to the Leftで間に合っている。将来的にタブの複数選択機能もFirefoxの標準機能に加わる見込みなので、しばらくの辛抱だ。

Firefox Quantum高速化の一翼を担うQuantum CSS

デスクトップ版Firefox Quantumでは、Quantum CSS(別名Stylo)と呼ばれる新しいCSSエンジンが初期設定で有効化されている(Bug 1330412)。CSSエンジンはレンダリングエンジンの構成要素の1つで、CSSパーサーとスタイルシステムから成り、HTMLパーサーが生成したDOMツリー(DOMノードが樹状に連なったもの)に対し、CSSを解釈してスタイルを計算した結果を当てはめていく。

Quantum CSSは約8.5万行のRust言語のコードで構成される。Geckoの旧CSSエンジンは約16万行のC++言語のコードで構成されていたから、半分程度のコンパクトさだ。それでいて、Quantum CSSは旧CSSエンジンが設計の古さゆえに抱えてた様々な不具合を解消している。もっとも、実装には苦労もあったようだ。font-sizeプロパティ1つとっても、いろんな単位をサポートしなければならないうえ、たとえば"medium"が何を指すかはフォントの系統ごとに変わってくるし、ルビやMathMLでの調整も必要になる。2015年の終わりころに開発が開始され、2年近い歳月を経てようやくFirefoxリリース版への搭載にこぎ着けた。

Quantum CSSは、Geckoの旧CSSエンジンからルールツリーの仕組みを引き継ぎつつ、Servoの並列処理の仕組みを取り入れるとともに、WebKit/Blinkのスタイル共有キャッシュに着想を得たキャッシュシステムを備えている。いわば各種ブラウザの最先端技術を融合させたCSSエンジンなのだ。

f:id:Rockridge:20171105213420p:plain:w400
ベストミックスのCSSエンジン

スタイルシステムは一般に、CSSに記述されている各セレクターが対象となるDOMノードすべてについてマッチするかどうかの判定を行う(セレクターマッチング)。また、計算済みスタイルが適用されないDOMノードについては、親ノードから引き継いだスタイルまたはデフォルトのスタイルを適用する(カスケード)。インタラクティブなWebページの増加に伴い、これらの処理による負担は重くなる一方だ。

Quantum CSSでは、処理の並列化によってこの問題に対処する。すなわち、CPUのマルチコア化を前提に、DOMツリーを適宜分割して、スタイルに関する処理を各CPUコアに割り当てるのだ。CPUが4コアであれば4つの処理を同時にこなすことが可能になる。手が空いたコアは別のコアが担当予定の処理を取ってくるようになっている(work stealingという)ので、コアが遊んでしまうこともない。

また、Quantum CSSでは、計算済みスタイルをキャッシュしておき、同一のスタイルが適用されるノードに対しては重複した処理を行わないようにする。この場合キャッシュのマッチング処理が必要になるが、Quantum CSSのキャッシュシステムは疑似クラスが用いられるケースなども想定してキャッシュ利用の効率性を高めているという。

以上のほかにも多数の最適化が施されているQuantum CSSだが、その実力はどの程度のものだろうか。MozillaのビルドシステムがQuantum CSSの有効化時に行った自動化テストの結果によれば、Amazon.comの読み込みテスト("laptop"のキーワードで検索した結果を25回表示させ、最初の5回を除いた20回について中央値を取ったもの)において、およそ25%の速度向上が見られた。コンテンツ次第ではあるが、複雑なページほど実力を発揮してくれそうだ。

他方、Quantum CSSに欠点がないわけではない。旧CSSエンジンよりもメモリ消費量は増えるようだ。それとは別に、互換性の問題もある。旧CSSエンジンでは正しく表示されていたWebサイトが、Quantum CSSだと表示がおかしくなるケースがありうる。そこで、Mozillaは問題の出たWebサイトにおいて旧CSSエンジンに切り替える仕組みを導入した(Bug 1403077)。

これまでに述べてきたとおり、Quantum CSSはコンテンツに適用されるものだが、Firefox本体のUI部分にも多数のCSSが用いられているので、その処理にQuantum CSSを適用するのは自然な発想といえよう。既にFirefox Nightly 58にはそうした仕組みが実装されており(Bug 1411532)、layout.css.servo.chrome.enabledの設定をtrueに変更すると有効化される。

Android版FirefoxにもQuantum CSSは投入される予定だ。Firefox Nightly 58には初期設定を無効にした形で実装済みで(Bug 1411802)、今後Nightly 59において初期設定が有効に切り替わる見通しだが、そのままリリース版まで維持されるかどうかは未定である。

将来的にQuantum CSSが必要な箇所すべてに適用され、互換性の問題も解消された暁には、旧CSSエンジンは削除されることになる(Bug 1395112)。つまり約16万行のC++コードがGeckoから消えてRustに置き換わるわけで、コードのメンテナンスしやすさや堅牢性といった点において大きなインパクトを与えるとみられる。

(17/11/06追記)
本文中の「DOMツリーを適宜分割して、スタイルに関する処理を各CPUコアに割り当てる」という記述が舌足らずであったように思うので、補足しておく。Quantum CSSがHTMLパーザーによって生成済みのDOMツリーを切り貼りするわけではない。そのような処理はCSSエンジンの守備範囲を超える。そうではなくて、スタイルシステムが担当する(親)ノードを決めるということが言いたかった。枝分かれするDOMツリーの一部をCPUコアAが、別の一部をCPUコアBがそれぞれ担当するのである。上記の記述は、「DOMツリーにおける担当領域を適宜分割して」と表現するのが適切であった。

タブバー上の人型アイコンを消す(追記あり)

Firefox 57以降、アクセシビリティサービスが有効になっている環境では、タブバー上にその旨を示すインジケーターが表示されるようになっている(Bug 1383051)。インジケーターは人型のアイコンであり、色合いが背景と違うのでけっこう目立つ。

f:id:Rockridge:20171029225459p:plain
タブバー上のインジケーター

アクセシビリティサービスの典型はスクリーンリーダーであり、Firefoxにアクセスするそうしたサービスが存在するときは、原則としてトラブルシューティング情報(about:support)の〔アクセシビリティ〕欄において種類などを確認できる。

問題は、高DPI環境でWindowsのディスプレイ設定が拡大表示になっている場合であっても、インジケーターが表示されてしまう点だ。アクセシビリティサービスを使っているつもりが全くないのに、タブバー上に目立つアイコンが表示され続けることになる。

このインジケーターを消す方法は2つある。1つは、インジケーターの表示設定を無効化すること。もう1つは、アクセシビリティサービスによるFirefoxへのアクセスを遮断することである。前者は、about:configのページでaccessibility.indicator.enabledの設定をfalseに変更すれば実現できる。

後者の方法はもっと簡単で、メニューの『オプション』から設定画面を開き、〔プライバシーとセキュリティ〕の許可設定欄にある「アクセシビリティサービスによるブラウザーへのアクセスを止める」にチェックを入れればOK。本体の再起動を要求されるので、これに応じるとチェックが有効化される。ちなみに、設定値としてはaccessibility.force_disabledが1に変更された形だ。

f:id:Rockridge:20171029232710p:plain
設定画面からアクセシビリティサービスをオフに

積極的にアクセシビリティサービスを使っているのでなければ、Firefoxへのアクセスは遮断してしまっていいと思う。そうしたサービスがFirefoxにアクセスする場合、ブラウザとしては処理を中断して応答しなければならず、知らず知らずのうちにパフォーマンスの低下を招いている可能性もあるからだ。

(17/11/02追記)
ATOK 2016以降に搭載されているATOKインサイトが、Firefoxにはスクリーンリーダーとして認識されるという話がある。アクセシビリティサービスを遮断することでATOKインサイトが使えないと困る場合、インジケーターの表示設定を無効化するのがよいだろう。

(17/11/04追記)
Firefox 57 Beta 13以降、インジケーターは初期設定で非表示となった(Bug 1411591)。Mozillaの開発者によれば、Beta版ユーザーの約7%がこのインジケーターを目にしていたそうだが、どうやらこの割合はMozillaの想定を超えていたようだ。Firefox 57のリリース後に行われるテストの結果を踏まえて初期設定を決めることとなり、accessibility.indicator.enabledの設定はfalseに変更された。

本文にはあまり意味がなくなってしまったが、初期設定においてアクセシビリティサービスがFirefoxにアクセス可能である点は変わりがない。Firefoxのパフォーマンスがインストール当初から良くない場合、「アクセシビリティサービスによるブラウザーへのアクセスを止める」の設定を変更してみるのも1つの手だろう。