Dead Zone

Stand alone.

E10s

2015-05-21 10:29:30 | 雑記

Firefox Nightlyにて。mozillaZineのforumに「このwebページでcrashするぞー」というのがあって。確かにcrashするんですが。タブが。
>Bad news first: This tab has crashed
>Now for the good news: You can just close this tab, restore it or restore all your crashed tabs.
別のタブも同時にcrashしまして。デフォルトでは dom.ipc.processCount=1 で全タブ1processなんで、当然そうなるんですが。
例えばprocessCountが5でタブを10個開いた時、どういう割り当て方をされるのかわかりませんが(均等に割り当てられるのであれば1process2タブということに)、タブがcrashした時、道連れになるタブがあるってことで... 無関係な全く問題の無いタブが道連れになってしまう、というのはなんだかいかがなものかという気がするのですが。直観的じゃないというか、道連れになったタブ(のページ)に何か問題があったんじゃないかと疑われてしまうというか。違和感ハンパない。もちろんprocessCountを十分大きな値にすれば回避できる話ではあるんですが。
奇怪だ...

メインプロファイルでe10sを使う気はないのでいいんですけど。

[追記]
dom.ipc.processCount=2にしてタブを4つ開き、うち1つでcrashを引き起こしたところ。たまたま同じprocessで実行されていたgooのタブにもcrashマークが付いている(crashしている)。

(screenshotを取ろうと何度か試してみたら、crashタブ数は1,2,3,4全パターンあった-_-)
(まさかとは思うけどこれってprocessとは関係なく別の理由で発生してるんだろうか...)
(>processCountを十分大きな値にすれば回避できる話ではあるんですが。
ってのも怪しいな...)

[追記]
about:memoryでWeb Content (pid xxxx)を見ると、どのプロセスにどのタブが割り当てられるかはやっぱり均等じゃないですね。順繰りでもないし。謎。

 

コメント

2.5H

2015-05-15 09:48:20 | 雑記

Firefoxのビルドが。2.5時間...(・・)
Celeron847(メモリ8GB,SSD128GB)、Windows 8.1、Visual Studio 2013ce、で。

しかしprintfデバッグはできない(consoleに何も出てこない)のであった・・・

しかも--enable-debugでビルドしようとしたらエラーでビルドできないという・・・

どうしたもんか(-_-;)

[5/17追記]
で、--enable-debug-symbolsでビルドしてどうにかVisualStudioでのデバッグが可能になったところで力尽きた。breakpointで止めたい所で止められない止まらない(-_-) 止められる所でもなぜか一部メモリが読めず変数の値が分からない。ダメダコリャ

[5/19追記]
そうこうしている内にWindowsでMozTemp〜フォルダが残りっぱなしになるバグは修正されていたのであった(・・;)(mozilla-centralで)

 

コメント

backlog?

2015-05-09 14:23:09 | 雑記

1163115 – Enable APZ for all Desktop windows if E10S is enabled

え?
と思いつつ、ついこないだメモリ食いまくってFirefoxをハングさせたapzが今どうなってんのかと。試してみたらさすがにハングはしなかったけど、backで元のスクロール位置に戻れないバグは健在で。
1106280 – Vertical scroll position is not saved when pressing back button
Project Flagsのtracking-b2g: backlogって...どういう位置づけなんだろう(?_?)
backlogっていうと、私はリリース時の積み残し(ここはできてないけどとりあえずリリースしちゃうよっ!次のリリースで追加するからねっ!できたらねっ!的な^^;)のイメージが強くて、ヤな予感しかしないんですけど。
取りこぼすべきでない残務、の意味ならいいんですけどね...
だいたいblockerバグだろこれ(-_-)

[5/10追記]
戻れるページと戻れないページがある件については...session historyにviewerが保存されている場合にはスクロール位置が復元されず、session historyにviewerが保存されていなくて再ロードする場合にはスクロール位置も正しく復元される、らしく。
なのでbrowser.sessionhistory.max_total_viewersを0にしてしまえばとりあえず回避はできる、と。

 

コメント

Nightly 2題

2015-05-06 22:19:05 | 雑記

最近気づいたFirefox Nightlyの件。

1. Print〜Microsoft XPS Document Writerでファイルに落とそうとすると「この場所に保存するアクセス許可がありません」と拒否される。

