もずはっく日記からの検索結果
発見した件数: 42件 | 再検索| タイトル | 最終更新日 |
|---|---|
| 内容(最初の段落のみ) | |
| Bug-org 1468917 When the ATOK2016 candidate window pops up, it flickers if browser in maximized size mode | 2018年07月12日 |
| ATOK 2016を利用している際に、ウインドウを最大化すると候補ウインドウが一瞬画面端に表示されるというバグです。 (続く……) | |
| Bug-org 1242331 [e10s][TSF] When typing fast, IME composition may be committed unexpectedly and input won't cause text input after that | 2016年02月18日 |
| e10s モードで、 TSF モードでWebコンテンツに入力していると、子プロセスがビジーな場合、入力中の未確定文字列が強制的に確定され、再度入力しなければいけなくなるというバグです。 (続く……) | |
| Bug-org 1153156 [e10s] Mousewheel scroll distance does not match non-e10s (with apz disabled) | 2016年10月15日 |
| Windowsでは、マウスホイールのスクロール量のシステム設定が変更されていない場合、ルートのドキュメントのページ全体のスクロール時にのみ、スクロール量を倍にする システムスクロールオーバーライド という機能があります。 e10s モードが無効の時と、e10sモードが有効でも、 APZ が有効な場合には問題無く動いてるのですが、e10sモードが有効でAPZが無効の場合、スクロール量が本来の速度に戻ってしまい、遅く感じるというバグです。 (続く……) | |
| Bug-org 1237582 [TSF][e10s] Browser hangs after bug1234422 with (hidden) Microsoft New Changjie or New Quick | 2016年01月30日 |
| 繁体中国語(台湾・香港)用に以前はあった、MS New ChangJieと、MS New Quickという TIP が、 Windows 10でもレジストリを先にいじっておくと 、言語の追加で選択可能になるそうなのですが、これをNightlyで使ってみると、NightlyのプロセスがCPUリソースを食い続け、半分フリーズしたような状態になるというバグです。 (続く……) | |
| Bug-org 1208977 [TSF] [e10s] Candidate window position is sometimes at the top-left of screen at using MS-IME for Japanese on Win7 | 2016年01月30日 |
| e10s モードかつ、 TSF モードの場合、MS-IMEをWindows 7で使っていると、時々候補ウインドウが画面の左上に表示されるというバグです。 (続く……) | |
| Bug-org 1179632 [e10s][TSF] Remaining composition in child process causes hitting assertion aCompositionEvent->message == (2200) in child process | 2015年12月30日 |
| e10s モードで、コンテンツ内のテキストエディタに未確定文字列がある際に、ウインドウを×ボタンで閉じるとクラッシュするというバグです。 (続く……) | |
| Bug-org 1224454 [e10s][IMM][TSF] IMMHandler and TSFTextStore should clean up itself when focused widget being destroyed before NOTIFY_IME_OF_BLUR | 2015年11月21日 |
| e10s モードで、Webコンテンツのエディタがフォーカスを持っている時にウインドウの×ボタンでウインドウを閉じてFirefoxを終了させると、 NOTIFY_IME_OF_BLUR が子プロセスの IMEContentObserver から送信されても、親プロセスの TabParent::GetWidget() が既に nullptr を返してしまうため、適切な nsWindow に通知することができないことが発覚しました。このため、IMEのイベントハンドラである TSFTextStore や IMMHandler 自身のインスタンスやそれが掴んでいる様々なオブジェクトが未解放のままプロセスが終了してしまい、メモリリークを起こしていたというバグです。 (続く……) | |
| Bug-org 1184890 [e10s][GTK][TSF] cannot input composing string on comment of articles on Facebook | 2015年10月31日 |
| Bug-org 1189396 と同じ話の e10s モード版です。 (続く……) | |
| Bug-org 1215434 APZC shouldn't handle eWheel event when the event will be handled by plugin | 2015年10月31日 |
| e10s モードが有効になっているNightlyでは APZC がデフォルトで有効になっていますが、この場合、 Bug-org 376679の修正 がAPZCによって無視され、windowlessプラグインにホイールイベントが伝達されません。 (続く……) | |
| Bug-org 1203381 IMEContentObserver should not post new notification after it posts some notifications but some of them are not performed yet | 2015年09月29日 |
| IMEContentObserver のログを記録できるようにしてみたところ、異常な回数、 NOTIFY_IME_OF_POSITION_CHANGE を送信しているのを発見しました。もし無駄な呼び出しがあった場合、 e10s モードではかなり無駄にCPUを走らせていることになります。 (続く……) | |
| Bug-org 1205945 [e10s] Japanese IME of OS X 10.10 sometimes shows candidate window to bottom-left of the screen | 2015年09月29日 |
| TSF の TS_E_NOLAYOUT のような問題がMac OS X 10.10.xのIMEでも発生しているというバグです。また、直前に確定した未確定文字列が新しい未確定文字列の変換候補に出てくるというバグも原因が同じバグだったのでこの修正により解決しています。 (続く……) | |
| Bug-org 1187583 [TSF][e10s] MS Office IME 2010's candidate window sometimes appears and flickers at top-left corner | 2015年09月29日 |
| Bug-org 1204523でMS-IME向けに修正した のと同じ症状がMicrosoft Office IME 2010でも候補ウインドウの表示時に発生しているというバグです。 (続く……) | |
| Bug-org 1204523 [e10s][TSF] The suggest window position of Japanese MS-IME for Win8.1 and Win10 is sometimes positioned top-left of the screen | 2015年09月28日 |
| Windows 8以降のMS-IMEには未確定文字列の変換候補を変換前から提案してくるサジェスト機能がありますが、このウインドウが e10s モードでは時々、画面の左上に一瞬だけ表示されることがあるというバグです。 (続く……) | |
| Bug-org 1200980 [e10s][TSF] Candidate window is sometimes not positioned properly because IMEContentObserver sometimes fails to notify IME of selection change | 2015年09月17日 |
| twitter.comでリプライを入力する時にATOKのナビバーや、様々な TIP のサジェストウインドウや、候補ウインドウがキャレット位置等の適当な位置に表示されないというバグです。 (続く……) | |
| Bug-org 1198594 crash in libsystem_kernel.dylib@0x16286 | 2015年08月30日 |
| Mac OS X 10.10でエディタにフォーカスを合わせると高確率でクラッシュするらしいバグです。スタックが変なことになっていますが、よく見ると、 ContentCacheInParent::FlushPendingNotifications() 内で delete を行っている最中にクラッシュしているようでした。 (続く……) | |
| Bug-org 1183873 5,000 instances of "'!mContentCache.CacheEditorRect(this, &aIMENotification)'" and associated warnings emitted from widget/PuppetWidget.cpp during linux64 debug testing | 2015年08月26日 |
| GTK版のFirefoxのみ、デバッグビルドでウインドウを移動すると警告が大量に出るため、自動テストのログが5,000の、 !mContentCache.CacheEditorRect(this, &aIMENotification) とそれに付随して出る警告で埋まっているというバグです。 (続く……) | |
| Bug-org 1187579 [e10s][TSF] Enable TSF mode in e10s mode | 2015年08月09日 |
| まだ、内部的には問題が残っているものの、日常利用のレベルでは e10s モードでも、 TSF モードが問題無く利用できるレベルになったので、デフォルトで有効にしようというバグです。 (続く……) | |
| Bug-org 1050644 [TSF][e10s] Candidate window of TIPs don't work correctly | 2015年08月09日 |
| e10s モードで、 TSF モードを有効にしていると、様々な TIP で候補ウインドウ位置やサジェストウインドウ位置がおかしくなるというバグでしたが、これまでの修正により、確認されている問題はWindows 8以降のMicrosoft謹製の中国語(簡体字・繁体字共)のTIPで全くウインドウが表示されないというバグだけになりましたのでその修正をこのバグで行いました。 (続く……) | |
| Bug-org 1187351 [e10s][TSF] TSFTextStore::GetTextExt() shouldn't return TS_E_NOLAYOUT after notifying TSF of layout change | 2015年07月26日 |
| TSFTextStore は NOTIFY_IME_OF_POSITION_CHANGE を受け取った際に、 ITextStoreACPSink::OnLayoutChange() を呼び出すことがありますが、この際に、キャッシュしているコンテンツのレイアウトが不確定な最初の文字のオフセットをリセットしていませんでした。そのため、 TSF や TIP からすると、レイアウトの計算が終わったと通知が来たのに、 ITextStoreACP::GetTextExt() を呼び出してみたら、まだだって言われる、という状況に陥っていました。 (続く……) | |
| Bug-org 1187367 [e10s][TSF] TSFTextStore shouldn't destroy native caret until notifying TSF of layout change | 2015年07月26日 |
| TSF -awareなアプリで動作しているATOKは、何故かネイティブキャレットの位置を参考にサジェストウインドウ位置を決めています。これに対応するため、 ITextStoreACP::GetTextExt() が呼び出された時に、その位置にネイティブキャレットを作成し、ドキュメントのロックが解除された時にキャレットを破棄していました。 (続く……) | |
| Bug-org 1185316 [e10s][TSF][GTK?] TabChild should notify TabParent of receiving WidgetCompositionEvent or WidgetSelectionEvent after dispatching it | 2015年07月26日 |
| Bug-org 1176954の修正 では、子プロセスがイベントを受信したら、親プロセスにそれを通知することで親プロセスがIMEに各種通知を発行するタイミングを調整するようにしましたが、この状態で通知すると、それにIMEが反応してコンテンツを取得しに来た場合、一番最後に送信したイベントの結果がまだ、 TabParent 内のキャッシュに反映されていない可能性があることに気付きました。 (続く……) | |
| Bug-org 1184986 [e10s][TSF] ContentCache shouldn't notify IME of layout change until all sending events are handled | 2015年07月26日 |
| Bug-org 1176954の修正 で、IMEへの通知を一部、子プロセスへの送信中のイベントが残っている場合には延期するようにしましたが、 NOTIFY_IME_OF_POSITION_CHANGE に関してもそれが必要というバグです。 (続く……) | |
| Bug-org 1176959 [e10s][GTK] Kakutei-Undo of Mozc doesn't work | 2015年07月19日 |
| e10s モードでは、GTK版Mozcの確定アンドゥが機能していませんでした。 (続く……) | |
| Bug-org 1176955 [e10s][TSF] Kakutei-Undo of Japanese IME doesn't work | 2015年07月19日 |
| e10s モードでは、 TSF モード時にATOK等の実装している確定アンドゥが動かないというバグです。 (続く……) | |
| Bug-org 1184004 [e10s] Methods to notify IME should use IMENotification at IPC | 2015年07月19日 |
| e10s モードでは、コンテンツからIMEへの通知はIPC通信を通して行われるわけてすが、この時に、何故か IMENotification を直接送受信せず、必要な内容を個別の引数にして渡していました。このため、受信した側ではまた IMENotification を再度作らないといけないため、 IMENotification の内容が変更される度に変更のコストがけっこう大きかったわけです。 (続く……) | |
| Bug-org 1176950 [e10s][TSF] nsTextStore shouldn't abandon locked content cache before dispatching events because they may be handled asynchronously in e10s mode | 2015年07月19日 |
| nsTextStore は、ドキュメントがロックされている間はコンテンツがJavascriptによって更新されることを防ぐため、コンテンツを予めキャッシュした上で、ドキュメントがアンロックされるまで、イベントを送信しないようにしています。 (続く……) | |
| Bug-org 1176954 [e10s][TSF][GTK?] TabParent shouldn't notify IME until all sending events are handled | 2015年07月19日 |
| e10s モードでは、子プロセスがフォーカスを持つ場合、chromeイベントでハンドリングしたネイティブのIMEイベントが、非同期で子プロセスに処理されることになります。ここで困るのが TSF やGTKでIMEに選択範囲の変化等を通知するタイミングです。これまでは、子プロセスから通知が来た場合に即、TSFやGTKに通知を行っていましたが、子プロセスの処理が遅れている場合、TSFやGTKからするといくつか前の状態が通知されるというおかしなことになります。 (続く……) | |
| Bug-org 1179122 [e10s] TextComposition should manage target in parent process even when its child process has focus | 2015年07月19日 |
| e10s モードでは、ネイティブのフォーカスは、常にchromeプロセスが持っています。つまり、IMEからのネイティブイベントをハンドリングするのはchromeプロセスになります。そして、各OS向けのwidgetが生成した WidgetCompositionEvent は、子プロセス内にフォーカスがある場合に、 EventStateManager::PreHandleEvent() で子プロセスにイベントを送信し、chromeプロセス内では何もしないという形をとっていました。つまり、 WidgetCompositionEvent の送信ターゲットを管理する TextComposition のインスタンスは子プロセスでのみ生成されていました。 (続く……) | |
| Bug-org 1053053 [e10s][TSF] Typed text appears in unfocused textarea when using IME | 2015年07月07日 |
| e10s を有効にしていると、contentプロセス内のエディタにフォーカスを移し、その後、chromeプロセス内のエディタにフォーカスを移動させてもcontentプロセス内のエディタに未確定文字列が表示されるというバグです。 (続く……) | |
| Bug-org 1175392 [e10s] IME Blur may be too late when moving focus from content to chrome due to race condition | 2015年06月30日 |
| 子プロセスのエディタがフォーカスを失い、親プロセスのエディタがフォーカスを得る場合には確実に発生するのですが、chromeプロセスからIMEに対してfocusとblurを通知する順序が、 (続く……) | |
| Bug-org 1177388 [e10s] ContentCache should be separated as two clasesses | 2015年06月30日 |
| ContentCache の初期実装時 には、親プロセスのみで利用されるべきメンバと、子プロセスでみ利用されるべきメンバをコメントや、 ContentCache::mIsChrome でバグを検出するようにしていました。しかし、親プロセス側にメンバを大量に追加する必要が出てきているのと、 mIsChrome は親プロセスで true になるわけではなく、chromeプロセスでのみ true になるようになっていたため、B2Gで利用されているネストされたマルチプロセスではうまく動かなくなっていました。これらの問題を修正するためにクラスを親プロセス用と子プロセス用に分離する必要が出てきました。 (続く……) | |
| Bug-org 1171796 [e10s] MOZ_LOG() and stderr from child process are not outputted into log file nor terminal on Windows | 2015年06月19日 |
| Windows上で e10s をデバッグしようとすると、デバッグビルドの実行時にプロンプトにも printf() 等での出力が出力されませんし、 MOZ_LOG() で出力したログも、ファイルは生成されるものの一行も生成されないというバグです。 (続く……) | |
| Bug-org 1175383 [e10s] TabChild should store PuppetWidget directly instead of nsIWidget | 2015年06月19日 |
| TabChild は自身で PuppetWidget のインスタンスを生成し、保持し続けますが、その間、ずっと nsCOMPtr<nsIWidget> mWidget; として保持しています。そのため、ぱっと見、 mWidget が PuppetWidget 以外の可能性があるかのように見えますし、実際に PuppetWidget 固有のメソッドにアクセスする場合には static_cast を利用していて、コードがスッキリしていませんでした。 (続く……) | |
| Bug-org 1172219 [TSF][e10s] nsTextStore should put off to send notifications to TSF if it's dispatching composition events but hasn't received update composition notification | 2015年06月19日 |
| 今のところ実害を発見していないバグですが、 nsTextStore はイベントの発火後に、そのハンドリングが終了したという通知が来ているか確認せずに TSF に様々な通知を返しているため、 e10s の動作によっては、TSFや TIP がコンテンツの内容を問い合わせて来ても、想定していない結果が返されて、挙動がおかしくなったり、そもそも動作しなくなったりする可能性があります。 (続く……) | |
| Bug-org 1171814 [e10s] ContentCache should always store first text rect because Yosemite's Japanese IME tries to retrieve it | 2015年06月19日 |
| Mac OS X Yosemiteの日本語入力のアプリは、長らく標準で使われていたことえりから別物になっています。この新しい IME は何故か時折、最初の文字の矩形を取得しに来ます。 (続く……) | |
| Bug-org 1173678 [e10s] ContentCache::GetUnionTextRect() should ignore some text rects which are not cached | 2015年06月19日 |
| e10s モードでは TabParent が IME から受け取ったイベントを子プロセスに送信し、その結果を受けとるまでにはタイムラグがあります。そのため、未確定文字列の変更直後にIMEがコンテンツを確認しにきた場合、必ず、 TabParent 側の ContentCache には古い情報がキャッシュされていることになります。 (続く……) | |
| Bug-org 1172466 IMEContentObserver shouldn't notify IME during reflow | 2015年06月19日 |
| IMEContentObserver はフォーカスを持ったエディタの内容の変化を監視し、 IME が必要としている場合はそれを nsIWidget 経由で通知します。また、自身の生成時と破棄時にはIMEにフォーカスを得たことと失ったことを通知します。 (続く……) | |
| Bug-org 1171810 [e10s] TabParent should cache union text rect of whole selection | 2015年06月19日 |
| e10s モードでは、 IME が同期的にコンテンツの情報を取得することができないので、 TabParent 内の ContentCache が必要されるであろう文字の矩形を予めキャッシュしています。このような手法でIMEのハンドリングを実装しているため、様々なケースに対応できるように矩形のキャッシュを無理の無い範囲で増やしていかなくてはいけません。 (続く……) | |
| Bug-org 1166436 crash in mozilla::dom::TabParent::HandleQueryContentEvent(mozilla::WidgetQueryContentEvent&) | 2015年06月06日 |
| Windows x64版で e10s が有効かつ、 IMM モード(現在、Nightlyでもe10sモードの場合はIMMモードが標準)の場合、 TabParent が NS_QUERY_TEXT_RECT をハンドリング中にクラッシュする、というバグです。ちなみに、crash reportを見てみると、Macでも希に発生している模様です。 (続く……) | |
| Bug-org 975383 Dispatch compositionupdate from TextComposition rather than widget | 2014年10月30日 |
| 現在、 compositionupdate の内部イベントである、 NS_COMPOSITION_UPDATE イベントは、各OS用の widget から発火していますが、同じロジックで発火している上、XPレベルでは、 TextComposition クラスで管理している未確定文字列の情報を widget 側と二重管理するのは勿体ないということで、 NS_COMPOSITION_UPDATE を、 TextComposition で発火するようにしよう、というバグです。 (続く……) | |
| Bug-org 1065835 TextComposition should have API to commit or cancel composition and if widget doesn't perform it synchronously, it should synthesize composition end event | 2014年09月30日 |
| TextComposition に、IMEの未確定文字列を強制確定、もしくは強制キャンセルさせるAPIを追加し、 TextComposition 自身が同期的にこれを実行することを保証すべき、というバグです。 (続く……) | |
| Bug-org 1059680 [e10s][TSF][IMM32] IME should be able to handle mouse events fired in content process | 2014年09月25日 |
| Bug-org 826657の修正 により、フォーカスを持ったエディタ内の文字がクリックされた際に、widgetはその通知を受け取ることができるようになり、IMEがそのイベントを消費した場合には、content側ではそのイベントを無視するようになりました。 (続く……) | |
発見した件数: 42件 | 再検索