2018年10月31日水曜日

KB4462933をインストール後HID準拠ゲームコントローラー(ジョイパッド)が接続されているとスリープしない・・・?

変な表題ですが、理由があります。
結論だけ言うと「KB4462933を再インストールしたら再現しなくなった」ように見せかけて「やっぱり再現した」ものの「再インストールしなくても再現しなくなった」です。
何が何だかさっぱりわかりません。

調査を進めてみると、もしかしてこの事象が発生するのはKB4462933に限らないかもしれない可能性が疑われました。
さらにその後、やっぱりKB4462933が原因だろうと考えざるを得ない事態が出来しました。
ちょっと複雑なので、順を追ってご説明いたします。

まず、以前にもありましたが、またもやUSBで接続されたジョイパッド(MS用語では"HID 準拠ゲーム コントローラー")が接続されていると、アイドル状態が続いて既定の時刻になってもスリープどころかブランクスクリーン(MS用語では"ディスプレイの電源を切る")にもならなくなりました。

あくまでもアイドル状態が指定時間続いた場合にスリープに入らないので手動でスリープを指示すれば正しくスリープに入ります。
ジョイパッドを抜去すると再度アイドル状態が続いた後に自動でスリープに入るようになります。

今回はKB4462933を適用した直後からこの事象が発生しました。

イベントログで確認しても、このKB4462933がインストールされてから丸一日後(たまたま長時間不在の中での更新でした)に気が付いて、試しに手動でスリープボタンを押下するまでスリープに入っていないことが記録されています。
家族に聞いても(常時私のPCを監視しているわけではないのでイベントログほど確実性はないものの)画面がつきっぱなしだったと言われましたので、スリープに入っていないことは確実です。

前回同じようなことを経験しているので、試しに接続されたままだったジョイパッドを抜去して待ってみると、正常に一定時間経過によって自動的にスリープしました。

試しに再起動してみても、ジョイパッドを接続しなおしたり接続ポートを変更してもこの状況は変わりませんでした。

一応、極めて黒に近い灰色に思われましたが、このまま犯人だと決めつけて間違っていたら間抜けなので、念のためにKB4462933をアンインストールして同様の試験したところ、自動的にスリープに入ることを確認しました。

さらに念のため、アンインストール前と設定が変わっていないかどうかの比較のため、以前のようにデバイスマネージャで電源設定を確認したりコントロールパネル->電源オプション->プラン設定の編集をチェックしましたが、両者の間で変更点は全くありませんでした。
powercfg.exe /requestsの結果も双方「なし。」の羅列で阻害要因なし。
powercfg.exe /energyの結果も双方阻害要因なし。

言い方を変えれば、powercfg.exe /requestsの結果および/energyの結果にKB4462933適用済の時とKB4462933未適用の時での差異が一切ありません(が挙動は異なる)という状況でした。

ここまでで犯人もわかったことだし、面倒ではあるけど対策はあるわけだからよしとして、暇なときにでも今度はもうちょっと原因を突っ込んで調べてみよう、ということでこの記事も一旦終わるはずでした。

ところがどっこい、そうは問屋が卸してくれませんでした。

KB4462933を再インストールしたところ、なんとジョイパッドを接続しっぱなしでも今度は正常に指定時間ピッタリに自動的にスリープに入るのです。

同様に再起動してみたり接続ポートを変えたりしてみても、時間経過で正常に自動的にスリープします。
電源設定もpowercfg.exeも再インストール前とアンインストール前の結果と比較してみましたが、やっぱり同一です。

しかし、KB4462933を初回インストールしたあとの再起動後から一切スリープしなくなったのは確かです。
なぜなら、私が不在時にこのWindowsUpdateによる更新が行われましたので、操作者がいない以上、正常ならば再起動してから一定時間経過後にイベントログにKernel-Powerのイベント42、「スリープの理由: System Idle」が記録されていなければなりませんが、その記録がないことからも明らかです。
スリープしているはずの時間帯だけでなく、翌日手動でスリープするまでにどっさりESENTイベントID916などのゴミログがイベントログに大量に、かつ間断なく記録されているのも傍証となります(まさかあのゴミログが役に立つとは!!)。

