« 2010年9月 | トップページ | 2010年11月 »

2010/10/23

IE9 beta版で不満なこと



バグではなく仕様変更なのでしょうが、使いづらい点がいくつかあります。ここで述べても変わるとは思えませんが・・・。

1. 戻るボタンで2ページ先や3ページ先に戻る場合、戻るボタンの横にある矢印がなくなり、ボタン上で右クリックして履歴を表示させないといけないこと。

関連ページ:http://social.answers.microsoft.com/Forums/ja-JP/ieja/thread/e4a24efc-81da-4597-aab7-8f860bbca656

2. お気に入りの追加方法がいまだによく分からないこと。
右クリックで保存する方法や、Altキーでメニューを出してからやるという方式なのでしょうか?

これだと右クリック禁止しているサイトでは、お気に入りに入れるのも一苦労ですね。

3. ページタイトルの確認が大変。ブラウザのトップではなく、各タブに表示されるため、最初の10文字ぐらいしか見えません、私の環境では。右クリックでプロパティを見るか、ソースを表示させて、タイトルを確認しなければならないのでしょうか? 最大化ボタンの左横にだだぴろいスペースがあるのに、そこになぜ表示させないのか不思議です。 4. 歓迎している人もいるようですが、情報バーの出し方がかえって私には使いづらいです。情報バーを消さなくても次のナビゲーションが可能になりましたが、それでも消さないといつまでも表示されています。そしてブラウザの下のほうにあるのも、私にはいやです。webmasterやプログラマーの責任も大きいでしょうが、たとえばポップアップがブロックされて、本来のコンテンツが表示されなくても、ユーザーにはなぜそのような状態になっているのかを悟ることが難しいです。リンクをクリックしたのに何も起きないという問い合わせをしてくる人が増えそうです。情報バーがIE8以前のように表示されていれば、ユーザーに少なくとも何かおかしなことが起こっているためにそういう状態なんだということは理解してもらえます。

5.おそらくバグだと思うのですが、クラッシュしてからの復帰がおかしいです。Windows 7の64bit版Ultimateで32bit版のIEを普段使っていますが、クラッシュすると、32bit版のIEをいくら起動させようとしても、最初のページを表示させる前に再びクラッシュして起動しません。ただ、ここで(どう思いついたのかは忘れましたが)64bit版のIEを起動させると、「your last browsing session closed unexpectedly.」と表示されて、起動できます。いったん64bit版IEで厄除けすると(クラッシュの原因?を除去すると)、今度は64bit版IEを終了させて32bit版IEを起動させると、32bit版IEも起動できるようになります。これがかなりうざいです。そもそも、IE8やIE7でこれほどクラッシュすることは、同じbeta版で考えてもなかったように思います。

| | コメント (0) | トラックバック (0)

IE9 beta版の右クリックが時々変なこと

再現条件はよく分からないのですが、IE9beta版では、たとえばテキストを選択した状態でコピーしたいと考えているのに、コンテクストメニューで「copy」の項目がない場合があります。英語版を使っていますが、即座に英語のメニューが読めないわけではないです。いくら探してもないのであり、またメニューの数も多いです。本当はinput type=textやtextareaで右クリックした場合はもっと少ないメニューのパターンで表示されるはずなのにです。

何回かやり直すとうまくいくのですが、うまくいかない場合、アクセラレータが選択しているテキストの左上に表示されている場合が多いような気がしますが、いまいち再現条件が分かりません。私のマウスの動かし方が悪いのかという思いもゼロではないのですが、IE8まではこのようなことがあったことがなく、少々困っています。

| | コメント (0) | トラックバック (0)

IE9betaと.htaccess(Basic認証)



IE9(betab版)のバグですぐに直してほしいと思うバグのうちのひとつがこれです。.htaccessでBasic認証をしている場合に、パスワードをコピー&ペーストで貼り付けようと思う機会は意外とあると思うのですが、ペーストしてログインしようとすると認証に失敗します。手動で入力した場合は成功します。

テストページを作成しました。
http://www.broadband-xp.com/test/htaccess/
ID: ie9
パスワード: 1234
で、手動で「1234」を入力すればログインできますが、1234をコピー&ペーストで貼り付けると、ログインできません(テストのときは一度ブラウザを終了させないと、手動でログインできたときの情報が残っていて、検証がうまくいきません。)。パケットを調べてみると、どうもペーストしたとき、パスワードは空の状態で送信されているために認証に引っかかっていることが分かりました。