1156742 – Low integrity content sandbox blocks Printing with "Microsoft XPS Document Writer" or "Print to file"
と同じ話のようで。
1151767 – Change the default Windows content sandbox to low integrity.
ここらへんを見ると、about:configでsecurity.sandbox.content.levelを1から0に変更してNightlyを再起動すればとりあえず回避できる、と。あるいはe10sをdisableに。

2. AppData\LocalLow\MozillaにMozTemp-{…}というフォルダが大量に...

削除してくれよ〜(-_-)
ってこれもsandboxのLow Integirity絡みなので回避策は上と同じ。

Nightlyだからバグはあっていいんだけど、いつfixされるの? ホントにfixされるの? と思うと、なんだかなぁ...
ま、e10sを使わなきゃいいだけの話なんですけど。当分の間は。...e10sがデフォになる日(予定では42?)なんて本当に来るのか?

[5/7追記]
MozTempが削除されない件はWindows7でも同じだった。0点。ていうか失格。

 

コメント

特に意味はないんですが

2015-05-05 19:02:13 | 雑記

というか無意味だとは思うけど。
現時点でFirefoxのe10sのパフォーマンスってどんなもんなのかと。
Free web browser performance benchmark test tools からの Peacekeeper - free universal browser test for HTML5 from Futuremark で1回だけ試してみたところ...

40.0a1 e10sのスコア:2760
40.0a1 非e10sのスコア:2920
38.0b9のスコア:3184
ついでに
IE11のスコア:1427(ただしVideo Codecが2つ足りなくて計測されてないのでそのせいかも)