問題は、KB4462933そのものが原因ではないことです(後述しますがこの段階ではそう見えたものの、この結論は実は早すぎるようです)。
アンインストールして再インストールしたら事象が再現しないのですからそう言わざるを得ません。

(ここから上記の誤った結論に基づいた仮説が縷々続きますが、その後の新しい現象が確認されたことにより無駄な文章となっております。表題の趣旨としては合致しないため、本来は削除すべきですが、スゴイ恥ずかしいのでblogの趣旨としてどう恥ずかしいのかしっかり残すために文字を一回り小さくして残させていただきたいと思います。)
ただし、ここから先は事実ではなく仮説になってしまいますが、今回のケースではKB4462933を入れたことによってスリープをしなくなったものの、再インストールを行うことによって正常にスリープするようになったという現象自体を見ると、WindowsUpdateで品質更新プログラムを適用する際に実行されていると思しき何らかの作業スクリプトに不備があり、このケースと同様にスリープしなくなるという現象を惹起する可能性に思いを致さざるを得ません。
ということは、つまるところ、別の品質更新プログラムや機能更新プログラムでもその修正・追加内容に拘らず同様の事象を再現する可能性があるということになります。

というのは、一般的にはこういった更新適用スクリプトには固有の手続き以外の共通化できる手順というのがあって、そういった部分は毎回書き直したりせず、使いまわされることが多いからです。
その部分に、たとえば更新中は一時的に自動スリープを抑止するような手続きが含まれており、かつ何らかの条件で抑止を解除する手続きの中で一部正常に元に戻せなくなるケースが見逃されているのではないか、などの可能性が考えられます。
また、様々な環境用に一切合切まとめられてしまっている品質更新プログラムの中から、当環境に適したモジュールを抽出して適用する際、特定条件下ではスクリプト部分に問題があって、誤適用してしまう可能性も考えられます。

もしこの仮説が正しければ、の話ですが、もしも今回同様なケースに見舞われた方がおいででしたら、スリープしなくなってしまった直前に適用された品質更新プログラムや機能更新プログラムを再インストールしてみてはいかがでしょうか。
もしかしたら、今回のケースのようにあっさり直ってしまうかもしれません。

今回のケースでも「アア、マタカ」と面倒くさがってジョイパッドを抜去するだけの対策で済ませていたら、品質更新プログラムの再インストールで正常な挙動に直せることが分からずじまいでした。

仮説を唱えるなら実証して見せろ!とお叱りを受けそうです。
ごもっともです。

これは言い訳ですが、KB4462933のインストールとアンインストールと各段階でのデータどりを1ターンとすると、当環境では1ターン当たり2時間弱かかります。
しかも、一般的に機能更新プログラムなどがWindowsUpdateで適用される前の再起動は「前回の」WindowsUpdateでリブートがかかった後、何日~何十日も再起動されないままで適用されるという条件もあります(今回の事案では12日間再起動されていませんでした)。
私にはそれを検証するだけの時間的資源がありません。本当に申し訳ございません。

言い訳だけでなく、危うくKB4462933冤罪事件を免れましたので、恥の記録としてここに記録する次第です。
お読みいただきありがとうございました。

・・・とは終われませんでした
問屋が卸してくれない状況で輪をかけてこれですから、言うなれば元売りも卸してくれないとでも言えばいいのでしょうか。

KB4462933を再インストールして正常にスリープをすることを確認したその当日の数時間後には、スリープしなくなる現象がまたもや再現したのです。

KB4462933を再インストールして正常にスリープができたことを何度も確認してから、そのままジョイパッドを接続したまま再起動もせず、数時間PCを使った後、所用で1時間ほど離席して帰ってくると、画面がまばゆく輝いていました。

イベントログも確認しましたが、離席した時刻以後は確かにスリープが記録されていません。

その間、繰り返しになりますが、検証のための最後のスリープを確認して復帰させた後は再起動などシステムに手を加えるようなことは何もしていません。
テキストエディタとブラウザを使っていただけです。

