SeleniumBasic：Chromeバージョンアップ後にClickがエラー

コロナが治まるまでChromeのバージョンアップは休止と何かで読んだので、まだ80のままだと思ってました。先日Seleniumで動かそうとしたらドライバが古いとエラーが出て、83に上がってるのに気づきました。知らないうちに81に上がり、82はスキップしていたらしい。

で、80まで動いていたコードの一箇所でエラーが出てしまい焦りました。
検索結果をダウンロードするボタンをClickさせるのですが、対象はこんな感じです。

<form action="download" method="post" name="DataDownload">
    <input name="xxxxx" type="hidden" value="DownloadData" >
    （その他もろもろ）
    <input class="contentsBtn" type="submit" value="検索結果をダウンロード" >
</form>

検索結果が表示されると現れるボタンで、これまでは以下のようにClickさせてました。

Dim objDriver As ChromeDriver
Dim objTemp As Object

（中略）

    Set objTemp = objDriver.FindElementByName("DataDownload")
    If objTemp.IsDisplayed Then objTemp.Click

83ではIsDisplayedまでは通るのですが、Clickでエラーとなりました。

element not interactable: element has zero size

何を怒られているのかはわからない。
しょうがないのでclassの方で要素を取得してみました。

Set objBtns = objDriver.FindElementsByClass("contentsBtn")
For Each objTemp In objBtns
    If objTemp.Value = "検索結果をダウンロード" Then
       objTemp.Click
       Exit For
    End If
Next

これならClickできました。
別のPCでChromeを強制的に80にして試すと、今でも前のコードでClickできました。とにかく81または83で何か仕様が変わったようです。

SeleniumBasic：SendKeysを使わずにテキストを入力

VBAでブラウザを操作するのに、IEからSeleniumBasic+Chromeへ移行してしばらく経ちます。不便に感じていたのがテキストボックスへの文字列の入力です。
IEならValueプロパティに値を設定すればよかったですが、 SeleniumBasicではなぜかそれができません。ネットで調べるとクリップボードに値を設定して、テキストボックス上でCtrl+vをSendKeysで実行するのが定番のようでした。なので今まではこうしていました。

Dim objDriver As ChromeDriver
Dim objKeys As Selenium.Keys
Dim objTemp As Object

    Set objDriver = New ChromeDriver
    objDriver.Get (URL)
    objDriver.Window.Activate
    Set objKeys = New Selenium.Keys

（中略）

    Set objTemp = objDriver.FindElementByName("txtExample")
    objTemp.Clear
    objDriver.SetClipBoard Sheet1.Range("A1")
    objTemp.SendKeys objKeys.Control, "v"

1回入力するくらいなら問題ありませんが、数十回数百回とループさせる場合は実行速度が遅く感じます。また実行中にうっかり他のアプリケーションでコピーしてしまうと、当然それがペーストされてしまいます。

解決しようとさらに調べていたところ、 ExecuteScriptというメソッドがあることに気づきました。JavaScriptの文字列を実行できるようで、これならValueに値を設定できることがわかりました。
上の（中略）以下は1行で済みました。

    objDriver.ExecuteScript "document.getElementsByName('txtExample')[0].value=" & Sheet1.Range("A1")

とりあえずこれで解決です。

ニコニコのHTML5版（β）を見て、特にコメント表示のことなど。

ニコニコもようやく脱Flashへ向かうようで、先週HTML5版の視聴ページが公開されました。

「動画視聴ページ HTML5版（β）」提供開始のお知らせ - ニコニコインフォ

まだ対象は一部のユーザーに限られているようですが、幸い自分は切り替えられたので見てみました。
下図はプレーヤーのサイズを標準（中画面）にしたところです。

HTML5版の方が若干小さく見えますが、動画の表示領域は同じ（640×360） でした。HTML5版は黒枠が無くなった分、コメントの表示領域が少し減っています。
下図は大画面にしたところです。

Flash版に比べてかなり大きくなります。デスクトップPCだと従来の大画面は小さく感じて拡大して使っていたので、これはありがたいと思いました。
下図はフルスクリーンにしたところです。

どのサイズにしろ、動画を開くのが軽くなり快適に感じました。

まだベータ版だからか、設定は下図の項目しかありませんでした。

またコメントパネルで過去ログを表示しようとしたところ、日時指定がプルダウンでスマホアプリのようなUIになっていました。