でした。
えっと・・・(汗
もう1度だけe10sで試してみたら、スコアは2795だったので、仮にぶれ幅が±50程度あったとしても・・・劣化(滝汗

コメント

HTML5test

2015-04-30 10:14:18 | 雑記

Windows 10 The Latest【速報】:Build 2015で明らかになったWindows 10新情報とこれまでのまとめ - @IT
>Windows 10 TPビルド10061で、HTML5の仕様にどれくらい準拠しているかを調べるサイト(http://html5test.com/)を実行した結果
何気にFirefox38b8(beta)でそのサイトにアクセスしてみたら...

Your browser scores 467 out of 555 points

さらに40a1(nightly)では

Your browser scores 478 out of 555 points

でした。
記事によるとIE11は348、ビルド10061のEdgeは390。なんだこの差は...

[追記]
記事が更新されてるみたいで。ビルド10074でのスコアは402に。ガンバレ~

 

コメント

Nightly - APZ

2015-04-23 12:28:37 | 雑記

1154459 – Turn on APZ for Windows for one nightly
特に不具合は感じませんが、Backで元の位置に戻らない(ページトップが表示される)ケースが多発。戻るページと戻らないページとで何が違うのかさっぱりわかりませんが。
bugzillaをあさってみると...
1106280 – Vertical scroll position is not saved when pressing back button
2014-11-29...

もひとつおまけに
1. 新規profileで起動
2. Bookmarks Toolbarを表示させる
3. Bookmarks Toolbarを非表示にする
→カックンカックン
(縦スクロールバーと横スクロールバーが交互に表示される状態になる)
(たぶん 1157579 – Standalone Image vibrates with APZ enabled in Windows)
面白いけど...

 

コメント

続e10sではマウスポインタがおかしく

2015-04-15 10:18:52 | 雑記

(e10sではマウスポインタがおかしく の続き)

これってMouseEnterイベント時には無条件にSetCursorするとかしなきゃいけないんじゃ?と思いつつEventStateManager.cppを眺めていたら。
MouseEnterで処理するのではなく、MouseExit時にキャッシュをクリアする(更新フラグを立てる)という処理が!

>   case NS_MOUSE_EXIT:
>     // If this is a remote frame, we receive NS_MOUSE_EXIT from the parent
>     // the mouse exits our content. Since the parent may update the cursor
>     // while the mouse is outside our frame, and since PuppetWidget caches the
>     // current cursor internally, re-entering our content (say from over a
>     // window edge) wont update the cursor if the cached value and the current
>     // cursor match. So when the mouse exits a remote frame, clear the cached
>     // widget cursor so a proper update will occur when the mouse re-enters.
>     if (XRE_GetProcessType() == GeckoProcessType_Content) {
>       ClearCachedWidgetCursor(mCurrentTarget);
>     }

ちゃんと説明付き!(^^;;
こういう処理があるのなら、PuppetWidget.cppの

> PuppetWidget::SetCursor(nsCursor aCursor)
> {
>   if (mCursor == aCursor && !mUpdateCursor) {
>     return NS_OK;
>   }

ここはすり抜けてカーソルも変更されるはずなんだけど...
謎。

あぁパワフルなマシンが欲しい...(-_-; 「ビルドに5時間」の壁...
クリーンビルドじゃないけど、hg pullして最新版で検証しようとすると更新されたファイルが多すぎて、結局5時間かかるという...

で。動作を覗いてみると。
確かにClearCachedWidgetCursorが呼び出されて更新フラグは立つけれども。
直後になぜかまたSetCursorが呼び出されてしまい、更新フラグもoffになり、次のMouseEnter時にはカーソルは変更されないという次第。
で。ソースをよく見ると。ClearCachedWidgetCursor呼び出し直後に

>     // If the event is not a top-level window exit, then it's not
>     // really an exit --- we may have traversed widget boundaries but
>     // we're still in our toplevel window.
>     if (mouseEvent->exit != WidgetMouseEvent::eTopLevel) {
>       // Treat it as a synthetic move so we don't generate spurious
>       // "exit" or "move" events.  Any necessary "out" or "over" events
>       // will be generated by GenerateMouseEnterExit
>       mouseEvent->message = NS_MOUSE_MOVE;
>       mouseEvent->reason = WidgetMouseEvent::eSynthesized;
>       // then fall through...

fall throughしてUpdateCursor呼び出してSetCursorに行き着いており。ぉぃぉぃ
そこで更新フラグを倒してるから更新フラグ立てる意味無いじゃん。役立たず。

というわけでClearCachedWidgetCursorを処理ブロックの最後に持っていったらマトモに動作するようになったっぽい。マジカ
いやはや。

[4/19追記]
む。本件は
1018639 – [e10s] Mouse cursor indicates a bidirectional resize
で、4/18版Nightlyでfixされたようです。上記とは全然別のアプローチで。結局やっぱりMouseEnterで処理するようになったっぽい。

 

コメント

e10s: Make Link

2015-04-12 10:25:49 | 雑記

Firefox Nightly(40.0a1)のe10sモードでは Make Link :: Add-ons for Firefox が動作しないんですが。
Browser Consoleを見てたらtargetがnullだと。ソースを見ると、target = document.popupNode が失敗しているようで。
このpopupNodeって Document.popupNode - Web API Interfaces | MDN を見るとDeprecatedになってて"it is in the process of being dropped"と。
非e10sモードなら動作するのでpopupNodeが削除されたわけではなく単純にe10sのバグなんだろうけど、Deprecatedなものをサポートするんだろうか(?_?)ギモン
で、triggerNodeを使えってことなので使おうとしたらこれが取得できず...
さんざんググって見つけた解が「document.popupNodeをgContextMenu.targetに置き換える」でした。
javascript - How to get document.popupNode in Firefox Electrolysis windows - Stack Overflow
一応動作してます。

[追記]
そういえば何気にヌルッとmake_link-11.03-fx.xpiをダウンロードしてアーカイブの中のjavascriptを改変してFirefoxにdropしてinstallしたけど...署名付きaddonしかインストールできなくなったらrelease版ではこういうこともできなくなるんだよね?
それはそれで困りもののような...

 

コメント

Nightly: でっかくなっちゃった

2015-04-11 20:01:12 | 雑記

ボタンアイコンが(爆

今朝Firefox Nightlyをupdate(2015-04-10版に)したらツールバーのボタンアイコンが巨大化しており。
やれやれ...と思いつつ関係ありそうなbugfix(=regression)を探しつつCSSが大量に変更されたっぽい話を眺めつつ何が影響を与えたのか追求するのを面倒くさがりつつしかしこれってもしもFirefox側で何かしら仕様変更があったとしてもClassic Theme Restorerが面倒を見てくれたりするんじゃなかろうかと期待しつつとりあえずStylishで該当ボタンのwidthを強制設定してお茶を濁しつつ何気にCTRのsupport forumを覗いてみたらば。
[Ext] Classic Theme Restorer (Customize UI) #2 • mozillaZine Forums
とっくの昔に対処コードが(・・)
素晴らしすぎる

 

コメント