プライベートのメインブラウザは Firefox なのですが、このところ 東京アメッシュ だけなぜか表示が異常に遅くなってしまいました。IE や Chrome はすぐに表示されますので、Firefox 固有の問題のようです。
Firefox を起動後、東京アメッシュ の初回表示だけが30秒ほどかかってしまいます。2回目以降はすぐに表示されます。ブラウザを閉じ再起動しても初回が遅い事象が再現されます。「重い」というより通信処理待ちの遅延のような感じです。
遅延に気付いたのはバージョンが36.x頃だったと思いますが、時間はかかりますが30秒程度で表示されるのでしばらく放置していましたが、少し時間が取れましたので調査してみました。環境は Windows7 32bit ですが、64bit でも同様の症状が再現されてます。ただ 東京アメッシュ の推奨ブラウザに Firefox の名前がないのが少々気になりますが。

Firefox ユーザは少数なのかあまり情報がなかったのですが、ここにきて Firefox Input(Twitter) や 2ch で、ちらほら同様の症状の報告が上がってきました。
Firefox もとい Mozilla といえば Netscape Navigator Gold 2.0 からのコアユーザでして、かれこれ20年になりますかね（汗）

• Mozilla – Firefox Input 5300394 5285604 5285604
  

• 2ch – Mozilla Firefox Part274©2ch.net 764 781 784-785
  

この 2ch の 781 レスから、どうやら Firefox 設定の「オプション > セキュリティ」タブの「攻撃サイトととして報告されているサイトをブロックする(K)」のチェックを外すと直るらしい。

「攻撃サイト…」「偽装サイト…」についての説明は mozilla support に詳しく記載されています。

オプション > セキュリティ	説明
攻撃サイトとして報告されているサイトをブロックする	この設定は、マルウェアのサイトやファイルから防護します。
偽装サイトとして報告されているサイトをブロックする	この設定は、閲覧者をだまして個人情報や銀行の暗証番号などを入力させようとする詐欺サイトを警告します。

この「攻撃サイト…」もとい「セーフブラウジング」のキーワードからさらに調査しますと MozillaZine.jpフォーラム に辿りつきました。

• MozillaZine.jpフォーラム

こちらの情報ですと「攻撃サイト…」に加え「偽装サイト…」についても違いがあるようです。また「東京アメッシュ」だけでなく「バンダイチャンネル」でも同様の症状が起きているようです。
確かに「攻撃サイト…」のチェックを外しますと「東京アメッシュ」が正常にすぐ表示されますね！

ということで、この表示遅延の原因やボトルネックがどこなのかを調査してみることにしました。
まずはいつからなのか、バージョン毎に表示速度を調べてみました。表示速度の計測にはブラウザ(クライアント側)の問題ですので、お手軽なブラウザ機能の Navigation Timing API を使用しました。いわゆる Javascript の window.performance でブラウザの一連の処理速度を計測できます。
詳細は割愛しますが、impressが提供しているブックマークレットによる計測を使用することにしました。
ブラウザ(クライアント側)の問題ということは、処理速度はPC性能に左右されますので、フォーカスするのは処理時間そのものではなく設定による処理時間の差になります。

上記の結果から、32.0.3までは問題なかったのが、33.0以降初回表示が遅くなっているのが見てとれます。また33.0～36.0.4までは「攻撃サイト…」「偽装サイト…」ともチェックを外さないと直らなかったのが37.0.2では「攻撃サイト…」のみとなっているのがわかるかと思います。なお処理時間はPC性能に依存します。

さてこの遅延の間、明らかにクライアントのPCでの処理に時間がかかっており、なにをやらかしているのか非常に気になるのでさらに調べてみました。
まず、Process Explorer にて Firefox の当該プロセスを追いますと、やはりこの30秒間はCPU使用率が100%ではないですが30～40%程度とある程度負荷がかかっているのがわかりました。重い原因でよくあるのが、Flashなど応答のないスクリプト警告で「（応答なし）」となる事象なのですが、今回の遅延では「（応答なし）」にはなりませんでした。

