mono
こんにちは。 サイト固有かつFirefox+AutoPagerizeなどでも再現する問題なので、AutoPatchWorkのIssueとするのが適切かどうかわかりませんが、SITEINFOの修正だけでは解決できそうにない問題のような気がしたのでここに書き込ませていただきました。 もしSITEINFOの修正だけで済む問題だったらすみません。 Amazon.co.jpではある条件下 (詳細は不明ですが、手元ではAmazonにログインすると再現しました) でページャが新しいタイプのものに置き換えられるらしく、今回の問題はこの新しいページャで起きる問題です。 新しいページャでは、hash fragmentを利用して動的にページ切り替えを行うようになっており、それに伴ってnextLinkで指定されているpagnNextLinkのhrefが#から始まるものに変更されています。そのため、AutoPatchWorkが動作するとそのとき開いていたURLの内容がそのまま継ぎ足されてしまいます。SITEINFOを修正できないかと思ったのですが、DOMツリー上にnextLinkとして使えるような代わりの要素が見当たらなかったので、対処方法がわかりませんでした。 なお、問題が起きるのは最初の1回だけで、2回目以降は正しいページが継ぎ足されます。これは、pagnNextLinkのhrefはHTMLの時点では#から始まるものにはなっておらず、JavaScriptで動的に変更しているためだと思われます。 よろしくお願いします。
ページを開いてから一度もページ遷移していない状態でbackやfastbackアクションを実行すると、リロードされてしまうようです。 history.length == 1の時に、history.goの引数が0になるのが原因のようなので、チェックして弾くように変更しました。 よろしくお願いします。
私は今のところTwitterでしか見たことはありませんが、inputタグやtextareaタグの代わりに、contenteditable属性を利用してリッチな入力ボックスを提供している場合があるようです。 そこで、contenteditable属性を利用して作成された入力ボックスを認識し、アクションの無効化とvi like actionsの有効化が正しく行われるようにしてみました。コードは以下のとおりです。 mono0x/ChromeKeyconfig@f5aafe7b9f8f904a88ef1d66f7b8c81960421ac0 ただ、現状ではvi like actionsのカーソル移動の挙動に問題があるので、pull requestは送っていません。具体的には、CSSのoverflow:scrollが設定された入力ボックス (Twitterの入力ボックス) で、キャレットが移動した結果見えなくなるような場合に、スクロールせず、キャレットが見えない位置へ消えてしまいます。 解決方法がわからなかったため、不完全な状態での報告になり申し訳ありません。
**Describe the bug** In normal `textarea` and `textarea` in open custom elements (`attachShadow({ mode: "open" })`), shortcuts defined in Vimium are disabled and I can input these keys. However, in...