Chrome, Opera, Firefox add-on for KJCLUB

2213458 JA 255

2019-02-09 16:22

크롬 Extension "KJ Eraser" 의 보수용 스레입니다.＾-＾

　Chrome

https://chrome.google.com/webstore/detail/kj-eraser/cookadobdgkdcaddopogkaocnnjejiba

　FireFox

https://addons.mozilla.org/ja/firefox/addon/kj-eraser/

　Opera

https://addons.opera.com/ja/extensions/details/kj-eraser-2/

　Vivaldi
https://chrome.google.com/webstore/detail/kj-eraser/cookadobdgkdcaddopogkaocnnjejiba

　Git (source code)

https://github.com/precious-days-inc/KJ-Eraser

★ Planned Updates

　Firefox (Android)

　Microsoft Edge

Have a precious kj life !

원문보기

Chrome, Opera, Firefox add-on for KJCLUB

クロームExtension "KJ Eraser" の保守用スレです.＾－＾

　Chrome

https://chrome.google.com/webstore/detail/kj-eraser/cookadobdgkdcaddopogkaocnnjejiba

　FireFox

https://addons.mozilla.org/ja/firefox/addon/kj-eraser/

　Opera

https://addons.opera.com/ja/extensions/details/kj-eraser-2/

　Vivaldi
https://chrome.google.com/webstore/detail/kj-eraser/cookadobdgkdcaddopogkaocnnjejiba

　Git (source code)

https://github.com/precious-days-inc/KJ-Eraser

★ Planned Updates

　Firefox (Android)

　Microsoft Edge

Have a precious kj life !

좋아요·댓글을 남기려면 로그인해 주세요.

댓글 ( 43 )

4 이전 글보기