[cc] https://safebrowsing.google.com/safebrowsing/gethash?client=navclient-auto-ffox&appver=37.0.2&pver=2.2
[/cc] そこで Live HTTP Headers にて Google へリクエストの再送信を試みましたが、特段 Google 側が重いという事象はありませんでした。レスポンスタイムもミリ秒単位でしたし、やはり Google へ問い合わせ後のブラウザの処理に時間がかかっているようです。

ここで重要なのがこの遅延の間、以降の通信（リクエスト）が「処理待ち」状態になることです。この事象が究明のカギになりそうな気がします。
これらからあくまで仮説ですが「セーフブラウジング機能により Google に問い合わせし、取得データをもとにブラウザで共通使用するリソースがなんらかの処理で排他ロックされ、以降の通信が処理待ちになる」というように思えてなりません。

[cc] %LOCALAPPDATA%\Mozilla\Firefox\Profiles\xxxxxxx.default\safebrowsing
[/cc] [cc] \safebrowsing
↓ (rename)
\safebrowsing-backup
↓ (rename)
\safebrowsing-to_delete
↓ (delete & new)
\safebrowsing
↓ (loop)
[/cc]

ではこのsafebrowingフォルダが、なぜリネーム＆削除＆再作成を繰り返すのか？という根本原因の特定にはまだ至っておりません。Firefoxのソースを舐めないと解らないかもしれません。

セーフブラウジングの「攻撃サイトのチェックを外す」ということはセキュリティレベルを下げることに繋がりますので、判断は分かれるかと思いますが、ただセーフブラウジングがどの程度セキュリティに貢献しているかは不明です（汗）すでにアンチウィルスソフトで対応できている気もしないでもないですが。。。

取り急ぎ、ここまでは判明しました。

---

2015/05/16 追記
Firefox 38.0.1 でも遅延継続中ですが、技術的なことはさておき、攻撃サイトのチェックをしたまま、アメッシュの表示を早くしたいのであれば、単純に英語サイトを表示すればよいかと思います。

• 東京アメッシュ英語サイト

降雨画像は同じですから、これでこれまでの遅延ストレスから一気に解消されます（笑）とりわけ気象などの公共情報は即表示されないとイライラ感が倍増しますからね！

なぜ日本語サイトだけGoogleへセーフブラウジングの問い合わせに行くのか、またsafebrowsingフォルダの作成削除を繰り返すのか、HTMLソースなどもdiffって追ってみましたが、いまだ原因究明には至っておりません。

---