仕方がないのでもう一度ジョイパッドを抜去してスリープするか確かめたところ、抜いてあれば時間経過でスリープすることを確認しました。

もうなんだこれ?と途方に暮れつつ、ジョイパッドを接続したままにして、まだ用事が済んでいなかったため再度離席したのち所用を終えて帰ってくると、今度はスリープしているではありませんか。

うーん。魂消たなあ。
この現象はこれまでとはまた違った新現象です。

KB4462933のアンインストール前でのケースでは、ジョイパッドを接続しなおしてもシステムを再起動しても兎にも角にもジョイパッドが接続されている限りスリープに入らない状態は変わらなかったのですが、今回はKB4462933をアンインストールしなくともスリープに入ってしまったわけです。
当然、電源周りの設定とpowercfg.exeの出力も比較しましたが、これまた他と同様、まるで違いは認められません。

前回のアンインストール前の挙動とは明らかに異なります。
いったい何なんだろう。
帰ってきてまたまたパッドを挿抜したりなどのこれまでと同様のテストを行いましたが、正しくスリープに入ってしまいます。

こうなると、現時点では一度スリープから復帰して何時間も使ったあとはスリープに入らなくなったという事しか言えなくなりました。

一度はKB4462933は冤罪とみなしそうになりましたが、実はそうとは言い切れないのではないかという疑いが再浮上してしまいました。むしろ、このパッチが当たるまでは何の問題もなかったのですからますます疑惑が深まってしまいました。

(ひょっとして、その間にスリープ抑止リクエストが入った場合はどうなるかと思いついてしばらくwindows media playerでDISPLAYとDRIVERとPROCESSに抑止が入るようにして使った後、スリープに入るかどうか試してみましたが、正しくスリープに入りましたのでこれは関係ないようです。確かに再インストールしてから特別なスリープ抑止リクエストがかかるようなアプリを起動した覚えはないので、無意味なテストでした。)

とにかく私の先の仮説とやらは大仰に書きまくった割には大外れでとっても恥ずかしいので、このblogの趣旨にとてもふさわしいため、このままこの記事を公開させていただきます。

いやほんと、魂消たなあ。
新たな仮説を打ち立てないと検証方法も設計できないし、今のところお手上げです。

原因を特定することが果たしてできるのか先行きが大変不安な展開となっております。
申し訳ございません。

2018年10月27日土曜日

Android用のブラウザで暗い背景色で長文が読みたい

当blogは副題をネットウラシマと申しまして、浦島太郎感漂う「こんなことも知らんのか」と言われるようなハズカシイ話題を記録するblogです。

そこで、今回のお題は「Android版のブラウザでの長文読書は背景が真っ白で目につらい。」です。
対策は「背景を黒く(暗く)すればいい。」

当たり前すぎます。
が、今時のメジャーブラウザはこれがまったくできない、またはプラグインが必要とされることに衝撃を感じたので記録する次第です。

結論から先に書きますと、(Chrome以外でメジャーと言えるブラウザの存在があるとして)メジャーどころではAndroid版Firefox+アドオンでのみ実現可能でした。

Firefoxで背景色を暗くするアドオンは複数あるのですが、その中ではDark Readerが個人的には最も出来が良いと感じ、採用しました。PC版ChromeおよびSafari用にも同一アドオンがあります。

他はあまり良い評価点を与えられなかったので名を挙げませんが、速度に難あり(白いままの画面が割と長い間、といっても数秒、表示されてしまう)、色に難あり(反転しなくていい文字色や画像も単純にinverseされたり特定の文字色以外は全部白になったり等)、文字数が多くなると急に無反応、スクロールするとスクロールされた領域が白いまま、など、数は多かれど実質的にはとても使えなかったり、ザンネン感が高いものが多かった中、比較的動作が良好だったのが採用の理由です。