　그래서 이사 완료. 현재 1.15로 체크중입니다만, 현재　「기능 그 자체」로 문제가 되는 부분은 찾아낼 수 있는 두. 억지로 든다면.... settings/migrate　의 버튼을 위에 이사해 시켜(^^; 정도일까. 등록수자체가 그렇게 많지 않은 것이면 아래에 있어도 별로 신경이 쓰이지 않는다고 생각합니다만, 등록 패턴이 많아지면 질 수록, 「아래의 버튼을 내기 위한 스크롤 다운」에 걸리는 시간이 길어져 상당히 귀찮음(＞＜) 　이상을 말하면, 조작 부분과 등록 데이터의 표시부분을 따로 하고, 데이터 스크롤로 조작에 지장이 나오지 않게 한다, 라고 하는 것이 제일 고맙습니다만(^^;

7년 전
4 이전 글보기

그래서, 발견. 핸들명：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년 전
3 이전 글보기

감사합니다.^(은)는 정규 표현으로 사용하는 문자이므로 그 관계일지도 모릅니다. 조금 확인해 보겠습니다＾-＾

7년 전
4 이전 글보기

「정규 표현으로 사용하는 문자」라고 하는 일로, 「예외 처리계일까」라고 하는 일로 한층 더 추가 테스트. 핸들명：cuckoo*/어카운트：*　그리고 등록하면 BAN 되는 것 같습니다. 그렇다고 하는 것은,"^"　하지만 나쁨을 하고 있다, 라고 하는 선으로 확정일지도. 상기의 일로부터 우선　「정규 표현으로 사용하고 있는 문자」에 대해서는, 프로그램상에서 전체크해 둘 필요는 있다 팔짱 무릎(^^; 그래서 대처의 정도, 잘 부탁드리는 m(__) m

7년 전
3 이전 글보기

FB 감사합니다. 늦어졌습니다만, 요정씨가 v1.16을 공개했습니다＾-＾ cucko*^ 와 cuckoo^로 테스트했습니다만, 모두 매치했으므로 아마 고쳐지고 있습니다. 「정의 데이터의 순서대로 소트」는 별도 확인해 보겠습니다. ID 순서라든지였던 것 같은... 이후에 Fix로 향해서 쌀란수복 기능과 별브라우저(Edge, 여우 for 인조인간)에의 대응을 진행시킨다고 합니다 ^-^

7년 전
4 이전 글보기

1.17, 확인했습니다. 예로서 든 cuckoo^에 대해서는 제대로 처리 되어 있는 것 같고, 살아납니다. 그것과 「조작 부분」이, 「데이터의 스크롤 표시」라고 떼어내진 것은, 정말 살아납니다.　와일드 카드를 사용한 일반화 등록에의 변경이나, 데이터 클로닝 시에 상당히 사용하므로, 언제라도 스윗치가 표시되고 있다고(면) 말하는 것은, 수수한 일입니다만, 사용하기 쉽게 되고 있다고 생각합니다. 　그리고, 소트입니다만, 「핸들명이 동일하고, 한편 어카운트가 다르다」 것을 복수 등록했을 경우에 나옵니다. 제일 간단하게 상황을 만들 수 있는 것은　「핸들명 임의＋어카운트로 조건 설정」했을 경우입니다. 요점은　「핸들명은 사칭 목적으로 공통 항목이 없지만, 어카운트에는 아이덴티티로서 특정 문자열을 넣고 있다」유저에게 대해서, 일괄로 BAN 하고 싶다고 하려는 의도로 등록하며 갔을 경우, 같은 등록을 하고 있는 데이터간으로, 소트 되어 있지 않은 상황이 되어 버린다, 라고 하는 것입니다. 아마 「핸들명」만을 소트 키로 하고 있는 것이 원인이라고 생각되어 arcticcat 씨가　「사양으로 그렇게 해서 있다」 것이면, 거기서 종료, 라고 하는 이야기가 된다고 생각합니다(^^;

7년 전
3 이전 글보기

요정씨가 1.18에 업데이트 했습니다.^-^ ·Microsoft Edge에의 대응(Store에의 등록 방법 확인중) ·우지스레의 코멘트란재구축(repair 버튼) wiredrunner712 씨> 소트순서는 깊게 생각하지 않았던 것 같아서, 다음 버젼으로 ID로의 소트도 추가하도록(듯이) 하는 ^-^;

7년 전
4 이전 글보기

1.19, 확인했습니다. 기본은 멀티 브라우저 전용을 위한 브러시 업같고, 볼품적으로는 컨텐츠 리페어 버튼이 증가했다는 느낌일까(^^; 　　유감스럽게 우지스레는 이미 BAN 대상으로 하고 있으므로.체크할 수 없는 것이(w) 단지, 코피페로 스렛드를 만든 결과, 태그 파괴로 쌀란을 표시할 수 없다고 하는 예는 다수 있다의로, 거기에 만나면 시험해 볼까하고. 그리고. 역시, 「핸들명 표시 방법」의 변환 버튼의 표시는, 반대로 하는 것이 좋다고 생각합니다. 현재라고, 버튼에 「Raw」의 표시가 있다 때에 「브라우저로의 외관상(즉 Visualized Data)의 표시」를 해 「Visualized」의 표시가 있다 때에 「실제의 핸들명(즉 Raw Data)의 데이터 표시」 (을)를 하는 것처럼 되어 있습니다만, 역시 반대로 하는 것이, 사용하는 측에와는은 알기 쉽다고 생각합니다. 의로, 「Raw」표시때는, 「실제의 핸들명의 데이터 표시」「Visualized」표시때는 「브라우저로의 외관상의 표시」 (으)로 변경 주시도록, 부탁합니다.

7년 전
3 이전 글보기

요정씨가 1.20에 업데이트 했습니다. ·유저명·ID의 소트 변환 ·Opera의 심사 대응 (구더기-대응이 걸렸으므로 대응) Visualized(가시가제)의 표기는 조금 혼동하기 쉬웠기 때문에 결국 Decode 버튼으로 했습니다. FB 감사합니다 ^-^

7년 전
4 이전 글보기

　늦어졌습니다.　1.20.0.0, 확인. 소트 버튼이 만들어지고, 이것을 사용하면 유저가 「온디멘드」로 소트 할 수 있다, 라고 말하는 것이군요. 그리고, 만져 보았는데, 먼저 보고한 「동일 핸들명·이종 어카운트」에서도, 제대로 소트 한 상태에 할 수 있는 것 같습니다.　이것으로, 등록한 어카운트를 확인하는데 고생하지 않고 끝납니다(^^; 표시 파괴(레스 기입 부분 파괴)에 대해서는 우선 Norepair대로 해 두어, 문제가 발생하는 스렛드에 해당하지 않는가 기대하고 있습니다만, 좀처럼 맞지 않고(w) 뭐,야 있어 일입니다만, 체크할 수 없다고 하는 상태는 계속중(^^; 어카운트 표시의 변환 버튼에 있는 텍스트는, 변경 후가 알기 쉽고 좋네요. (Raw 데이터라고, 모르는 분이라고 모르는 단어 위, 「생 데이터」라면, 은폐 코드를 어떠한 수법으로 가시화한 상태로 표시하지 않아?　그렇다고 하는 해석도 있으므로, 복수의 해석이 없는 기술이 좋다고 생각하는 m(__) m)

7년 전
3 이전 글보기

오랫동안 사이가 열려버렸습니다만, 요정씨가 1.21에 업데이트 했습니다^-^ 거대 화상을 보통으로 되돌리는 기능과 대량의 개행이 제거되게 되었습니다. wiredrunner712 씨>FB 감사합니다. 들어 준 과제는 일단 정리되었는지? 또 무엇인가 궁금한 점이 있으면 FB부탁하는 ^-^

7년 전
4 이전 글보기

　네-와. 혹시 1.21이후에의 판 인상에 수반하는 현상인가와 눈치챘으므로, 보고. 　 Firefox판으로 확인했습니다만, 「표시의 Remove가 처리전에 일단 멈추어 있어?」라고 하는 느낌의 거동이 되어 있습니다. 　　움직임으로서는, 　「스렛드를 열면, BAN 대상으로 해서 등록되어 있는 유저의 기입이, 모두 표시되고 있다」→ 「BAN 대상으로 하고 있었음이 분명한 유저에게 대해서, 유저명을 오른쪽 클릭」 ( 「스렛드 부분의 기입 표시부분을 오른쪽 클릭해, 브라우저의 부메뉴를 액티브하게 한다」(분)편이 적절한 표현같습니다),→ 「표시 억제 처리가 시작되어, BAN 대상 유저가 모두 표시 억제된 상태가 된다」　 그렇다고 하는 느낌. 　표시 억제 처리가, 입구 직후의 부분에서 일단 멈추어 있어?　님움직임을 닮고 있다고 생각합니다만, 그 쪽에서 재현할 수 있으십니까? 덧붙여서 같은 현상은, chrome계에서는 발생하고 있지 않는 같습니다.

7년 전
3 이전 글보기

FB 감사합니다. 늦어졌습니다만, 요정씨가 1.23.0.0에 업데이트 했습니다. wiredrunner 산호 지적대로, remove 주위에 하나 버그가 있었으므로, 수정한 것 같습니다. 그리고, 대량의 img 태그를 붙이는 타입의 레스에 대해서도 일단 코멘트할 수 있도록 잠정 대응했습니다.

7년 전
4 이전 글보기

　대응, 감사합니다 m(__) m 대량의 img 태그를 붙이는 타입의 레스＜-이것에의 대응은, 기대한 이상임으로, 매우 기쁩니다 m(__) m진짜 타스 칼리 매스

7년 전
4 이전 글보기

네-와.1.23.0.0　그리고, 이전에 보고한 「표시의 Remove가 처리전에 일단 멈추어 있어?」(이)가 재현. 발생 스렛드는 http://www.kjclub.com/jp/board/exc_board_9/view/id/2830451 divine_socialism　에 붙어 BAN 설정이 되어 있는 것에도 불구하고, 표시되어 버립니다. 기입을 클릭하면 Remove 처리를 합니다. Fx의 데이터를 그대로 Chrome판에 카피하면 정상적으로 Remove 처리가 되므로, 아마 Fx판 고유의 현상, 이라고 생각됩니다. 　추측하면....아마 오모토는 「전회 보고한 부분」과 같다.　단, 다른 부분. 「평가 부분을 복수 패턴 만들 때, 문제가 있다 부분 있는 상태로 카피해 만들었다」 것으로, 같은 문제가 「다른 평가 루틴」에 남아있는 가 아닐까. 그렇다고 하는 것으로, 체크의 정도, 부탁드리는 m(__) m

7년 전
4 이전 글보기

덧붙여 씀:등록 어카운트를 모두 삭제한 다음 divine_socialism　만을 재등록했을 경우라면 정상적으로 Remove 되는 것 같습니다. 그리고, Chrome에 카피되어 있던 전등록 유저를 카피해 가져오면, 「일단 스톱」현상이 재발. 그 말은, 처리 그 자체는 정상적으로 행해지고 있는 같은 것 같습니다. 데이터 측에 어떠한 지장이 있다 의 것인지인.... 　그것이라고 보고와는 관계가 없는 다른 현상에 대해. Windows의 작법이라고, 마우스를 사용해 텍스트 선택을 한 뒤, 선택 부분상을 오른쪽 클릭하면 부메뉴(카피등 )가 나옵니다.　KJ-Eraser　(을)를 짜넣어 한편 무효화하고 있는 경우도 이 작법은 지켜지고 있습니다. 하지만, KJ-Eraser를 「유효화」하면, 선택 상태가 해제되어 버립니다. (단 이쪽은, 마우스로 선택 후,　Ctrl-C　그리고 카피할 수 있으므로 대체 방법은 있어요) 한층 더 기재하면, 아무래도 전반적으로, 마우스 오른쪽 클릭으로 내는 부메뉴 전반이, KJ-Eraser가 액티브하게 되어 있으면, 움직임이 이상해지고 있는 가 아닐것인가 라고 하는 기분도(^^; 텍스트의 코피페에 관해서는, Windows의 단축 키를 사용하는 것으로 회피 할 수 있어는 합니다만. 　또한, 「기입의 수정」을 행 왕 했을 때. KJ-Eraser가 무효화되고 있는 경우, 「기기입분 」이 편집 박스에 인용된 다음, 편집을 할 수 있습니다. KJ-Eraser가 유효화 되고 있는 경우, 편집 박스에는 아무것도 텍스트가 없는 상태로의 편집이 됩니다. (정확하게는, 일단 편집 박스에 텍스트가 인용된 뒤, 소거되고 있다) 한층 더 「백그라운드에서 여러 가지 하고 있을까―」라고 하는 화면의 움직임을 볼 수 있어 재편집 모드나 답신에서는 편집할 수 없다(^^; 이것에 대해서는 여러 가지 시험한 결과, 「일단, Fx 이외의 윈도우를 액티브하게 한 뒤, 재차 Fx를 액티브하게 한다」라고, 왠지 편집을 할 수 있는 것을 우연히 발견 w 　확장 기능중에서, 데이터의 초기화를 실시할 때, 부적절한 부분까지를 대상으로 하고 있다, 있다 있어는 초기 처리 그 자체가 다소 이상하다(루프 하고 있어?) 의 것인지인―, (이)라고 할 생각이. 　이쪽의 현상은, 「KJ-Eraser를 무효화」해 회피하는지,　「신규 기입」을 한 다음 구기입을 삭제할까의 2택이 됩니다. 「목적을 달성하는 방법은 있다」의로, 뒷전이라도 좋은 것인지-라고 생각했습니다만, 「마우스 오른쪽 클릭」전반에 영향이 나오고 있는 일을 중요하게 본다면, 우선 순위는 이 쪽이 높을지도, 입니다 m(__) m

7년 전
5 이전 글보기

우물입니다. KJ Eraser의 덕분에, 쾌적한 KJ생활을 보내고 있습니다. 고마운 것입니다, 감사. 그런데. 지나친 수의 바보 바보 행세를 해 아피카스의 탓으로, 필터수가 오버플로우 했는지, 지정해도 반영되지 않게 되어 버렸습니다. 만약 수극 시에 기분이 타면으로 괜찮습니다. 필터 지정의 수를 올려 받을 수 있으면, 더욱 더 행복한 KJ생활을 보낼 수 있는 고 , 부디 검토 부탁드리겠습니다.

7년 전
4 이전 글보기

Ron Zacapa　＜-　조금 옆으로부터. 　아시는 바라고는 생각합니다만, 와일드 카드 지정하면, 등록 유저를 줄일 수 있어요. 예를 들면, Display name * (asterisk 1개) ID gg_* (gg_에 asterisk 1개) 그렇다고 하는 패턴 등록을 해 두는 것만으로, 5, 6개는 등록수를 줄일 수 있습니다. 이 패턴으로 등록해 두면, 표시되는 핸들은 차치하고, ID에 관해서 아이덴티티를 유지하고 싶다고 하는 바보들에게 대해서, 과거 뿐만 아니라 미래에 사용하는 핸들까지 정리해 BAN 할 수 있으므로 추천입니다. 그리고, 졸도 같은 일이 일어나 보고 싶어, 등록 데이터를 줄이면 「도중에 비표시 처리가 스톱」이라고 하는 현상은 없어졌습니다.100개 정도입니까―, 리밋트. 엔브라라면 한시기 500까지 등록 어카운트가 성장했습니다만(w) ※등록 데이터의 백업이 있었으므로 보면, 1000가까운 시일내에 등록되어있었습니다(^^;

7년 전
5 이전 글보기

wiredrunner씨, 들입니다. 부끄럽지만 와일드 카드 지정은 몰랐습니다(′·&#969·`) 그렇지만 덕분에 우선은 전부나 붙일 수 있었습니다. 감사!

7년 전
5 이전 글보기

모처럼 와일드 카드 배웠는데··· 벌써 오버플로우 해 버렸습니다(′·&#969·`)

7년 전
4 이전 글보기

　아마, 만들기로서 「상한치 설정」이 너무 적은 것이라고 생각합니다. 　소프트나씨적으로 말하면,　「그 시점에서 필요한 캐파보다 1자리수상」은 마스트.(예를 들면 취급하는 수가 1000이라면, 10000은 봐 둔다) 　있다 정도 리밋트를 작게 하고 싶다면, 「그 시점에서」판명되어 있는 상한치(결국은 KJ로 기입을 실시하고 있는 인원수)에 대해, 제품 수명까지의 신장율을 실은 수가 됩니다만(^^; 우선 1000의 오더는 필요하다고 생각하기는 하지만요＞상한치

7년 전
3 이전 글보기

오랫동안 방치하고 있어 미안합니다, 이쪽 폐걸치고 있습니다. 코드상은 상한치라고 말하는 것은 가지고 있지 않기 때문에, 순수하게 PG에 버그가 있다인가 브라우저의 스토리지를 다 먹고 있어 의 어느 쪽인가라고 생각합니다. FF와 Opera는 확실히 스토리지의 상한 자체를 취할 수 없기 때문에, 데이터가 오버플로우 해 이상한 기분이 들고 있는지도 알려지지 않습니다. 조금 요정씨에게 확인하는 ^-^

7년 전
3 이전 글보기

랭킹에 대해서는, extension로부터 필터 정보를 던지는 것을 어떻게 시큐어(이용자에게 있어서)로 하는지, 라고 던진 앞의 API를 어떻게 시큐어(시스템에 있어서)로 하는지, 만 해결하면 할 수 있다라고 생각합니다. 단지 개인적으로는 너무 공격적인 용도의 것을 만드는 것은 어떨까라고도 생각하거나＾-＾ 해결법은 보이고 있어 요정씨가 별도이고 진행해 걸치고 있던 것에 관련하므로, 이쪽은 조금 시간을 내주고 싶고.

7년 전
4 이전 글보기

　-.우선 찾아냈으므로. Eraser 버젼：1.23.0.0 Chrome 버젼：75.0.3770.80(64 bit판) Eraser의 표시를 보면, 94284 bytes(aprx.987 users) available와 있다의입니다만, 85 패턴까지 밖에 등록할 수 없습니다. 86 패턴눈을 오른쪽 클릭해 등록 처리를 해도, 리스트에는 실리지 않고. 그리고, 기등록 유저로부터 1 패턴을 삭제하면, 별패턴을 등록 할 수 있습니다만 「삭제한 수」와「신규 등록 패턴」의 수는 항상 같고, 85이상의 등록은 할 수 없는 것 같습니다. (Fx판에서는, 등록 패턴의 리밋트는 아직 찾아내지 않았습니다.135까지는 등록해 보았습니다만, 아직도 천정은 높은 보고 싶다) 덧붙여 이 상태에서는, 각 판의 일람, 및 스렛드 표시로의 BAN 처리는 정상적으로 실시하는 것이 되어있습니다.

7년 전
4 이전 글보기

한층 더. Eraser 버젼：1.23.0.0 Firefox 버젼：67.0.2 　 이쪽은, 등록 유저수에 관해서는 리밋트를 찾아내고 있지 않습니다. 하지만, 등록수가 123을 넘으면, 일람, 있다 있어는 스렛드로 「표시 억제 처리」가 효과가 없게 되어, 일람 있다 있어는 스렛드 표시로 BAN 대상이 표시되어 버립니다. 단지, 이쪽은 표시중의 핸들명(BAN 대상 설정의 유무를 불문하고) 오른쪽 클릭하면［비표시 처리가 콘티 뉴 되었다」인가와 같이, 비표시 설정한 것이 비표시가 됩니다. 이것도, 123 패턴을 넘으면 비표시가 능숙하게 가지 않는다고 하는 현상이 나오지만, 122 이하로 하면, 정상적으로 처리됩니다. 이것도 수수께끼 상태(^^; 덧붙여 씀：　등록수가 58으로 「BAN 처리 일시정지」가 발생. 상기의 기입도, 테스트하면서이므로 실수는 없다고 생각합니다만.... 등록수의 문제가 아니고, BAN 처리 그 자체의 어디엔가 문제가 있다 의 것인지인orz

7년 전
4 이전 글보기

arcticcat ＜어플리케이션 자체에 「등록수상한」이 설정되어 있지 않다고 하면, 내부적인 요소(애드 온(add-on)의 환경 설정, 혹은 동작시키고 있는 PC의 환경 그 자체)인가＞원인 　 Ron Zacapa 씨의 기입의 뉘앙스로부터 추측하면, Ron씨는 chrome계의 브라우저(chrome/opera/vivaldi등 )를 사용되고 있는 것은이라고 생각합니다만,　「더 이상의 등록은 할 수 없다」라고 하는 수는, 어느 정도입니까? 집과 같은가?

7년 전
5 이전 글보기

아―. 이쪽의 환경을 쓰지 않으면 안되겠지요.실례했습니다. wiredrunner씨의 추찰대로, MBP OSX10.11.6　＋　Chrome74.0　입니다.

7년 전
5 이전 글보기

필터수는, 88이 상한이었습니다.

7년 전
3 이전 글보기

FB 감사합니다. 늦어져 죄송합니다만, 이쪽 역시 스토리지 상한이 원인같습니다. 리치한 데이터의 갖게하는 방법을 하고 있었으므로, 장황한 데이터를 깎아 등록수를 늘릴 수 있도록(듯이) 수정한다라는 것입니다. (예를 들면, ID가 와일드 카드 지정되어 있지 않은(=대상이 확정되어 있다) 경우는 표시명은 가지지 않는다) 현상은 지적대로 100건 정도로 가득 찹니다만, 지금 300 정도는 갈 수 있고 있습니다. 좀 더 늘릴 수 있을 것 같은과 수정 범위가 넓기 때문에 만약을 위해 확인하고 나서 내일쯤에 릴리스 하는＾-＾

7년 전
3 이전 글보기

늦어졌습니다만, 요정씨가 v2.0.0.1을 공개한 것 같습니다＾-＾ 버젼대로 대폭적인 수정이 들어가 있으므로, 무엇인가 불편이 있다일지도 모릅니다. &#9312 SETTINGS ⇒ 데이터를 카피해, 만약을 위해 백업 &#9313 MIGRATE ⇒ SAVE 그리고 데이터가 신형식에 변환되어 등록수자체는 증가한다고 생각합니다.

7년 전
4 이전 글보기

　보낼 수 있었습니다만, 2.0.0.1, 확인했습니다. Fx는, 자동 버전 업에 맡기는 형태로 판 올려 해 보았습니다만, 문제 없게 데이터의 변환은 행해진 것 같습니다. 지금부터, 사용 애드 온(add-on)를 바꾸어 테스트해 보겠습니다. 감사합니다 m(__) m

7년 전
4 이전 글보기

　테스트해 보았습니다. 우리 환경만일지도 모릅니다만....좀 여러 가지 일어나고 있는 것 같은 기분이(--; 특히 chrome판으로, 경우에 따라서는빼도 박도 못한 님일이 되어있는 가 아닐것인가 라고 하는 생각이 듭니다. 우선 좀 목욕탕 들어가고 나서, 재차 orz

7년 전
4 이전 글보기

네-와.　보고. 　먼저 Fx판. 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년 전
4 이전 글보기

　한층 더 이제(벌써) 1개.좋은 이야기와 별로 좋지 않은 이야기. 좋은 이야기는, KJ-Eraser　의 대응 브라우저에　Craving Explorer2 https://v2.crav-ing.com/ 하지만 더해진다, 라고 하는 것. 　Craving Explorer의 V1.x계는 IE베이스로 애드 온(add-on) 불가입니다만, V2.x계는 크로미움계 베이스의 브라우저이므로, Google의 웹 스토어로부터 문제 없고 인스톨 가능했습니다. 　좋지 않은 이야기는,　「Craving Explorer　V2.x」에, 접시 상태로부터 KJ-Eraser　V2.0.0.1을 인스톨 해도,　1.2. x로부터 업데이트 했을 때와 같이, Blacklist에 관한 모든 조작이 효과가 없다고, 하는 것. url는 줍고, kj에 액세스 하면 액티브화해, 통상과 같이 등록 처리 그 자체는 조작할 수 있습니다만, 실제로는　「적어도 외관상」등록은 되어 있지 않다는, 상태입니다. 메뉴를 보면, 등록 처리 부분은 만져지고 있는 것 같습니다. 의로, 혹시 크로미움계측에서는, 「데이터를 주운 뒤의, 블랙 리스트에의 등록 처리」부분, 그것도 「 구데이터로부터의 콘버터 처리」라고 공통되고 있는 (곳)중에 실패하고 있을까―, (이)라고 할 생각이(^^;아크마데스이소크데스가

7년 전
4 이전 글보기

이제(벌써) 1개. 아마, DisplayName/ID　(을)를 키로 하는 소트 처리입니다만, 데이터가 null　그렇다고 하는 패턴은 고려하지 않았던 응이 아닐까―, (이)라고 생각합니다. 의로, 이쪽도 「나중에」로 좋기 때문에, 대처를 부탁드리는 m(__) m

7년 전
3 이전 글보기

매번 폐걸치겠습니다 일단 위기인 곳을 수정했습니다＾-＾ &#9312 초기 상태로부터의 유저 추가 불가 이하 FB 받은 사상은, 확인하는 대로 차례차례 수정해 나가는 간다고 합니다 &#9313 소트로 null가 고려되지 않는다 &#9314 편집시에 코멘트란의 내용이 일단 클리어 된다 &#9315 FF에 대해 대상 유저가 도중까지 밖에 비표시가 되지 않는

7년 전
4 이전 글보기

　2.0.0.2, 확인했습니다. chrome/craving explorer　에 짜넣어, 동작을 확인. ·　오른쪽 클릭으로부터의 Blacklist에의 등록 ·　기등록 데이터의 편집과 등록 ·　기등록 데이터의 삭제 ·　모두 수타로의 등록 까지는 확인했습니다. 의로, 등록에 관해서는 문제 없다고 생각합니다. 　Eraser의 윈도우에, 「대체로의 등록 유저의 리밋트」가 나오게 된 것은, 문제가 분리해가 하기 쉬운 「손」이다와 사입니다. 그리고, 기술적으로, 입니다만.... 「Display Name　의 여하에 관련되지 않고, ID의 바리에이션만으로 일괄 BAN」하고 싶은 것이면.... 예를 들면, gg_nnnnnnnnnn(n는 임의의 텍스트)라고 하는 패턴의 ID를 사용하는 유저에 대해 일괄 BAN 하고 싶은 경우, 1.x계라면 Display name：* ID：　gg_* 그리고 등록하고 있었습니다만, 향후는 Display name：블랭크(null) ID：　gg_* 그리고 등록하는 것이 좋을 것 같습니다만, 이 인식으로 OK입니까?

7년 전
3 이전 글보기

확인 감사합니다＾-＾ 지정분에 대해서는 인식대로, 공백 = * (전지정)입니다. 이하에 정리하면 (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년 전
5 이전 글보기

들입니다, 여러 가지 에로 에로 감사합니다. 이런 표시가 나와 등록할 수 없게 되어 버렸습니다가, 장점을 사용할 수 있지 않을까요? 교수 받을 수 있으면 기쁘겠습니다.

7년 전
3 이전 글보기

Ron Zacapa > 어떻게도입니다, 스토리지 용량이 한 잔의 메세지군요. 이하의 순서로 안 된다입니까? &#9312 SETTINGS ⇒ 데이터를 카피해, 만약을 위해(메모장 등에) 백업 &#9313 MIGRATE ⇒ SAVE &#9313그리고 데이터가 신형식에 변환되어 300건 정도까지라면 등록할 수 있게 된다고 생각하는＾-＾

7년 전
4 이전 글보기

피드백이나 리포트는 없습니다만, Ron씨의 문제에 관해서는 Fix로 좋다고 생각합니다. 그것과 Fx로 보고한,　KJ-Eraser가 액티브한 상황으로의 「텍스트 선택 상태로부터의 오른쪽 클릭」문제입니다만, 20.0.0.2로, Chrome에서도 재현할 수 있었습니다.　Opera에서도 확인할 수 있었으므로, Chrome계 전반에서도 일어나고 있다, 라고 봐도 좋은 것 같습니다.

7년 전
4 이전 글보기

새로운 스렛드, 만드는 것이 좋은 것인지.... 그렇다고 하는 것으로, chrome에서도 중절 현상, 확인할 수 있었습니다. chrome　：버젼: 75.0.3770.100(Official Build) (64 비트) KJ-Eraser：버젼：2.0.0.2 KJ-Eraser내 상태 유저 레지스트레이션수：82 MIGRATE로, 등록자 정보는 개정판에 변환제. 6,798 bytes (aprx_399 users) available　그렇다고 하는 표시 있어 현상：Fx판과 외부에서 본 현상은 같다. 　BAN 대상으로 등록되어 있는 유저가, 표시된다. 스렛드의 표시부분을 오른쪽 클릭하면, 일시정지하고 있던 「비표시 처리」가 재가동하고 있었는지와 같이 되어, 비표시 대상 유저의 기입이 사라진다. 　아무래도, Fx특유의 문제가 아니고, 어디라도 일어나는 현상같습니다.

7년 전
3 이전 글보기

사이가 비어 버려 정말로 미안합니다. 최근 여러가지 바쁘고 별로 시간을 잡히지 않게 된 것과 KJ(라고 할까 일본의 포럼) 자체에의 관심 자체가 희미해지고 있어 꽤 손이 내기 힘든 상황입니다. 의견 주신 분들, 특히 wireadrunner씨에게는 수많은 피드백을 받아 정말로 감사합니다^-^ GitHub에 코드는 전부 공개하고 있으므로 유시가 자취를 그 다음에 주면 좋았었지만, 유감스럽지만 그러한 분도 나타날 것 같지 않기 때문에, 일단 그 쪽은 클로우즈 하겠습니다. 현상의 불편에 대해서는 파악하고 있기 때문에, 결정된 시간을 잡히면 고칠지도 모릅니다만, 일단 기대하지 않는 느낌으로 받을 수 있으면과. 처음은 2-3 h로 만들 수 있을 것 같기 때문에 만들까라고 하는 가벼운 김(이)었습니다만, 여기까지 스케일 아웃 한 것은 정직 예상외로 요정씨에게 요망을 모두 수중에 넣을 수 있는 기술력이 없고 정말 미안합니다. 향후의 반성으로 하는 ^-^

6년 전

Chrome, Opera, Firefox add-on for KJCLUB

Chrome, Opera, Firefox add-on for KJCLUB

IT