[cc] 7000[1a73a900]: Checking fragment tokyo-ame.jwa.or.jp/ja/images/, hash FB928D3D9BB6B30740D5C8BD9D82B50B4CD53692752DB091B3C61C9F4AE3E031 (3D8D92FB)
0[4d1000]: nsHttpChannel::BeginConnect [this=1c423400] 7000[1a73a900]: Probe in goog-malware-shavar: 3D8D92FB, found 1
0[4d1000]: host=tokyo-ame.jwa.or.jp port=-1
7000[1a73a900]: Found a result in goog-malware-shavar: Not complete. (Age: 86400s)
[/cc] [cc height=”200″] http://tokyo-ame.jwa.or.jp/ja/images/button/headmenu/home_on.gif
http://tokyo-ame.jwa.or.jp/ja/images/button/headmenu/guidance.gif
http://tokyo-ame.jwa.or.jp/ja/images/button/headmenu/amesh.gif
http://tokyo-ame.jwa.or.jp/ja/images/button/headmenu/link.gif
http://tokyo-ame.jwa.or.jp/ja/images/button/headmenu/english.gif
http://tokyo-ame.jwa.or.jp/ja/images/button/headmenu/gesui.gif
http://tokyo-ame.jwa.or.jp/ja/images/button/area/tama_west.gif
http://tokyo-ame.jwa.or.jp/ja/images/button/area/tama_north.gif
http://tokyo-ame.jwa.or.jp/ja/images/button/area/tama_south.gif
http://tokyo-ame.jwa.or.jp/ja/images/button/area/west23.gif
http://tokyo-ame.jwa.or.jp/ja/images/button/area/east23.gif
http://tokyo-ame.jwa.or.jp/ja/images/map/explanation.gif
http://tokyo-ame.jwa.or.jp/ja/images/spacer.gif
http://tokyo-ame.jwa.or.jp/ja/images/time_panel/time_panel_lane.gif
http://tokyo-ame.jwa.or.jp/ja/images/button/operate/back.gif
http://tokyo-ame.jwa.or.jp/ja/images/button/operate/next.gif
http://tokyo-ame.jwa.or.jp/ja/images/button/operate/play.gif
http://tokyo-ame.jwa.or.jp/ja/images/button/operate/stop.gif
http://tokyo-ame.jwa.or.jp/ja/images/button/operate/stop2.gif
http://tokyo-ame.jwa.or.jp/ja/images/button/operate/history.gif
http://tokyo-ame.jwa.or.jp/ja/images/button/operate/whole.gif
http://tokyo-ame.jwa.or.jp/ja/images/button/operate/magnify.gif
http://tokyo-ame.jwa.or.jp/ja/images/sub_title/info_list.gif
http://tokyo-ame.jwa.or.jp/ja/images/sub_title/warn.gif
http://tokyo-ame.jwa.or.jp/ja/images/hanrei.gif
http://tokyo-ame.jwa.or.jp/ja/images/navi_map/navi_map.gif
http://tokyo-ame.jwa.or.jp/ja/images/button/operate/details_ja.gif
http://tokyo-ame.jwa.or.jp/ja/images/button/area/tama_west/okutama.gif
http://tokyo-ame.jwa.or.jp/ja/images/button/area/tama_west/hinohara.gif
http://tokyo-ame.jwa.or.jp/ja/images/button/area/tama_west/ome.gif
http://tokyo-ame.jwa.or.jp/ja/images/button/area/tama_west/hinode.gif
http://tokyo-ame.jwa.or.jp/ja/images/button/area/tama_north/musashimurayama.gif
http://tokyo-ame.jwa.or.jp/ja/images/button/area/tama_north/tachikawa.gif
http://tokyo-ame.jwa.or.jp/ja/images/button/area/tama_south/hachioji.gif
http://tokyo-ame.jwa.or.jp/ja/images/button/area/tama_south/hino.gif
http://tokyo-ame.jwa.or.jp/ja/images/button/area/west23/nerima.gif
http://tokyo-ame.jwa.or.jp/ja/images/button/area/west23/suginami.gif
http://tokyo-ame.jwa.or.jp/ja/images/button/area/west23/setagaya.gif
http://tokyo-ame.jwa.or.jp/ja/images/button/area/east23/adachi.gif
http://tokyo-ame.jwa.or.jp/ja/images/button/area/east23/koto.gif
http://tokyo-ame.jwa.or.jp/ja/images/now_loading.gif
http://tokyo-ame.jwa.or.jp/ja/images/anim.gif
http://tokyo-ame.jwa.or.jp/ja/images/error_display.gif
http://tokyo-ame.jwa.or.jp/ja/images/bg/header_bg.gif
http://tokyo-ame.jwa.or.jp/ja/images/amesh_logo.gif
http://tokyo-ame.jwa.or.jp/ja/images/bg/headmenu_bg.gif
http://tokyo-ame.jwa.or.jp/ja/images/bg/headinfo_bg.gif
http://tokyo-ame.jwa.or.jp/ja/images/time_panel/time_panel_knob_blink.gif
http://tokyo-ame.jwa.or.jp/ja/images/time_panel/time_panel_knob.gif
http://tokyo-ame.jwa.or.jp/ja/images/time_panel/time_panel_knob_click.gif
http://tokyo-ame.jwa.or.jp/ja/images/button/operate/back_off.gif
http://tokyo-ame.jwa.or.jp/ja/images/button/operate/back_on.gif
http://tokyo-ame.jwa.or.jp/ja/images/button/operate/next_off.gif
http://tokyo-ame.jwa.or.jp/ja/images/button/operate/next_on.gif
http://tokyo-ame.jwa.or.jp/ja/images/button/operate/play_off.gif
http://tokyo-ame.jwa.or.jp/ja/images/button/operate/play_on.gif
http://tokyo-ame.jwa.or.jp/ja/images/button/operate/stop_off.gif
http://tokyo-ame.jwa.or.jp/ja/images/button/operate/stop_on.gif
http://tokyo-ame.jwa.or.jp/ja/images/button/operate/stop2_off.gif
http://tokyo-ame.jwa.or.jp/ja/images/button/operate/stop2_on.gif
http://tokyo-ame.jwa.or.jp/ja/images/button/operate/history_off.gif
http://tokyo-ame.jwa.or.jp/ja/images/button/operate/history_on.gif
http://tokyo-ame.jwa.or.jp/ja/images/button/operate/whole_off.gif
http://tokyo-ame.jwa.or.jp/ja/images/button/operate/whole_on.gif
http://tokyo-ame.jwa.or.jp/ja/images/button/operate/magnify_off.gif
http://tokyo-ame.jwa.or.jp/ja/images/button/operate/magnify_on.gif
http://tokyo-ame.jwa.or.jp/ja/images/button/operate/details.gif
[/cc]

