Chrome, Opera, Firefox add-on for KJCLUB

　という事でお引っ越し完了。 現在１．１５でチェック中ですが、今のところ　「機能そのもの」　で問題になるような部分は見つけられず。 強いて挙げるなら.... settings/migrate　のボタンを上にお引っ越しさせて(^^; 位かな。 登録数自体がそう多くないのであれば下にあってもあまり気にならないと思うのですが、登録パターンが多くなればなるほど、「下のボタンを出すためのスクロールダウン」にかかる時間が長くなって結構面倒（＞＜） 　ま理想をいうと、操作部分と登録データの表示部分を別にして、データスクロールで操作に支障が出ないようにする、というのが一番ありがたいのですが(^^;

7年前

という事で、発見。 ハンドル名：cuckoo^／アカウント：conca 当該者作成スレッド http://www.kjclub.com/jp/board/exc_board_9/view/id/2797050 Visualized/Raw　切替では、特に特殊なコードは認められず。 cuckoo^／conca　の定義だとBANされない。 cuckoo^／*　の定義でもBANされず。 *／conca　だと、右クリック定義からの変更、まるっと手打ちのいずれの定義でもBAN出来る ので、たぶんハンドル名側でなんかやってる（若しくは　"^"　記号で特殊処理に落ちてる？）と思われます。 追記： 　定義修正で気がついたのですが、定義データの逐次ソートがうまくいってない？　様に見受けられますm(__)m

7年前

ありがとうございます。^は正規表現で使う文字なのでその関係かもしれません. ちょっと確認してみます＾－＾

7年前

「正規表現で使う文字」　という事で、「例外処理系かな」　という事でさらに追加テスト。 ハンドル名：cuckoo*／アカウント：*　で登録するとBANされるようです。 という事は、"^"　が悪さをしてる、という線で確定かも。 上記の事から、とりあえず　「正規表現で使用している文字」　については、プログラム上で全チェックしておく必要はあるようですね(^^; という事で対処の程、宜しくお願いいたしますm(__)m

7年前

FBありがとうございます. 遅くなりましたが、妖精さんがv1.16を公開しました＾－＾ cucko*^ と cuckoo^でテストしましたが、いずれもマッチしたので多分直ってます. 「定義データの逐次ソート」は別途確認してみます. ID順とかだったような... このあとFixにむけてコメ欄修復機能と、別ブラウザ（Edge、狐for人造人間）への対応を進めるそうです^-^

7年前

1.17、確認しました。 例として挙げたcuckoo^についてはきちんと処理できているようで、助かります。 それと、「操作部分」が、「データのスクロール表示」と切り離されたのは、ほんとに助かります。　ワイルドカードを使った一般化登録への変更や、データクローニングの際に結構使うので、いつでもスイッチが表示されてるというのは、地味なことですが、使いやすくなってると思います。 　で、ソートですが、「ハンドル名が同一で、且つアカウントが違う」ものを複数登録した場合に出ます。 一番簡単に状況を作れるのは　「ハンドル名任意＋アカウントで条件設定」した場合です。 要は　「ハンドル名は詐称目的で共通項目がないが、アカウントにはアイデンティティとして特定文字列を入れている」　ユーザについて、一括でBANしたいという意図で登録していった場合、同様の登録をしているデータ間で、ソートされていない状況になってしまう、というわけです。 たぶん「ハンドル名」のみをソートキーにしているのが原因と思われ、arcticcat さんが　「仕様でそうしている」　のであれば、そこで終了、という話になると思います(^^;

7年前

妖精さんが1.18にアップデートしました.^-^ ・Microsoft Edgeへの対応（Storeへの登録方法確認中） ・ウジースレのコメント欄再構築（repairボタン） wiredrunner712 さん> ソート順は深く考えていなかったようなので、次バージョンでIDでのソートも追加するようにします^-^;

7年前

１．１９、確認しました。 基本はマルチブラウザ向けのためのブラッシュアップのようで、見栄え的にはコンテンツリペアボタンが増えた，という感じかな(^^; 　 　残念なことにウジースレは既にBAN対象にしているので．チェックできないのが(w)　ただ、コピペでスレッドを作った結果、タグ破壊でコメ欄が表示できないという例は多数あるので、それに出会ったら試してみようかと。 で。 やはり、「ハンドル名表示方法」の切り替えボタンの表示は、逆にした方がよいと思います。 現在だと、ボタンに 「Ｒａｗ」の表示がある時に「ブラウザでの見かけ上(つまりVisualized Data)の表示」が行われ、 「Visualized」の表示がある時に「実際のハンドル名(つまりRaw Data)のデータ表示」 が行われる様になっていますが、やはり逆にした方が、使う側にとってはわかりやすいと思います。 ので、 「Ｒａｗ」表示の時は、「実際のハンドル名のデータ表示」 「Visualized」表示の時は「ブラウザでの見かけ上の表示」 に変更いただきますよう、お願いします。

7年前

妖精さんが1.20にアップデートしました. ・ユーザー名・IDのソート切り替え ・Operaの審査対応 (ウジー対応が引っ掛かったので対応) Visualized（可視可済）の表記はちょっと紛らわしかったので結局Decodeボタンにしました. FBありがとうございます^-^

7年前

　遅くなりました。　1.20.0.0、確認。 ソートボタンが作られて、これを使えばユーザが「オンデマンド」でソートできる、という事ですね。 で、いじってみたところ、さきに報告した「同一ハンドル名・異種アカウント」でも、きちんとソートした状態に出来るようです。　これで、登録したアカウントを確認するのに苦労せずに済みます(^^; 表示破壊（レス書き込み部分破壊）については、とりあえずNorepairのままにしておき、問題が発生するスレッドにあたらないか期待しているのですが、なかなか当たらず（w） ま、よいことなのですが、チェックできないという状態は継続中(^^; アカウント表示の切り替えボタンにあるテキストは、変更後の方がわかりやすくてよいですね。 （Rawデータだと、判らない方だと判らない単語の上、「生データ」なら、隠蔽コードを何らかの手法で可視化した状態で表示するんじゃないの？　という解釈もあるので、複数の解釈がない記述の方がよいと思いますm(__)m）

7年前

長らく間が開いてしまいましたが、妖精さんが1.21にアップデートしました^-^ 巨大画像を普通に戻す機能と、大量の改行が除去されるようになりました. wiredrunner712 さん>FBありがとうございます. 挙げていただいた課題はいったん片付いたかな? また何か気になる点があればFBお願いします^-^

7年前

　えーと。 もしかしたら１．２１以降への版上げに伴う現象なのかなと気づいたので、報告。 　 Firefox版で確認しましたが、「表示のRemoveが処理前で一旦止まってる？」という感じの挙動になっています。 　 　動きとしては、 　 「スレッドを開くと、BAN対象として登録されているユーザの書き込みが、全て表示されている」→ 「BAN対象にしていたはずのユーザについて、ユーザ名を右クリック」 (「スレッド部分の書き込み表示部分を右クリックし、ブラウザのサブメニューをアクティブにする」　の方が適切な表現のようです）、→ 「表示抑制処理が始まり、BAN対象ユーザが全て表示抑制された状態になる」 　 という感じ。 　表示抑制処理が、入り口直後の部分で一旦止まってる？　様な動きに似てると思うのですが、そちらで再現できますでしょうか？ ちなみに同様の現象は、chrome系では発生していないっぽいです。

7年前

FBありがとうございます. 遅くなりましたが、妖精さんが1.23.0.0にアップデートしました. wiredrunnerさんご指摘の通り、remove周りに一つバグがあったので、修正したようです. あと、大量のimgタグを貼り付けるタイプのレスについても一応コメントできるよう暫定対応しました.

7年前

　対応、ありがとうございますm(__)m 大量のimgタグを貼り付けるタイプのレス＜-これへの対応は、望外で、とてもうれしいですm(__)mﾎﾝﾄﾀｽｶﾘﾏｽ

7年前

えーと。１．２３．０．０　で、以前に報告した「表示のRemoveが処理前で一旦止まってる？」　が再現。 発生スレッドは http://www.kjclub.com/jp/board/exc_board_9/view/id/2830451 divine_socialism　についてＢＡＮ設定をしてあるにもかかわらず、表示されてしまいます。 書き込みをクリックするとRemove処理が行われます。 ＦｘのデータをそのままChrome版にコピーすると正常にRemove処理がされるので、多分Ｆｘ版固有の現象、と思われます。 　推測すると....多分大元は「前回報告した部分」と同じ。　但し、違う部分。 「評価部分を複数パターン作る際、問題がある部分ありの状態でコピーして作った」ので、同じ問題が「別の評価ルーチン」に残ってるんじゃないかと。 ということで、チェックの程、お願いいたしますm(__)m

7年前

追記:登録アカウントをすべて削除した上でdivine_socialism　だけを再登録した場合だと、正常にRemoveされるようです。 で、Chromeにコピーしてあった全登録ユーザをコピーして持ってくると、「一旦ストップ」現象が再発。 ということは、処理そのものは正常に行われてるっぽいようです。 データ側に何らかの支障があるのかなぁ.... 　それと、報告とは関係がない別の現象について。 Windowsの作法だと、マウスを使ってテキスト選択をしたあと、選択部分上を右クリックするとサブメニュー(コピー等)が出てきます。　KJ-Eraser　を組み込んで且つ無効化している場合もこの作法は守られています。 が、KJ-Eraserを「有効化」すると、選択状態が解除されてしまいます。 （但しこちらは、マウスで選択後、　Ctrl-C　でコピーできるので代替方法はあります） さらに記載すると、どうやら全般的に、マウス右クリックで出すサブメニュー全般が、KJ-Eraserがアクティブになっていると、動きが怪しくなってるんじゃないかという気も(^^; テキストのコピペに関しては、Windowsのショートカットキーを使うことで回避出来はするのですが。 　更に、「書き込みの修正」を行おうしたとき。 KJ-Eraserが無効化されている場合、「既書き込み分」が編集ボックスに引用された上で、編集ができます。 KJ-Eraserが有効化されている場合、編集ボックスには何もテキストが無い状態での編集になります。 （正確には、一旦編集ボックスにテキストが引用されたあと、消去されている） さらに「バックグラウンドでいろいろやってるのかなー」というような画面の動きが見られ、再編集モードや返信では編集できない(^^; これについてはいろいろ試した結果、「一旦、Ｆｘ以外のウィンドウをアクティブにしたあと、再度Ｆｘをアクティブにする」と、なぜか編集ができることを偶然発見ｗ 　拡張機能中で、データの初期化を行う際、不適切な部分までを対象にしてる、あるいは初期処理そのものが多少おかしい(ループしてる？)のかなー、という気が。 　こちらの現象は、「KJ-Eraserを無効化」して回避するか、　「新規書き込み」をした上で旧書き込みを削除するかの二択になります。 「目的を達成する方法はある」ので、後回しでもいいのかなーと思いましたが、「マウス右クリック」全般に影響が出てる事を重く見るなら、優先順位はこちらの方が高いかも、ですm(__)m

7年前

まいどです。 KJ Eraserのおかげさまで、快適なKJ生活をおくっております。 ありがたいことです、感謝。 ところで。 あまりのかずのアホバカ成りすましアフィカスのせいで、 フィルター数がオーバーフローしたのか、指定しても反映されなくなってしまいました。 もしお手隙の際にご気分が乗ったらでけっこうです。 フィルタ指定の数をアップして頂けますと、 ますます幸せなKJ生活を送ることができます故、 なにとぞご検討のほどお願いいたします。

7年前

Ron Zacapa　＜－　ちょっと横から。 　ご存じだとは思うのですが、ワイルドカード指定すると、登録ユーザを減らせますよ。 例えば、 Display name * (アスタリスク１個) ID gg_* (gg_にアスタリスク１個) というパターン登録をしておくだけで、５、６個は登録数を減らせます。 このパターンで登録しておくと、表示されるハンドルはともかく、IDに関してアイデンティティを保ちたいというアホたちについて、過去のみならず未来に使うハンドルまでまとめてBAN出来るのでお薦めです。 で、拙も同様のことが起こってたみたいで、登録データを減らしたら「途中で非表示処理がストップ」という現象はなくなりました。１００個くらいなんですかねー、リミット。 エンブラだと一時期５００まで登録アカウントが伸びたのですが(w) ※登録データのバックアップがあったので見てみたら、１０００近く登録されてました(^^;

7年前

wiredrunnerさん、どもです。 恥ずかしながらワイルドカード指定は知りませんでした(´･ω･`) でもおかげさまで、とりあえずは全部やっつけることができました。 感謝！

7年前

せっかくワイルドカード教わったのに・・・ もうオーバーフローしちゃいました(´･ω･`)

7年前

　たぶん、作りとして「上限値設定」が少なすぎるのだと思います。 　ソフトやさん的にいえば、　「その時点で必要なキャパより１桁上」　はマスト。(例えば扱う数が１０００なら、１００００は見ておく） 　ある程度リミットを小さくしたいのなら、「その時点で」判明している上限値(つまりはＫＪで書き込みを行っている人数）　に対し、製品寿命までの伸び率を乗せた数　になるんですが(^^; とりあえず１０００のオーダーは必要だと思うんですけどね＞上限値

7年前

長らく放置しててすみません、こちらご迷惑おかけしてます. コード上は上限値と言うのは持っていないので、純粋にPGにバグがあるかブラウザのストレージを食い尽くしてるかのどっちかだと思います. FFとOperaは確かストレージの上限自体がとれないので、データがオーバーフローして変な感じになってるのかもしれません. ちょっと妖精さんに確認します^-^

7年前

ランキングについては、エクステンションからフィルタ情報を投げるのをどうセキュア（利用者にとって）にするか、と投げた先のAPIをどうセキュア（システムにとって）にするか、だけ解決すればいけるとおもいます. ただ個人的にはあんまり攻撃的な用途のものを作るのはどうかなとも思ったり＾－＾ 解決法は見えていて妖精さんが別で進めかけていたものに関連するので、こちらは少しお時間いただきたく.

7年前

　うーむ。とりあえず見つけたので。 Eraserバージョン：1．23．0．0 Chromeバージョン：75.0.3770.80（64bit版） Eraserの表示を見ると、94284bytes（aprx.987users） availableとあるのですが、８５パターンまでしか登録できません。 8６パターン目を右クリックして登録処理をしても、リストには載らず。 で、既登録ユーザから１パターンを削除すると、別パターンを登録出来ますが「削除した数」と「新規登録パターン」の数は常に同じで、８５以上の登録は出来ないようです。 (Fx版では、登録パターンのリミットはまだ見つけてません。１３５までは登録してみましたが、まだまだ天井は高いみたい) なお、この状態では、各板の一覧、およびスレッド表示でのＢＡＮ処理は正常に行うことが出来ています。

7年前

さらに。 Eraserバージョン：1．23．0．0 Firefoxバージョン：６７．０．２ 　 こちらは、登録ユーザ数に関してはリミットを見つけていません。 が、登録数が１２３を超えると、一覧、あるいはスレッドで「表示抑制処理」が効かなくなり、一覧あるいはスレッド表示でBAN対象が表示されてしまいます。 ただ、こちらは表示中のハンドル名（BAN対象設定の有無を問わず）右クリックすると［非表示処理がコンティニューされた」かのように、非表示設定したものが非表示になります。 これも、１２３パターンを超えると非表示が上手くいかないという現象が出るものの、１２２以下にすると、正常に処理されます。 これも謎状態(^^; 追記： 　登録数が58で「ＢＡＮ処理一時停止」が発生。 上記の書き込みも、テストしながらなので間違いはないと思うのですが.... 登録数の問題ではなく、BAN処理そのもののどこかに問題があるのかなぁorz

7年前

arcticcat ＜アプリケーション自体に「登録数上限」が設定されていないとすれば、内部的な要素(アドオンの環境設定、若しくは動作させているPCの環境そのもの)なのかなぁ＞原因 　 Ron Zacapa さんの書き込みのニュアンスから推測すると、Ronさんはchrome系のブラウザ(chrome／opera／vivaldi等)を使われてるのではと思うのですが、　「これ以上の登録は出来ない」　という数は、どのくらいですか？ うちと同じかなぁ？

7年前

あー。 こちらの環境を書かないといけませんよね。失礼しました。 wiredrunnerさんの御察しの通り、 MBP OSX10.11.6　＋　Chrome74.0　です。

7年前

フィルタ数は、８８が上限でした。

7年前

FBありがとうございます. 遅くなってすみませんが、こちらやはりストレージ上限が原因のようです. リッチなデータの持たせ方をしていたので、冗長なデータを削って登録数を増やせるように修正するとのことです. (例えば、IDがワイルドカード指定されていない(=対象が確定している)場合は表示名は持たない) 現状はご指摘の通り100件程度でいっぱいになりますが、いま300くらいは行けてます. もうちょっと増やせそうなのと、修正範囲が広いため念のため確認してから明日あたりにリリースします＾－＾

7年前

遅くなりましたが、妖精さんがv2.0.0.1を公開したようです＾－＾ バージョンの通り大幅な修正が入っているので、何か不具合があるかもしれません. ① SETTINGS ⇒ データをコピーし、念のためバックアップ ② MIGRATE ⇒ SAVE でデータが新形式に変換され、登録数自体は増えると思います.

7年前

　送れましたが、２．０．０．１、確認しました。 Ｆｘの方は、自動バージョンアップに任せる形で版上げしてみましたが、問題なくデータの変換は行われたようです。 これから、使用アドオンを切り替えてテストしてみます。 ありがとうございましたm(__)m

7年前

　テストしてみました。 うちの環境だけかもしれませんが....ちといろいろ起こってるような気が(--; 特にchrome版で、場合によっては抜き差しならない様な事になってるんじゃないかという気がします。 とりあえずちと風呂入ってから、改めてorz

7年前

えーと。　ご報告。 　先ずＦｘ版。 20．0．0．1でも、中折れ現象発生。　「非表示処理が途中でストップしている」　という感じの状況に変化は無しです。 加えて、KJ-Eraserをアクティブにしていると、ブラウザ上でテキスト選択状態から、選択テキスト上で右クリックすると、選択が解除される／スレッド内の書き込みについて修正モードで入ると「修正時に引用された大元のテキストが全てキャンセルされて空白になる」という状況も継続中。 　次にChrome版ですが.... 20.0.0.1を組み込み後、再起動したところ、以前に登録していた情報が全て消えています。 それはまだいいとして(よくないのですが(^^;)　、登録が出来ないorz 右クリックでKJ-Eraserメニューから登録処理をしても、BlackListに全く追加されません。 Display Name／ID　いずれでの登録を試してもしてもダメ。 全て手打ちで登録を試しても、登録されません。 加えて、SETTING／MIGRATEのいずれのボタンも反応なし。 　KJ-Eraserの削除を含む、思いつく限りのことをしても状況は全く変わらずchrome版に関しては、完全にお手上げ状態です。 ということで、ご確認の上、修正をお願いいたしますm(__)m

7年前

　さらにもう1つ。よい話とあまりよくない話。 よい話の方は、KJ-Eraser　の対応ブラウザに　Craving Explorer2 https://v2.crav-ing.com/ が加えられる、ということ。 　Craving ExplorerのV1.x系はIEベースでアドオン不可ですが、V2.x系はクロミウム系ベースのブラウザなので、Googleのウェブストアから問題なくインストール可能でした。 　よくない話の方は、　「Craving Explorer　V2.x」に、さらの状態からKJ-Eraser　V2．0．0．1をインストールしても、　1.2.xからアップデートした時と同様、Blacklistに関する全ての操作が効かない、ということ。 urlは拾って、kjにアクセスするとアクティブ化し、通常と同様登録処理そのものは操作できますが、実際には　「少なくとも見かけ上」　登録はされていない、という状態です。 メニューを見ると、登録処理部分はいじられているようです。 ので、もしかしたらクロミウム系側では、「データを拾ったあとの、ブラックリストへの登録処理」部分、それも「旧データからのコンバート処理」と共通しているところで失敗してるのかなー、という気が(^^;ｱｸﾏﾃﾞｽｲｿｸﾃﾞｽｶﾞ

7年前

もう1つ。 たぶん、DisplayName／ID　をキーとするソート処理ですが、データがnull　というパターンは考慮していなかったんじゃないかなー、と思います。 ので、こちらも「あとで」でよいので、対処をお願いいたしますm(__)m

7年前

毎度ご迷惑おかけします いったんクリティカルなところを修正しました＾－＾ ① 初期状態からのユーザー追加不可 以下FBいただいた事象は、確認しだい順次修正していくいくそうです ② ソートでnullが考慮されない ③ 編集時にコメント欄の内容がいったんクリアされる ④ FFにおいて対象ユーザーが途中までしか非表示にならない

7年前

　2.0.0.2、確認しました。 chrome／craving explorer　に組み込み、動作を確認。 ・　右クリックからのBlacklistへの登録 ・　既登録データの編集と登録 ・　既登録データの削除 ・　全て手打ちでの登録 までは確認しました。 ので、登録に関しては問題ないと思います。 　Eraserのウィンドウに、「だいたいの登録ユーザのリミット」が出るようになったのは、問題の切り分けがしやすい「手」だと思うです。 で、技術的に、ですが.... 「Display Name　のいかんに関わらず、IDのバリエーションだけで一括BAN」　したいのであれば.... 例えば、gg_nnnnnnnnnn（ｎは任意のテキスト）というパターンのＩＤを使うユーザについて一括BANしたい場合、 1．ｘ系だと Display name：* ID：　gg_* で登録していましたが、今後は Display name：ブランク(null) ID：　gg_* で登録した方が良さそうですが、この認識でＯＫでしょうか？

7年前

ご確認ありがとうございます＾－＾ 指定方についてはご認識の通り、空白 = * (全指定) です. 以下にまとめると (a) IDでフィルタリングする場合 　ID: id 　Display Name: (空白) (b) Display Name でフィルタリングする場合 　ID: (空白) 　Display Name: 表示名 (c) ID + Display Name でフィルタリングする場合 　ID: id (ワイルドカード * 指定のみ) 　Display Name: 表示名 ちなみにMIGRATE⇒SAVEで、* だけの値は空白に変換されます. また、IDが * を含まない場合、（IDだけでユーザーは確定されるので）Display Name は消えます.

7年前

どもです、いろいろエロエロありがとうございます。 こんな表示が出て登録できなくなっちゃいましたが、ウリが使えてないんでしょうか？ ご教授いただけたら嬉しいです。

7年前

Ron Zacapa > どうもです、ストレージ容量が一杯のメッセージですね. 以下の手順でいけないでしょうか？ ① SETTINGS ⇒ データをコピーし、念のため(メモ帳などに)バックアップ ② MIGRATE ⇒ SAVE ②でデータが新形式に変換され、300件くらいまでなら登録できるようになると思います＾－＾

7年前

フィードバックやレポートはないのですが、Ronさんの問題に関してはFixでいいと思います。 それと、Ｆｘで報告した、　KJ-Eraserがアクティブな状況での「テキスト選択状態からの右クリック」問題ですが、２０．０．０．２で、Chromeでも再現できました。　Operaでも確認できたので、Chrome系全般でも起こっている、と見てもよさそうです。

7年前

新しいスレッド、作った方がいいのかなぁ.... ということで、chromeでも中折れ現象、確認できました。 chrome　：バージョン: 75.0.3770.100（Official Build） （64 ビット） KJ-Eraser：バージョン：2.0.0.2 KJ-Eraser内の状態 ユーザ登録数：８２ MIGRATEで、登録者情報は改訂版に変換済。 6,798 bytes (aprx_399 users) available　という表示あり 現象：Ｆｘ版と外部から見た現象は同じ。 　ＢＡＮ対象で登録してあるユーザが、表示される。 スレッドの表示部分を右クリックすると、一時停止していた「非表示処理」が再稼働していたかのようになり、非表示対象ユーザの書き込みが消える。 　どうやら、Fx特有の問題ではなく、どちらでも起こる現象のようです。

7年前

間が空いてしまって本当に申し訳ないです. 最近いろいろと忙しくあまり時間が取れなくなったのと、KJ（というか日本のフォーラム）自体への関心自体が薄れており、なかなか手が出しづらい状況です. ご意見くださった方々、特にwireadrunnerさんには数々のフィードバックをいただいて本当にありがとうございました^-^ GitHubにコードは全部公開しているので有志が跡をついでくれればよかったんですが、残念ながらそういう方も現れそうにないので、いったんそちらはクローズさせていただきます。 現状の不具合については把握しておりますので、まとまった時間が取れたら直すかもしれませんが、いったん期待しない感じでいただければと. 最初は2-3hで作れそうだから作ろうかなという軽いノリだったんですが、ここまでスケールアウトしたのは正直予想外で妖精さんに要望を全て取り込める技術力がなくほんとすみません. 今後の反省とさせていただきます^-^

6年前