さてコメントの表示ですが、標準サイズで見るとHTML5版の方がくっきり見えます。

文字に黒い縁取りがあるからです。実際に見るとわかるのですが、HTML5版のコメントはFlash版のような立体感がありません。そのため縁取りをしているのかなと思いました。
フルスクリーンで見るとけっこう違和感がありました。

文字のサイズもFlash版より大きくなっています。これは改良していただきたいです。

改行のコメントもできるのですが、従来のCtrl＋「.」やAlt＋「1」「0」といったコマンドは効きませんでした。
その代わり、あらかじめテキストエディタ上で改行を入れたコメントをコピペすることができました。コマンドを知らなくてもかんたんに改行できるようになるのは、いいことだと思いました。
下図はbig16行のコメントを複数重ねたところです。

少なくともこのケースで見る限り、HTML5版でも同じように表示されるみたいでした。

Flash版と決定的に異なるのは、CJKフォント変化が発生しないことです。

一方で、フォントを指定する新たなコマンドが追加されています。

[動画]プレイヤー（HTML5版） - ニコニコヘルプ

下図はWindows 10上のMS Edgeで、新コマンドgothic・minchoを試したところです。
※Flash版では、このコマンドの効果は反映されません。

字形からの推測ですが、gothicは游ゴシック・minchoは游明朝ではないかと思います。
Chromeだとminchoの字形が少し違いました。

これも推測ですが、同じ游明朝のDemiboldというやつに見えました。

それにしても游ゴシックや游明朝？（7や8.1にはないのでは）と思い、7でも見てみました。

gothicはGulim・minchoはSimSunのように見えます。これはChromeでも同じでした。

従来のフォント変化でおなじみのGulim・SimSunが表示されるということは、開発側としてはこちらが意図した挙動なのかもしれません。しかし日本語版Windows 10に、Gulimは標準ではインストールされていません。SimSunはインストールされていますが、これも表示されていません。今後この10と7の違いがどうなるのか、気になるところです。

いずれにしても、フォントを明示的に指定できるようになるのは画期的だと思いました。
特定の記号によって意図しないフォント変化が起きることもなくなります。またOSのバージョンやブラウザの違いによるコメント表示の差異も、これでなくなっていくことを期待したいです。

Chrome 51：SimSun化に対して特殊な文字

前回の話の続きですが、その前にSimSun化とは別のフォント変化を見つけました。

以前、Chrome上の半角カナの表示においてカギカッコなどの記号類だけArial Unidode MSで表示されているという話を書きました。今は仕様が変わっているようですが、半角の記号類が特殊であることは変わらないようです。
下図の半角カタカナのコメント表示は、Arial Unidode MSの有無に関係ありません。フォントはメイリオだろうと思われます。

これに半角のカギカッコを追加してみると、先頭の半角カナのフォントが変わります。その字形はArial Unidode MSの有無によって異なります。

半角カギカッコによるフォントへの影響はSimSun化のそれと同じように見えます。
下図はカギカッコとカタカナの位置を入れ替えた場合の字形の違いを示しています。

2016/7/21追記：
以下の現象はChrome 52では起こらなくなったようです。

半角カギカッコの効果は全角文字に対しても同じでした。

半角カギカッコの直後の文字は、Arial Unidode MSがあればArial Unidode MS、なければＭＳ Ｐゴシックではないかと思います。

SimSun化の話に戻ります。
前回SimSun化文字の直後の文字しか変化しないと書きましたが、半角カギカッコが間に入るとそうではありませんでした。

この状態は半角カギカッコがいくつあっても同じでした。

これとは別に、似たような挙動をとる文字がありました。全角の長音記号です。

SimSun化文字の直後でなくても、長音記号が連続する限りSimSun化が続きます。
また、連続する長音記号の中でなら何文字めでも「あ」がSimSun化します。

ただしこの効果は漢字だと発生しないようでした。

また、ひらがなであっても2文字めがあるとそこでメイリオに戻されるようです。

たまたま長音記号で気づきましたが、実は全角のカギカッコでも同じでした。どういう理屈なのか、これらの記号類はかな文字とは区別されているようです。
なお、この挙動は冒頭の半角カギカッコによるフォント変化の中でも同様でした。

Chrome 51：SimSun化の発生