取り急ぎ addPrefix() の対処療法を行うようですが、根本的にこの safebrowsing 処理のロジックはどうなんでしょう？「found 1」になった場合、そのURLのユニーク一覧を保持しておきレスポンス最後に safebrowsing.google.com へ一括問い合わせしデータベース更新は一度だけとかはできないんでしょうかね。または67画像で41回問い合わせですからこのバッファをもう少し多めに取ったらよいと思うのですが。問い合わせ処理とデータベース更新処理は別スレッドのようなので難しいのかな？
もしくは問い合わせとデータベース更新を同期処理にするとか。またはそもそも再構築ではなくマージ(追記)とかできないんでしょうかね。このままではまた同じような Hash Prefix が一致するサイトが出てきそうな感じがしますね。いずれにしても、safebrowsing 処理のロジックは改善の余地がありますね。

この修正がどのバージョンで反映されるかは不明ですが、もう少し時間がかかりそうですね。

---

ハリルホジッチ新監督の初陣はスタメンを見てビックリしましたが、終わってみれば公約通り、勝ちにこだわった采配で勝利。

世界標準の最低ラインで、次々と日本代表の問題点が浮き彫りになっています。

• 寄せが甘い
• 球際の厳しさ（が足りない）
• 簡単にマークを外す

どれも基本的なことばかりなのですが、あと一歩、半歩、30cmが世界基準ではまだまだ足りないということですね。実際こういう点を指摘した指導者は今までいたのでしょうか？非常に新鮮に映るのは私だけでしょうか？昔は出来ていたことのような気もするのですが（汗）
野球で言えば、捕球時の体の向きとか、グラブの向きとか、カバーリングとか、リードとか本当に基本中の基本なのかなと。野球なら尻バット込みで(笑)徹底的に高校までに叩きこまれる基本かなと（笑）今は尻バットNG！？（汗）
そういった基本という意味では、先日の宇佐美のシュートがポストに嫌われたシーン、しっかり詰めておくべきですね。

ほんの少しのところの差なのでしょうが、そこが世界との差、最終的には大きな差になってくる。ブラジルW杯、アジアカップ、開幕前までは技術＆結果とも全く見劣りしないレベルだったのですが、いざ本番ではそういったところが、致命傷になるということでしょうね。基本を当たり前に体が無意識に反応するレベル、20年前より技術レベルは確実上がったように思うのですが、やはりメンタルも含めこういった基本的なところなのでしょうね。なにかスッキリした感じです。どんなに上手かろうが、実績あろうが、この泥臭い基本が劣って（怠けて）いたら容赦なく切る、これが一番欠けていることなのでしょうね。そして平等と競争。全くその通りで、チャンスは平等に与え競争を促すハリルホジッチ監督、言うことないですね。

強烈なリーダーシップとトップダウンですが、コミュニケーションはアギーレ監督以上のような感じですしね。非常に大切なことだと思います。信頼関係を築く上でも非常に重要なことですね。

ノムさんの口癖、「配球には理由がある（配球の意図を答えられる）」と言っておられますが、ハリルホジッチ監督はデータ中心主義から導き出されるすべての施策(戦術)に明確な意図（理由）があるように思います。先日のトラッキングの記事でも書いていますが、私もデータ分析は大好物です。ただデータから導き出す戦術は指揮官それぞれですよね。
「あのパスなぜそこに出したんだ？」と問われたら出し手は明確に答えられるようにしてほしい。パス出しの意図にこだわってほしい。逆にそのパスいる？無駄じゃないって言われないように。パスひとつ取っても意味のあるパスであるように、ということですね。
ハリルホジッチ監督の口癖は「準備」。明確な分析があるからこそ的確な準備ができるということですね。