加えて、Android版Firefoxのプライベートタブでは、画面上部のタブ名表示部もアドレスバー表示部も暗色表示になるため、その部分を暗色表示にするためだけのアドオンを探さなくても気になりません。
この部分は「設定」->「一般」->「全画面表示でブラウジングする」オプションスイッチを有効にしたうえで、なおかつ、画面を上にある程度スクロールさせないと引っ込まないという大変鬱陶しい仕様ですので、最初からその部分が暗いプライベートタブで読むと手っ取り早いと思います。

実際にやってみた範囲内では以上です。

以下、なんでAndroid用のブラウザの画面を暗くしたいのかを含めた前置きと、なぜ結論で述べた以外のブラウザで実現できないか、などを書き連ねた戯言です。

子供のころから寝る前に本を読まないと寝付けない習慣がついてしまっていて、枕もとの照明で読んでいました。

ところが、スマートフォンが普及して高解像度で文字も美しく表示され、さらに一画面内の文字数も文庫本1ページ程度は軽く表示できてしまうに及び、枕もとに本を積んでおく必要もなくなり、照明をつけなくとも読めるし本より軽いのですぐにスマートフォン、その後はタブレットを用いるようになりました。

読書に用いるアプリ、例えばKindle、自炊jpeg化した小説などではPerfect Viewerなど当然のように白黒反転機能がついています。
Android4.2だか4.3まで標準搭載されていた「(アプリ名としての)ブラウザ」(ややこしいので以後旧標準ブラウザと表記します)にも、実は画面の反転表示機能があります。

尤もブラウザを使って本(長文)を読むことはなかったので、主に白黒反転機能があるアプリだけでこれまで読んできました。

ところが最近、中国古典に再度嵌りそうになっています。
Web上に面白い文献がたくさんあり、すぐに原文を参照出来たり、意味が分からない言葉の解説をすぐに調べることができ、これは寝る前にちょっとづつ読むのにいいな、画面が大きくて複雑な漢字でも明瞭に表示できるタブレットで読みたいなと思いました。

が、現在の主流ブラウザの背景色は白い。とても白い。
暗い中で真っ白な画面を見た瞬間、虹彩を絞って瞳孔を狭める筋肉に痛みが生じるくらい急激な動きを生じる程度に極めて白く、そして眩しいのです。

とてもではありませんが「読む」なんてできません。せいぜい「見る」程度でもすぐにギブアップです。
普段PCで使うモニタよりも段違いに近くで光る白い板を、暗い中で見つめることになるのですから当然といえば当然です。

旧標準ブラウザを搭載するスマホも手元にあるにはあるのですが、XperiaAなので画面が小さいためタブレットで読みたいということで、調べてみました。

さて、ようやく本題です。

まず普段だったら大本命のAndroid版Chrome。
PC版と違い、アドオンも入れられません。だからカスタマイズもできません。
このケースでは絶望です。

旧標準ブラウザもGoogle製にも拘らず、Chromeには旧標準ブラウザのような反転機能が搭載されていないどころか、アドレスバーも何もかも真っ白です。
但し、何の解決にもなりませんが念のために申し添えますと、シークレットタブの場合はアドレスバー表示部だけ暗灰色になりますが表示中のコンテンツの背景色には何の影響も与えません。そりゃそうです。

Android版Chromeを含めて、どうしてもブラウザ自身で表示中のコンテンツの背景色を暗くすることができないとすれば、OSの機能を使って色反転する手があるだろう、と思われるかもしれません。確かAndroid5だか6だかで搭載された機能です。
しかし、当然ながら略図や地図、石碑や鼎などの写真などの画像も反転してしまいます。さらに当然ながらブラウザ以外も反転します。
画面上部の通知領域と下部のナビゲーションバー(戻ったりするボタンがあるバー)も当然ながら色反転されてしまいます。
通常この両者の背景は黒なので、反転すると白くなります。一部だけ輝いていて眩しい上に余計目障りになってしまいます。
じゃあ両者を白くする/できるホームアプリを入れれば解決でしょ、と言われそうですが、そこまでするのは余程そのブラウザに対する忠誠心が高い人に許される特権でしょう。

そこまでして使うほど愛するブラウザなら別ですが、そもそも、単純に不便ですよね。