WordPress・MTOS簡単インストール機能対応!レンタルサーバー『ヘテムル

| | コメント (0) | トラックバック (0)

IE9バグ: Flash(swfファイル)に直接アクセスしてリロードすると文字化けデータ出現



IE9では私だけでも非常にたくさんのバグを見つけました。正式リリースはまだまだ控えたほうが賢明だと思われます。さて、マイクロソフト社に数多くのバグを報告していますが、そのうちの1件だけ、確認が取れたと報告があったのが、「FlashファイルをHTMLファイルに埋め込む形だけでなく、swfファイルに直接アクセスし、それをリロードした場合、バイナリーデータが無理やりテキスト化された状態(いわゆる文字化け状態)」になるというバグです。

たとえば、http://www.adobe.com/jp/support/flashplayer/ts/documents/swfs/flashplayerversion.swf にアクセスして、リロード(再読み込み)します。いわゆる文字化け状態になります。バイナリーデータがテキスト化された状態で表示されます。MIMEが完全に無視されます。

| | コメント (0) | トラックバック (0)

2010/10/07

IE9トラブル: エラー5 - アクセスが拒否されました

私が開発しているアプリケーションの配布で、Inno Setupを使ってインストーラを使っているのですが、IE9(on Windows 7 ultimate 64bit)でダウンロードして実行しようとすると、「ディレクトリー:「C:\users\ユーザー名\AppData\Local\Temp\****.tmpを作成中にエラーが発生しました。エラー5 - アクセスが拒否されました。」となります。同じファイルをFirefoxでダウンロードして実行しても問題なし。

IE9ではCtrl+Jのショートカットでダウンロードマネージャーが起動できますが、そこからダウンロードフォルダーは変えてあります。(G:\ie9というフォルダーに。)IEからダウンロードして直接実行しているから駄目なのかと、この「G:\ie9」にあるファイルをエクスプローラで表示させてから実行しても、やはり駄目です。ところがこのファイルを別のフォルダーにコピーしてから実行するとちゃんと実行できます。

逆にインターネットからダウンロードせずに、ローカルで作成したインストーラをG:\ie9フォルダーにコピーして、エクスプローラから実行すると、今までなんともなかったファイルがいきなり、「アクセスが拒否されました」になります。

ただし、g:\ie9フォルダーにあるファイルを右クリックから管理者として実行するとちゃんとインストールできます。どうも、IE9ではセキュリティのために、低い権限でダウンロードフォルダーにあるファイルは実行されるようにプログラムされているのか(仕様)、バグっているのか、このような挙動になるようです。なお、いったんsaveしてからrunするとこのエラーになりますが、最初から3つあるボタン:Run/Save/Cancelのうち、runを押すとインストールできます。(でも、遠い記憶ですが、セキュリティの関係でRunよりも常にいったんSaveしてからのほうが安全と読んだ気がするので、個人的には直接「実行」や「Run」のボタンを押してインストールしたことはこれまでなかったです。)

なお、まったくの非推奨ですが、IE9のアイコン上で右クリックして、「管理者として実行」を行ってからファイルをダウンロードするようにすると、SaveしてからRunしてもインストールできました。かといって、管理者として実行しつついろんなサイトを訪問するのは危険極まりないので、皆さんやめましょう。原因の切り分けとしては重要な情報だと思い、書いています。

それにしては、あまり大きな仕様変更という形で報道されていないというか、あまり騒ぎになっていないようなのですが・・・。

ただ、他人の作ったプログラムはメジャーなものがほとんどで、きちんと署名が入っているからなのか、他のプログラムのインストール時にこの手のエラーになっていないので、私のInno Setupのファイルの書き方に問題がある可能性があります(ユーザーアカウント制御のことをあまり考慮できていないなど。)。IE9が正式リリースされる前に、早く解決しないといけないです。

| | コメント (0) | トラックバック (0)

2010/10/05

子供の算数の問題とJavaScript



昨日、子供(小学5年生)に算数の問題を聞かれた。次のような問題であった。

ある数の約数の和からその数自身を引いた数を計算します。たとえば、4であれば約数が1,2,4であり、4は含めないので、1+2=3のように計算します。