個人的には「カウンター」を意図的に成功させて欲しい。久しく日本代表のカウンターなんて観てないような気がします。
これは素人のたわ言ですが、欧州リーグを見ていますとカウンターって、センターライン前後で出し手が非常に重要だと思うんですよね。受け手はオフサイドなど考えずひたすらスペースに全力で走る、そこへオフサイドラインを見ながら出し手が”スペース”にパスする。もしオフサイドになったらそれは受け手が悪いのではなく、出し手が悪いのではないかと。下手に受け手の足元にパスするからカウンターにならない。玄人からしたらそんなの当たり前なのかもしれませんが、実際それが出来ていないんですよね！

この際だから、ハリルホジッチ監督に「サッカー協会」も大ナタ振るって改革して欲しいものです。無駄がいっぱいありそうですしね！

先日の試合、サポーターvsファン論争が勃発していましたが、黄色いファンであろうが、お金を払って現地で応援しているのですから、ＴＶ画面キャプって文句言ってるやつよりかはマシかと。そういうファンも含めて大きくなることが肝要なのかなと。
そういえば、南アのデンマーク戦、ラステンバーグのスタジアム入口に加藤ローサがいて思わず１枚パチリしようかと思ったのですが、そこはアイドル撮りにこんなところまで来たんじゃねーとか勝手に思って硬派サポーターを装いましたが、今思えばあの時１枚撮っておけばよかった！（爆）顔が本当にちっちゃかった！（汗）

球春到来。昨年も開幕時に記事を書いてますが、今年もオープン戦から見えた印象で今年を占ってみたいと思います。選手からすれば大きなお世話ですが（汗）

• 日本ハム・大谷
  昨年は記事の印象通りの活躍でしたね。先日、Get Sportsで、田中マー君も同じことを言ってましたね。しかし今年は昨年春ほどの劇的な成長はいまのところ見られませんね。オープン戦を見ますと昨年の飛躍幅が大きかったせいか、今年はそれほどと言うか、むしろ昨年より悪くなっているように見えます。直近の試合では投球時の力のベクトルが３塁ベンチ方向に逃げている感じがします。フォームも一回り小さくなってしまった感じ。おそらくステップする際、踏みだし足の重心バランスばかりに意識が行き過ぎているのではないかと。まあ修正能力のある投手なのであまり心配はしていませんが。
  いくら160km出しても、試合に勝てなければなんの意味もないですし、肩・肘を酷使するだけです。やはりスピードより球のキレをもっと意識すべきですね。日本なら150km出ればもう十分でしょう！マスコミも、もう球速ばかりを追いかけないでほしい。大谷の将来のためにも球速至上主義はもう止めましょう！

• 阪神・藤波
  昨年は春の記事ではあまりよくない印象でしたが、今年は非常によく映ります。ストレートの質が明らかに良くなっていると思います。シュート回転していたボールが今年は綺麗なフォーシームになっています。昨年はステップの修正など戸惑いが見られましたが今年はフォームに自信が見て取れます。今年は現時点で大谷よりストレートの質は上ですね。体つきも一回りとまではいかないまでも半回りは大きくなった印象です。今年は期待してよいんじゃないでしょうか！

• ソフトバンク・松坂
  コアな野球ファンなら誰が見ても悪く映りますよね。よい頃の松坂を知っているだけに余計にです。比較しては行けませんが、左足を踏み出す際体の開きを意識し過ぎてしまっているのか、以下の画像のように上半身が猫背で丸まっていて、全体像で「く」の字に見えるところですね。西武のころはもう少しピンと背筋が立っていたと思うのですが、肘に手術の影響なのですかね。良くなるまでにはまだ時間がかかりそうな気がします。
  
  松坂はとにかく「いかにして四球を出さないようにするか」をまず考えるべきです。これは日本でもMLBへ行っても全く変わっていない悪クセなんですよね。