従って、あくまでもブラウザ内だけで表示コンテンツの背景色およびガワ(アドレスバー等)を暗色で表示できるブラウザを探しました。
以下、それを踏まえて縷々続きます。

お次はAndroid版Edge。インストールしたことがないしWindows10版でも自作javascriptを使った当blog用コンテンツの動作確認のためだけにあるストレージの肥やし感満載のMS期待の星です。
Chrome以外のブラウザが出てくること自体は大歓迎ですので、試しにインストールしてみましたところ、これも真っ白。背景色を暗色にするオプションも見当たらず、アドオンも利用不可。
PC版ではいつかIEのシェアを抜く日が来ることをお祈りいたしつつ結局アンインストール。

今度はAndroid版Opera。わかりやすいところに「ナイトモード」という切り替えスイッチがあるので一瞬「おおおっ」と一気に胸が高鳴りますが、実はガワが暗色に変わるだけでメインのコンテンツには適用外です。
他ブラウザでもシークレットだかプライベートだかのモードで開けば大抵そのあたりは暗色ですのであんまり魅力がありません。
ていうか最近ナイトモードとか流行ですねぇ。
平たく言っちゃえば、単純にブルーライト商法ってやつですかねぇ。
でしょうねぇ(自己納得)。

そしてなによりAndroid版Operaも背景色を暗色にするオプションが見当たらず、アドオン適用不可能のためカスタマイズ不可。
個人的にはPC版Opera12までは相当お世話になっていたため、過去一瞬だけAndroid版Operaを使ったことがあるのですが、その際は様々なサイトがまともに表示されずにレイアウトが盛大に崩れていたので即アンインストールした覚えがあります。
今回も、要件に合致しないためまたもお払い箱にせざるを得ませんでした。

今度はAndroid版Firefoxです。先の結論で申しました通り、Firefoxにアドオンを適用出来たおかげで要件を達成することが出来ました。

完全に個人の環境のせいだと思うのですが、本当はこれは避けたかった。
利用したいタブレットがMediaPad T2 Proで、この端末でFirefoxを使うと、Firefoxの初回のページ読み込みが何かのタイムアウト待ちに引っかかっているらしく、自宅サーバのホームページだろうがgoogleの検索ページだろうが、ともかくなんでもかんでも初回表示に必ず数十秒かかるためです。

同じAndroid版Firefoxでも他のスマートフォンでは全くそんな現象は起きませんし、当然他のブラウザでは一切そういったことは起きないのですが、起動後一度でも読み込みを完了しさえすれば速度的には問題なくなりますし、ページのレイアウト崩れもあまりないというメリットもありますので、Windows版とLinux版ではお世話になっていることもありますし、これからAndroidでもお世話になることにいたしました。

他にもAndroid版ブラウザはあまたありますし、中には反転機能を最初から備えたブラウザもあるのかもしれませんが、とりあえずはこれで運用してみたいと思います。

それにしても、PC上では背景色が黒くないと嫌なのはテキストエディタとvt100エミュレータくらいで、これはMS-DOSのころのアプリは背景色が真っ黒なのが一般的だったなど慣習的なもので、眩しさとかは全く関係がありません。現に、個人で気軽に使えるマルチウィンドウシステムが普及した後で使い始めたIDE(VisualC++とか)やらExcel,Word等の背景が真っ白でも全然違和感を感じません。当blogの背景色も真っ白ケッケです。

部屋が暗い中でPCを使うなんてこともありませんので、背景色を暗くしたいということを切実な要望として感じるのはスマートフォンやタブレットならではといえるのかなあ、と勝手に思う次第です。

以上、恥の記録と長大な駄文でした。
お読みいただき、誠にありがとうございました。

2018年10月26日金曜日

Firefox 63.0 でサイドバーのブックマークと履歴の行間を狭くする方法

面倒なので数日ほっぽいといた更新をようやく受け入れたところ、Firefox 63になりました。
更新したら、サイドバーの行間がドーンと間延びするようにされてしまいました。

