月: 2012年3月

サイズやレイアウトがぐちゃぐちゃになった入力フィールドやチェックボックスを直す – UIComponentのインスタンスをダイナミックに作ると大変

清水 咲里

弊社の製品「アポ助」のクライアントはFlashアプリケーションで、ActionScriptを駆使して作られています。 直感的で誰でもすぐに使える画面が好評なのですが、その直感的な操作を実現するために、その時の状態に応じて入力フィールドやチェックボックスなどを動的に生成してレイアウトしています。

ところが、このように動的にコンポーネントを生成してレイアウトするアプリケーションの場合、入力コンポーネントにUIComponentの子クラスを使うとやっかいなことになることがあります。

アポ助はクリニック用の予約管理システムなので、患者様のお名前を入力するフィールドや、診察の種類を選ぶボタンがあり、以下の画像が正しい姿です。

正しい姿
正しい姿

ご覧のように、文字やフィールドなどがきれいに整列して見易くなっています。以下が使用しているクラスです。

テキスト部分: flash.text.TextField
入力フィールド:fl.controls.TextInput
診察の種類:fl.controls.RadioButton/fl.controls.CheckBox
(fl.controlsのコンポーネントは、fl.controls.UIComponentの子クラスです。)

ところが、特定の条件において、これが次のように表示されることがあります。

サイズなどがぐちゃぐちゃ
サイズなどがぐちゃぐちゃ

一目瞭然ですが、フィールドのサイズ設定が反映されずに枠からはみ出ていますし、ラジオボタンやチェックボックスに、肝心のボタンが表示されていません。この問題はUIComponentの描画のタイミングに起因するようです。

この問題はUIComponentのdrawNow()メソッドを呼ぶことで回避できます。つまり、描画のタイミングを明示的に指示する形です。TextInputのwidthやheightの設定が反映されなかったり、チェックボックスが表示されない時などに、試してみてください。

HTTP status code 416 (Chrome)

清水 文行

HTTPサーバのログにはステータスコード416を返していることが結構あったりするようです。Rangeヘッダは先ごろApache Killerで有名な問題がありましたが、特にDoSしようとしているわけでもなく普通のリクエスト。共通項は

  • Chrome (新旧問わず 6.0.472.63, 15.0.874.121, 17.0.963.56, …)
  • GET対象のサイズが6で割り切れる(リクエストは複数ですが対象は高々3つだけなのでたぶんたまたま)。

くらいしか見当たりません。ただし新しめのChromeでは416の直後に再度GETして正常取得しているので、何らかの対症療法が施されているように見えます。https://code.google.com/p/chromium/issues/detail?id=68298によれば13で修正されているようですがregressionでしょうか、はたまた別件でしょうか。Range, If-*ヘッダをログ、ChromeからのRangeはunsetして様子を見ることにします。

誤検知: cmdproxy.exe Trojan.Win32.Siscos.ipv

清水 文行

新しい機械をセットアップするといろいろ起きて楽しいです。WindowsでもGNU Emacsでちゃちゃちゃっと便利に済ませたいときがよくあるのでNTEmacs 23.3をぶち込んだところ、Vulnerability Scanが便利なKasperskyさんが表題の警告を表示。variant部分が3文字です。Trojan.Win32.Siscos.ipvは最近追加された亜種、詳細説明無し。Trojan.Win32.SiscosのNumber of resultsは6453だそうで。データを盗むということのようですがdetached署名でも確認してあり VirusTotalで2/43、しかも片方はsuspiciousなので誤検知ということで良さそうです。(最近出たemacs-23.4-bin-i386.zipの方は署名に使われているkey ID 0x597F9E69(0x587DE7C6597F9E69)な公開鍵がGNUの公開鍵一覧にもメジャーなキーサーバにも存在していないのでFSFに鍵無いと連絡だけしてとりあえず放置してありますが、こちらのcmdproxy.exeはどうだったんでしょうね)

シェルを呼び出してまでWindowsでEmacsを使うこともないのでさくっとquarantineしてくれちゃって良いのですが、一応困る人がいるかもしれないのでunbel32以来久々のfalse detectionの報告をしたところ、「ごめん、誤検知。次で直すね。ありがとー!(超訳)」とのお返事。

問題イベント名: BEX

清水 文行

http://technet.microsoft.com/en-us/library/cc738483(v=WS.10).aspx によれば a buffer overflow or DEP exception だそうな。ってことは例外は全部 ?EX なのか、例外は最大で26個までなのか、はたまた36個までなのか、特別例外とかいう「イベント」があったらまずくないのか、などなどBOFとでも書いておいてくれればいだくはずもない素朴な疑問はおいておいて、バイナリが正しい配布のものであることを確認して、複数のアンチウィルスでも確認、さらに可能であればそれがDEPに対応できていないことを確認した後にわざわざその実行ファイルでのDEPを無効にし、実行完了後に戻すことにします。

今回はWindows用JREインストーラ実行開始直後

JREインストーラのハッシュはどこにも見当たらないのでインストーラ本体のデジタル署名を隅々まで確認。もっともらしそう。「オンラインで解決策を確認してプログラムを終了します」をクリックすると無言のまま終了。何も無いことを確認してくれたんですね。

このインストーラに対してDEPくらい対応してよという声も複数見つかるので、では半べそですがインストーラのDEPを無効にします。 EMET があれば簡単です。’Configure System’ボタンを押し、DEP を ‘Always On’ から ‘Application Opt Out’ に格下げ。’Configure Apps’ボタンを押して jre-6uxx-windows-xxx.exe を追加、DEPのチェックをはずし、OSごとリブート。インストーラを実行してインストール完了後に’Configure Apps’で追加したものを削除して、DEPを’Always On’に戻して完了。