• 巨人・菅野
  昨年シーズン途中から、腕の振りが横振りになっていてあまりよくないなと思っていたら、案の定肘を痛めてしまいました。今年は次第に良くなってきてはいますが、良い時の状態まではまだまだ程遠いといった感じですね。やはり肘がまだ悪いのか、昨年の故障のトラウマの影響なのかといった印象です。

• 巨人・大田、沢村
  この二人の共通点は頭ですね。大田に関しては原監督や井端が指摘していますが、頭が空っぽなんですよね。大田自身が「考え過ぎ」と言ってましたが、むしろなにも考えていないのではないかと思わざるを得ないですね。配球を読んでからの「考え過ぎない」なら解るのですが、配球すら読んでない気がしてならない。配球を読むとはまず傾向（データ、確率）を頭に入れることです。沢村も一緒。脳みそまで筋トレしているんじゃないのかと思うほどです（笑）。
  二人ともノムさんに弟子入りしたほうがよいのでは！？そうノムさん、最近見ないですね。S☆1などマスコミへの露出もなくなり体調が心配です。

• 横浜・筒香
  今年はよく映りますね！ボールを引きつけるバッティング理論、まさしくその通りで理にかなっていると思います。私のバッティング持論で一番大切なのことはピッチャーから投げられたボールに対し、スイングすると決めた決断点をより打者の近くにするということ。ただ単にインパクトの打点を体の近くにするだけでは全く効果がありませんね。動くボールをどれだけ見極められるか長く見れるかが重要なのですから。選球眼もよくなるはずです。今年は右の中田、左の筒香ぐらいになる予感がします。

• 広島・黒田
  今年は「男気・サンデー黒田」フィーバーとなりそうですね。マツダスタジアムもMLBに雰囲気が近くてよい球場ですしね。黒田効果なのか、いままで常識とされてきたボール球をいかに使うかという日本式の配球パターンもストライクで勝負していくMLB流に変わっていくかもしれませんね。今後のトレンドも動くボールになっていくのかもしれません。そうなると、打者も引きつけるバッティング理論がより重要になってくると思います。

• [番外編] 県岐阜商・高橋
  古田いわく大谷がNPB史上最高逸材と言ってましたが、昨日の選抜高校野球の県岐阜商・高橋も衝撃的でした。ポテンシャルはそのくらいありそうな印象です。まだまだ荒削りですが、故障などなければ間違いなく第二の大谷・藤波になりそうな逸材です。

最後に、NPBも番宣ばかりの始球式ではなく、サッカーの入場シーンをを見習い、すべての試合で少年少女の始球式かそれに準ずることができなのかって思いますね。

2015/04/30 追記
今日もそうですが、巨人@東京ドームの始球式は少年野球チームを招待して各ポジション選手とともに守ってましたね。そういえば昨年生観戦した時もやってたことを今思い出しました（汗）良いことですね！

先日、Firefox を 35 ⇒ 36 にアップデートしたのですが、それ以降 Firefox Add-on の iMacros でブラウザのスクショを自動保存する SAVEAS コマンドでエラーとなる事象が発生しました。

そもそも iMacros とはなんぞやってことですが、簡単に言えば、EXCEL のマクロのようなもので、ブラウザの操作をマクロ（独自スクリプト）で自動実行してくれるブラウザ拡張機能（アドオン）です。もちろん手動でスクリプトを書いてもよいのですが、iMacros の良いところは、EXCEL のマクロのような「記録」「再生」機能があることです。iMacros を使えば、コマンドを書かなくとも EXCEL のマクロ記録のようにブラウザ操作の「記録」と「再生」を簡単に行えるようになります。

ブラウザはおそらく現在もっともよく使われるアプリケーションですが、ブラウザの操作のかなりの部分は単純な繰り返し作業ではないでしょうか。みなさんも日々同じサイトを開いたり、検索エンジンで毎日同じ語句をチェックしたり、あるいはウェブサイトテストで単純作業を繰り返していませんか？ iMacros を使えば、一度記録するだけで、同じ操作をいつでも iMacros に実行させることが可能になります。