2016/7/21追記：
下記の現象はChrome 52では起こらなくなったようです。

Chrome 51からかどうかわからないのですが、先日の日本語フォントが変わった件をちょっと調べていたらSimSun化が起きることに気づきました。

U+2FF0がどこから出てきたかですが、SimSun・メイリオ・Arial Unicode MSそれぞれのCMAPを比較してSimSunにだけあるものを抽出しました。と言っても同じ条件の文字すべてでこの現象が起きるわけではなく、今のところU+2FF0～U+2FFBでしか確認していません。

このSimSun化の特徴は、フォント変化文字U+2FF0の後にある１文字めしか変化しないことです。

また、U+2FF0をコメントの先頭以外の場所に置いても何も起こりません。
これは先の49から起きるようになったフォント変化の特徴と一致しています。ひょっとすると、49の時点でこのような挙動になっていたのかもしれません。

ただしU+2FF0の前で「リセット」する操作を行えば、何文字めでもSimSun化を起こせることがわかりました。下図の「↓」の部分にはU+200Cを挟んであります。

Arialで表示される文字を置けばこうなるようです。
改行を入れた場合も同様でした。

なお、下図はIEでの表示と比較したところです。IEだとこの文字の組み合わせではSimSun化は起きません。

SimSun化文字を置いてやれば、ChromeとIEの表示はほぼ同じになります。

Chromeのこのような挙動を見ることになるとは思っていませんでした。仕様は変わっていくものですね。

Chrome 51：日本語フォントの変更

今朝Chromeを51に上げたところ、ニコニコのコメントで日本語フォントが変わっているのに気づきました。

字形から、メイリオだろうと思われます。Chrome 21でフォント変化が起きなくなって以来の衝撃でした。
とは言え、いずれこうなるのではとはだいぶ以前から考えていました。前バージョンでXPのサポートを打ち切ったことで、ＭＳ Ｐゴシックという古いフォントの使用をやめたのではないでしょうか。

問題は文字幅です。漢字は一見同じ幅のように見えましたが、複数並べるとIEの表示よりChromeの方が少し狭いようです。

一方、かな文字の幅は明らかにChromeの方が広くなっています。

歌詞字幕などで、文字幅に依存するようなコメントだと影響がありそうです。

今のところＭＳ Ｐゴシックがメイリオに変わったという以外、違いには気づきません。記号類など時間があったら調べてみたいです。

それにしても、メイリオの太字だと同じコメントでもなんか濃く見えます。スマホでの表示っぽい。

Chrome 49：フォント変化の発生

先週リリースされたChrome 49を使っていたところ、ニコニコのコメントの一部でフォントが変わっているのに気づきました。

しかしよく見ると、フォントが変わるのは特定の文字に隣接した場合であることがわかりました。上の例で言うとU+2581です。

この例の場合U+2584とU+2588はArial・他はLucida Sans Unicodeだと思いますが、U+2581だけはLucidaにもありません。MS Officeの入った環境ならArial Unicode MS、入っていなければＭＳ Ｐゴシックだろうと思います。Arial Unicode MSがないと下図のような表示になりました。

特定の文字と隣接すると変わるというのは、まるでIEのようなフォント変化です。

ただしU+2581を先頭以外の場所に移動させると何も起きませんでした。

U+2581と同じ現象を発生させる文字は他にもありました。しかし一見同じ条件に見えても何も起きない文字もあり、法則性は不明でした。

字形の違いがはっきりわかる例：

以上の例ではLucida Sans UnicodeがArial Unicode MSに変化したのではないかと思われますが、他のパターンもありました。下図のケースはSegoe UI SymbolがＭＳ Ｐゴシックに変化しているように思います。

この例ではArial Unicode MSの有無は関係ありません。
字形の違いがはっきりわかる例：

またSegoe UI SymbolがArial Unicode MSに変化したと思われるケースもありました。この例ではArial Unicode MSの有無で結果が異なります。

他にも、Lucida Sans UnicodeがＭＳ Ｐゴシックに変化したと思われる例：

Arial Unicode MSがＭＳ Ｐゴシックに変化したと思われる例：

などに気づきました。まだあるのかもしれません。

Chrome 21以降、PepperFlashでこのような現象は見たことがありませんでした。
一時的なバグなのか仕様の変更なのか、気になるところです。