問1)この時、10までの数で、この計算結果がその数自身になるものは何ですか?
問2)100までの数で、この計算結果がその数自身になるものが1つだけあります。その数は何ですか?

-------
1番の問題は、計算を数回もすれば、終わりますから簡単です。子供も解けていました。(6ですね。1+2+3=6)ただ、2番の問題は力ずくで解けば、いつかは解けると分かっていても、何かいい方法があるかと、子供は私に聞いてきたわけです。

ただ、私もしばらく考えて、いい方法が思いつきませんでした。仕方がないので、11から順番に計算することにして、素数はどう考えてもスキップできるので、それは除外するにしても、延々計算しました。そして、あきらめかけていたところ、28で1+2+4+7+14=28となり、正解にたどり着けました。でも、問題に「1つだけある」とわざわざ書いてくれていたので良かったのですが、そうでない場合は困ったと思います。
気になったので、JavaScriptで解くことにしました。ある数の約数を調べるためには、割り切れるかを調べればいいのですが、全部調べるのはもちろんばかばかしいので、その数の平方根までを調べればいいわけです。たとえば、180の約数で2が見つかったら90(=180÷2)も約数。ただ、ひとつ注意しないといけないのが49のような場合7×7ですが、7を2回エントリーさせると間違いです。

上のJavaScriptでは、他のプログラムにも応用しやすいように、遭えてその数自身も総和の計算に入れておいて、後から算数の問題に合わせる形で引くようにしてあります。このプログラムを使えば、10000までの数でこのような計算結果になるのは、「6」「28」「496」「8128」の4つだとすぐに分かります。

どのような法則があるのかと調べてみると、496を素因数分解すると(2の4乗)×31となります。31は、(2の5乗-1)です。8128を素因数分解すると、(2の6乗)×127ですが、127は(2の7乗-1)です。28は(2の2乗)×7で、7は(2の3乗-1)です。6=2×3で、3は(2の2乗-1)です。

では、なぜ、(2の3乗)×(2の4乗-1)、すなわち8×15=120はエントリーされないかといえば、15は素数でないためのようです。8128の次に、この問題に当てはまる数を予測してみると、(2の8乗-1)は255で素数でないからダメぽいです。(2の9乗-1)は511であり、この数は7で割りきれてしまいます。(2の10乗-1)は1023ですが、これも11で割りきれてしまいます。結局(2の13乗-1)=8191が素数ですから、(2の12乗)×8191=33550336となります。

ただ、JavaScriptでは、200万ぐらいまでの数を連続的にJavaScriptで調べることはFirefoxでかろうじてできましたが(IE9はもっと低い数で駄目。)、それ以上はハングしたり駄目でした。ですから、33440336はこの条件に当てはまることは分かりますが、そこまでに登場する数でそのような数が他にないという証明方法は分かりませんでした。

結局、これは、昔、高校数学で習った、
1+2+(2の2乗)+(2の3乗)+・・・・・(2のn乗)=2の(n+1)乗-1
の法則と関連している気もしますが、上であげた推察以外のパターンで、この問題に適合する数が存在しないのかどうかは分かりませんでした。文系に進み、まともに大学の授業も聞いていなかった私にはこれが限界です。

最初の子供の算数の問題に戻りますと、28という答えを導き出すまでに、素数を除いて計算しまくる以外に、もっとエレガントな方法があったのでしょうか? もし分かる人がいれば教えてください。ただし、小学校5年生の問題であることを忘れずに。(そもそも素数かどうかの判断も、暗記しているか約数がないかを計算しているはずので、飛ばしていることにならないかも。)

| | コメント (2) | トラックバック (0)

2010/10/03

IE9でlightboxが動作しなくなった場合

まったく同じスクリプトでも、DocTypeを削除したら動きました。Lightbox2のサイトのソースを保存して確認しました。

DOCTYPEが指定されている場合、this.imageArray[imageNum][0] != imageLink.hrefの部分が気に入らないらしいのですが、細かい原因は探していませんが、このDOCTYPE宣言でJavaScriptの挙動が変わるのは、珍しいような気がします。いつもいつもDOCTYPEを変えられるわけではないでしょうが、時間がないときは、この応急措置でうまくいくかもしれません。

また、typeof window.external.addFavoriteの件もそうでした。こちらは、逆にDOCTYPE宣言がある場合は動きました。さらに、別件で、これは私のJavaScriptの書き方の問題もあるのですが、IE8でも問題なく動いてくれていたのに、動かなくなったスクリプトをご紹介します。