• 前置きはさておき、エラーは以下のような内容でした。
• 
• [cc] NS_ERROR_XPC_NOT_ENOUGH_ARGS: Not enough arguments
  [nsIWebBrowserPersist.saveURI], line 7 (Error code: -1001)
  [/cc]

エラーメッセージは見ての通り、 nsIWebBrowserPersist.saveURI() メソッドで引数が足りない（満たしていない）というエラーなのですが、iMacros 自体はアップデートなどの変更はしていませんので、単純に Firefox 36 へのアップデートが問題かと。ちなみにFirefox 35 に戻すと正常に動作しました。iMacros のバーションは 8.8.9 です。
「Not enough arguments」ですから素直に Firefox 35 ⇒ 36 で saveURI() の引数が増えたと考えるのが妥当ですが、アップデートごときで果たしてメソッドの引数の数を増やすほどの仕様変更（暴挙）に出るかってほど、あまりにも乱暴すぎるので普通は下位互換を考慮に入れるずなのですがね。

早速 Google 先生のお世話になりますと、iMacros のコミュニティフォーラムの SAVE SCREENSHOT ERROR w/Firefox 36.0 というページがビンゴ！
このページのスレで、iMacros Wiki の Version Historyから iMacros を V8.9.1 にアップデートすれば直るらしい。

• 2015-03-04 V8.9.1 => Download now (To install: Download, and then drag-and-drop the .xpi file onto an open instance of Firefox.).
  • Added Firefox 36 compatibility
    • Fixes “NS_ERROR_XPC_NOT_ENOUGH_ARGS: Not enough arguments [nsIWebBrowserPersist.saveURI]”
    • Fixes problem with JS code executed twice instead of once

しかし、Firefox 公式の iMacros Add-onサイト はいまだに V8.8.9 のまま。公式サイトであれば信頼できるのですが、アリアリの（なんでもできる） Add-on(xpi)　ですから、セキュリティ上少々不安。
V8.9.1 は imacros.net の Wiki からのダウンロードですので信頼性という点ではあまり気にする必要はないとは思いますが、ここは Firefox 公式のお墨付き（Firefox 公式サイトからのダウンロード）が欲しいところです。ただ Firefox 公式サイトからのダウンロード＆インストールでも「作者情報未検証」という警告は出ますので同じといえば同じなのですが（汗）検閲済ってことで。

とまあ技術屋性分で、Firefox 36 で saveURI() メソッドがどう変更になったのか一から調査してみることにしました（汗）
すると、 MDN(Mozilla Developer Network) にあっさり記載されていました。やはり aReferrerPolicy という第4引数が１つ増え、引数の数が7から8個に増えていました。

• ・saveURI()

  As of Firefox 26, this method should no longer be used from add-on code. Please use Downloads.createDownload() instead.

  As of Firefox 36, a new parameter aReferrerPolicy was added as the fourth argument, changing the number of parameters from 7 to 8 and shifting the order of the parameters in a backwards incompatible way.

  void saveURI(
    in nsIURI aURI,
    in nsISupports aCacheKey,
    in nsIURI aReferrer,
    in long aReferrerPolicy,
    in nsIInputStream aPostData,
    in string aExtraHeaders,
    in nsISupports aFile,
    in nsILoadContext aPrivacyContext
  );
  

要するに、 saveURI() メソッドはすでに Firefox 26 で deprecated になったので、今後は Downloads.createDownload() を使ってね！ってことですね。でもまあ百歩譲っても下位互換性は維持しておくべきのような気がしますが、すでに Firefox バーションも 26 ⇒ 36 で 10 バージョンも猶予したので Add-on 開発者もそろそろイイよね！って感じなんでしょうね。
ロジックは Javascript ですから、メソッドのオーバーロードが効きそうなので、追加した第4引数の aReferrerPolicy は一番最後（第8引数）にしておけばよかったのでしょうが、第3引数が aReferrer ですから、まあコードの美しさというか規約を優先したのでしょうね。no longer ですしね。

というオチでしたので、Firefox 公式が iMacros V8.9.1 に更新されるまで、V8.8.9 のソースコードを修正して凌ぐことにしました。