まあ、正直現状におけるPC版のFirefoxの存在意義はChrome一強の片隅でひっそりと佇んでくれていることにあると思っていますので、余計な愚痴は差し控えたいと思います。

さて、それにしてもやっぱり間延びしすぎて見づらいので、Firefox63でサイドバーの行間を狭める別の方法を考えます。

とりあえず、以下の方法でどうでしょう。
なお、以下の方法で使用している-moz-tree-ホニャララはFirefox64からWebコンテンツから使えなくなるそーでーすどどーん。
しかし、Webコンテンツから、っていう文言が私にはよくわかりません。単にアドオンや表示したページからjavascriptなどで操作ができなるという意味なのか、XULそのものの廃止に向けた準備作業なのか、ブラウザマニアでもなんでもないのでさっぱりです。

ま、ついでなんで試してみました。
今回ご紹介するuserChrome.cssに記述する手法の場合は、手元の開発用Windows10でbeta版のFirefox64.0b3で試してみましたところ、問題なく行間が狭まりました。
ついでにNightly版のFirefox65.0a1(2018-10-25)でも問題なく行間が狭まりました。

Nightly版はbetaですらないのでまだ何とも言えませんが、beta版のFirefox64.0b3の場合はリリースが2018/12/11に迫っており、その後は来年までクリスマス休暇ですので多分このままではないかと思います。
尤も、顔を真っ赤にしてこれから大修正を加える可能性もありますので単に利用させていただいているだけの私には何とも言えません。
  1. メニューの「ヘルプ」から「トラブルシューティング情報...」を開く。
  2. 「アプリケーション基本情報 」テーブル内の「プロファイルフォルダー」行の「フォルダーを開く」ボタンを押下する。
  3. 「chrome」という名称のフォルダがなければ手動で作成し、chromeフォルダーを開く。
  4. 「userChrome.css」というファイルがなければ、chromeフォルダー内に手動で作成し、メモ帳で開く。
    なお、拡張子を表示しない設定になってたりしてuserChrome.css.txtなんてファイルを作ってしまうお茶目を演じてもいいですが意図する結果は得られません。
    また、メモ帳以外で開くアプリケーションを決定する際になんでメモ帳を指定しているのかわかんないからWordでいいやとか面白いことをなさっても意図する結果は得られませんのでご注意ください。
  5. 以下の呪文をコピーしてメモ帳にペーストして保存する。
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    @namespace url("http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul");
    #bookmarksPanel, #history-panel {
      font-size: 9pt !important;
      font-family: "Meiryo UI" !important;
    }
    treechildren.sidebar-placesTreechildren::-moz-tree-row{
      margin-top:-3px !important;
      margin-bottom:-4px !important;
    }
    treechildren.sidebar-placesTreechildren::-moz-tree-row(hover){
      margin-top:0px !important;
      margin-bottom:0px !important;
    }
    treechildren.sidebar-placesTreechildren::-moz-tree-row(selected){
      margin-top:0px !important;
      margin-bottom:0px !important;
    }
  6. Firefox63を再起動する。
ちょっと狭すぎるよなぁ、という場合には負の値を正の値に近づけて調整してみてください。
Firefox62までは上記の設定だと狭すぎると思います。Firefox62までの調整方法は以前の記事のコメント欄でご紹介しましたが、改めて文末にご参考としてご紹介いたします。

やけにJavascriptで動的に生成した画面の動きが他ブラウザに比べて甘いとか、いまだにonclickとondblclickを同時にきちんと発火させられない(EdgeやChromeではとっくに実装済)とか基本的な機能はほっぽっとくくせに、こんなことに血道をあげて変更を加えてくる人的リソース配分の余裕っぷりがうらやましいですね。あ、愚痴かなこれ・・・
がんばれFirefox,シェアがどんどん下がっていても、目指す方向性がさっぱり周りからは見えなくても。

ご参考: Firefox62までのサイドバーの行間を狭める定義。
なお、広くする分にはこの方法で広げられます。
上記手順のうちコピー内容を以下の3行に変更してください。
treechildren.sidebar-placesTreechildren::-moz-tree-row{
height:1px !important;
}
以上です。