DOCTYPEを宣言している場合、スクロールとともに、オブジェクトもスクロールさせるような時に、
は動作しません。

なら動作します。以前、古いブラウザでもこのような挙動(厳密な解釈)があったと思いますが、最近はこれで動いていたので、まあいいかとなっていました。これはIE9のバグではなくて、私のJavaScriptの問題でしたね。

また、読売新聞など他社のサイトを見ていると、debuggerを有効にしている場合、かなり鬱陶しくエラーが出ます。原因を調べてみると、ある広告会社のJavaScriptにこのようなJavaScriptがありました。(抜粋して、書き換えてあります。)

このJavaScriptの場合、 「Invalid this pointer used as target for method call」となりますが、これはDOCTYPEが<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">の場合。DOCTYPEなし場合は「abc」が出力されます。

なら動きます。また、

も、問題なく動きます。よくばりすぎると駄目みたいです。

| | コメント (0) | トラックバック (0)

2010/10/02

IE9バグ?(2)-- 特定条件で、typeof window.external.AddFavoriteでエラー

お気に入りに登録させるためのボタンを表示する場合に、慎重を期して、window.external.addFavroiteがサポートされているかどうかをチェックすることがあります。

if(window.external && typeof(window.external.AddFavorite)!="undefined"){
//ボタンをdocument.write
}
ところが、IE9(beta版)では、このtypeofのところで、「Object does not support this property or method」になります(条件あり。後述します。)。try catchで囲めば大丈夫なのですが、try catchで囲むと、なぜかe.messageはに何も出力されません。ボタンがdocument.writeされます。try catchするだけでエラーが表に出ないだけでなく、ちゃんとボタンが出力されます。これは完全にバグでしょうね。

さらに、詳細設定の「Disable script debugging( Internet Explorer)」のチェックをはずすと(デフォルトではチェックが入っています。)、このエラーは発生せず、ボタンはdocument.writeされます。どうもdebuggerとの相性のようです。debuggerが動作している場合、window.externalが別のオブジェクトをポイントしているのかもしれません。

2010年10月2日午後13時55分ごろ追記
DocTypeにも影響されるようで、DocType指定なしや<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">ではエラーになるのですが、「<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">」では、エラーになりませんでした。

▼▽サービスの詳しい内容のつまった資料はこちらから▽▼

| | コメント (0) | トラックバック (0)

IE9はキャッシュ機能を改善? 改悪?



ウイルスバスター2011
無料体験すると、抽選で1名様に
20万円分のVISAギフトカードが当たる!


スクリプトのエラーを通知するようにIE9(betab版)を設定して、自分のサイトを確認したところ、ある外部ファイル(JSファイル)で予想外のところでエラーが出る。とりあえず、try~catch~で逃げることに。これでエラーがでないはずだが、同じところでエラーになる。しかも更新したはずなのに、更新する前のスクリプトを開発者ツールは表示します。

どうもキャッシュから読み込まれているようだ。ところがリロードしてもだめ、キャッシュをクリアしても駄目、キャッシュをクリアしてから、IEを起動させても駄目(だったと思います。)でした。仕方がないので、Windowsを再起動してから表示させてみる。今度はうまくいきました。

調べてみると、
Caching Improvements in Internet Explorer 9
http://blogs.msdn.com/b/ie/archive/2010/07/14/caching-improvements-in-internet-explorer-9.aspx

に書かれているように、IE9ではキャッシュ機能がimproveしたそうだ。だけど、開発者側からするといつまでもキャッシュから読み込まれて困る場合もあるわけで改悪とも言えなくもないように思います。

(IE9のキャッシュ機能の「改善」記事を日本語で読まれたい方は、こちらの記事が分かりやすいと重います。)
_
通常のHTMLファイルの場合はリロードで問題ないのだけれど、そのHTMLファイルからリンクされているところのJSファイルの更新がどうも期待通りに動かない。後から思い出したが、Ctrl+リロードボタンならうまくいきそうだが、ではなぜキャッシュをクリアしても駄目だったのか不明。むむむ。

jsファイルのパスの後ろに「?111」などを付けてあげると、デバッガーは起動しなくなりましたが、いつもいつもこうすることはできません。

| | コメント (0) | トラックバック (0)

« 2010年9月 | トップページ | 2010年11月 »