[cc]%APPDATA%\Mozilla\Firefox\Profiles\xxxxxxx.default\[/cc] xpi ファイルはただの zip ファイルですのでリネームするなりし、その中の imacros.jar を探します。 imacros.jar 内の content フォルダ配下の MacroPlayer.js こそがエラー元の箇所になります。

diff -U 1 -u MacroPlayer.js.org MacroPlayer.js
--- MacroPlayer.js.org	Fri Jan 30 09:59:38 2015
+++ MacroPlayer.js	Fri Mar 20 21:19:24 2015
@@ -1372,3 +1372,3 @@
         if (!wait) {
-            wbp.saveURI(uri, null, null, null, "", file, pcontext || null);
+            wbp.saveURI(uri, null, null, null, null, "", file, pcontext || null);
             return;
@@ -1415,3 +1415,3 @@
 
-        wbp.saveURI(uri, null, null, null, "", file, pcontext || null);
+        wbp.saveURI(uri, null, null, null, null, "", file, pcontext || null);
     };
@@ -1560,3 +1560,3 @@
         
-        wbp.saveURI(source, null, null, null, null, file, pcontext || null);
+        wbp.saveURI(source, null, null, null, null, null, file, pcontext || null);
     };
@@ -1988,3 +1988,3 @@
         
-        wbp.saveURI(source, null, null, null, null, file, pcontext || null);
+        wbp.saveURI(source, null, null, null, null, null, file, pcontext || null);
     };

以上で iMacros の SAVEAS コマンドが動作するようになりました。

2015/03/31 追記
本日付でFirefox 公式の iMacros Add-onサイト はV8.9.2に更新されました。このアップデートにより不具合も解消されます。

Jリーグが開幕しましたね。ふと試合結果を見るとトラッキングシステムのデータが掲載されているではありませんか。トラッキングシステムは今年から導入とのことですが、むしろ遅いぐらいですよね。このトラッキングシステムはすでにイングランド、ドイツ、スペインなど欧州の主要リーグで採用されています。昨年のブラジルワールドカップでも現地から随時チェックできました。

日頃、メンタル論ばかりボヤいてる筆者ですが、実はデータや科学的観点からスポーツを眺めるのは大好きです。

• 選手走行距離
• 選手加速度
• チーム総走行距離
• 走行スピード
• 移動エリア
• ボールの動き
• 審判の動き
• 選手間の距離
• 平均ポジション
• 状況別走行距離
• 時間別走行距離
• 状況別ポジショニング
• ピッチ全体の俯瞰映像

• 選手走行距離
• 選手スプリント回数(24km以上)
• 選手出場時間
• 走行スピード(LIVEのみ)
• ヒートマップ(LIVEのみ)

• パススピード
• パス距離
• パス精度

欧州と比較できるのならおそらくパススピードはかなりの違いがあるのではないかと思いますね。蹴る、止めるといった基本レベルでまだまだというところをデータで確認してみたい欲求が（大汗）野球では投球の変化量や打球角度の自動取得が可能なぐらいですからこの程度は楽勝のような気がします。中長距離のパス精度もかなりの違いがありそうですね。また開幕から物議をかもしている審判の動きなども見てみたいものです。

このトラッキングデータってXML,JSONやCSVで提供してくれないんですかね。最悪PDFでも構わないのですが。
実際、LIVEトラッキング対象だった名古屋v松本山雅で見るとなんとデータ表がPNG画像でした。これは二次利用させないという意図がアリアリ！？
手動入力で頑張ればできないこともないですが、時間とマンパワーが必要で非効率ですね。必要なら有償でってことですかね！FIFAですらPDFで全公開しているのですから、その程度は無償公開してほしいものです。

実際、公開されている範囲でデータベース化までをマイルストーンとして組むとなると、OCR噛ませてって手もありだとは思いますがかなりの手間ですね。このくらいは公開しているのですから画像ではなく、せめてHTMLやPDFで欲しいものですが、ランキングのほうはHTML化しているようですので、二次利用云々というより、むしろグラフ化などのコスト的要因なんでしょうかね。確かにデータバーなどいかにもEXCEL使ってますってデザインでひょっとしてこの Tracking Data Report も手動で作成なのか！？　なことはないと思いますが、もし手動での作成だとしたらご苦労様です、っていうよりアナログすぎて萎えてしまいますね。