이건 정말 다시 생각해봐야 한다고 생각합니다. VM과 TM 모두 이와 반대로 동작합니다. 스크립트로 이동하면 스크립트 콘텐츠/소스와 설치 버튼이 모두 포함된 페이지가 표시됩니다. 기술적으로 '리디렉션'되는 동안 본질적으로 여전히 사용자 스크립트로 '탐색'합니다. 아마도 이것은 -users 및 -dev 메일링 리스트에 올라와 다른 사람들의 의견을 보아야 합니까?

커뮤니티 토론을 지지합니다.

개인적으로 나는 ~아무도 소스를 리뷰하지 않는다는 의견이므로 이해할 수 없는 대다수를 포함하여 모든 사용자에게 소스를 보여주는 것은 어리석은 일입니다.

그리고: @require 도 있을 때 주요 소스만 검토하는 것은 거의 수행되지 않습니다.

소스 코드를 검토할 수 있는 가능성이 반환되지 않으면 정말 슬플 것입니다. 나는 항상 코드를 훑어보고 더 편안합니다. 그리고 잘 알려진 라이브러리(공식적으로 호스팅되는 jQuery 등)를 가리키지 않는 @require 포함이 있는 경우, 저는 항상 회의적이며 해당 스크립트가 정말로 필요하지 않는 한 일반적으로 설치를 중단합니다(이 경우 @require 의 내용을 훑어

하지만 내가 예외이고 대부분의 사람들이 코드를 보거나 이해하지 못한다고 해도 스크립트 작성자가 설치할 때 소스가 표시된다는 것을 알도록 하는 예방 효과가 있다고 생각합니다.

여전히 소스 코드를 표시하지 않기로 결정한 경우 쉽게 액세스할 수 있는 view-source: 스크립트를 설치할 때 소스 코드를 가리키는 링크를 추가하십시오(또한 @require 스크립트가 포함되는 것이 바람직함).

언급한 바와 같이 저는 검토 능력도 중요하게 생각합니다. 원하는 소수의 사람들을 위해. 소스의 _all_을 검토할 수 있도록 #2567처럼 작동하기를 바랍니다. 설치 후 편집을 클릭하기만 하면 모든 소스 및 텍스트 리소스가 표시됩니다. 원하는 대로 활성화하거나 제거합니다.

여러 네트워크 요청이 필요한 경우 성능에 몇 가지 영향이 있습니다. 특히 3. 와 4. 에는 "유효한 메타블록이 있는 지점까지 다운로드하여 설치 대화 상자를 표시할 수 있습니다."가 있습니다.

파일이 실제 사용자 스크립트가 아니고 유효한 메타블록이 없다고 가정해 보겠습니다. 설치 대화 상자가 표시되지 않습니다. 내가 볼 수있는 유일한 조치는 탐색을 재개하는 것입니다. 탐색이 재개되면 파일을 다시 다운로드해야 합니다. 불필요한 요청(#2830은 onHeadersReceived 에서 현재 수행 중인 작업을 확장하여 이 문제를 해결합니다.

이전에 이 점을 지적한 적이 있으며 고려해야 합니다. 연결이 느리면 어떻게 됩니까? 예를 들어 파일을 다운로드하는 데 10초가 걸린다고 가정해 보겠습니다. GM이 스크립트를 찾아 다운로드를 시도할 때 사용자는 10초 동안 피드백이 없습니다. 실패하고 탐색을 계속하기 위해 브라우저에 전달합니다. 다시 10초 동안 파일을 다운로드하여 표시합니다.

이 문제를 해결할 방법이 없다고 말하지는 않겠습니다. 예를 들어 데이터를 캐시하거나 그런 다음 실제 탐색에서 출력을 덮어쓸 수 있습니다. 그러나 이것이 사용자를 보호하기 위해 불필요한 코드 복잡성을 초래한다고 생각합니다.

또는 어쨌든 설치 대화 상자를 불러오고 스크립트가 아닌 파일을 설치하는 데 실패할 수 있습니다(VM이 이 작업을 수행함). 나는 그 나쁜 UX를 고려할 것입니다.

누군가가 추가 요청 없이 이를 수행하는 깔끔한 방법을 생각해 낼 수 있다면 좋습니다. 그렇지 않으면 _actual_ 혜택 없이는 이 일을 할 수 없습니다. [1]

[1] 잠재적인 이점으로 #2567로 인해 "소스 코드의 _all_을 검토할 수 있는 것"을 언급하셨습니다. 그러나 나는 동의하지 않는다. #2567은 소스 코드를 설치할 때 사용할 수 있는지 여부에 관계 없이 _무관한_ 기능이어야 한다고 생각합니다.

모르겠어요. 다른 주제에 대해서는 약간의 토론을 거친 후에 나올 수 있었습니다. 그러나 이것은 내가 "보이지 않는" 것입니다.

내 관점에서 스크립트가 즉시 표시되는지 여부는 크게 신경 쓰지 않지만 설치를 취소하거나 그리스몽키가 설치되지 않은 경우와 같이 원시 파일을 볼 수 있어야 한다고 생각합니다. 기본적으로 숨겨져 있는지 여부는 중요하지 않지만 설치 대화 상자를 닫고 스크립트로 돌아가는 방법이 중요해 보입니다.

*.user.js 라는 보기를 중단하는 것이 합리적이지 않다고 생각합니다. 이것은 브라우저 기능을 제거하는 것입니다.

나는 사용자 스크립트를 웹 페이지라기보다 확장 기능으로 봅니다. 확장 프로그램도 탐색하지 않습니다. 다운로드/설치하거나 하지 않습니다.

*.user.js라고 불리는 보기를 중단하는 것은 이치에 맞지 않는다고 생각합니다. 이것은 브라우저 기능을 제거하는 것입니다.

또한 비활성화된 경우 탐색을 건드리지 않는 것을 포함하여 이전 버전의 GM과 동일한 작업을 수행합니다. 브라우저에서 이것을 꼭 보고 싶다면 먼저 GM을 끄십시오.

나는 사용자 스크립트를 웹 페이지라기보다 확장 기능으로 봅니다. 확장 프로그램도 탐색하지 않습니다. 다운로드/설치하거나 하지 않습니다.

나는 이 논리에 동의하지 않는다. 확장자는 아카이브된 파일 패키지입니다. 사용자 스크립트는 그렇지 않습니다. @requires 및 @resources 에 대해 주장할 수 있지만 그건 미약하다고 생각합니다. 그들 모두가 그것들을 사용하는 것은 아니며 그들 중 상당수는 단지 일반 텍스트입니다. 원시 텍스트 페이지로 이동할 때 일반적으로 (첨부 파일/다운로드 헤더가 설정되지 않았다고 가정합니다. 저도 짜증나는 부분입니다) 보기 전에 다운로드할 필요가 없습니다.

그것은 또한 GM의 이전 버전처럼 일을 하고 있습니다.

물론입니다. 하지만 이것이 특정 기능에 대해 찬성하거나 반대하는 훌륭한 논거는 아니라고 생각합니다. 이전 버전은 기준선을 제공할 수 있지만 앞으로 모든 것이 새로운 맥락에서 재검토되어야 한다고 생각합니다. 여기에는 코드 복잡성, 주입하거나 주입하지 않는 이점, 장점 등이 포함됩니다.

확장 프로그램도 탐색하지 않습니다. 다운로드/설치하거나 하지 않습니다.

텍스트 파일이 되는 것은 차이를 만듭니다. 예를 들어 github에는 "원시 보기(view raw)" 옵션이 있는데 이 옵션은 이제 깨졌습니다.

비활성화된 경우 탐색을 터치하지 않는 것을 포함합니다.

알아두면 좋은 정보입니다. 나는 이것을 추측했을 수도 있지만 실제로는 분명하지 않습니다. 파일을 보려고 하는데 렌더링이 되지 않아 당황스럽습니다. 어쩌면 우리는 빈 페이지를 표시하는 대신 사용자가 이를 만났을 때 수행할 수 있다는 힌트를 제공할 수 있습니다.

저는 대부분의 사용자에게 최고의 가치를 제공하는 디자인 결정을 내리는 것을 중요하게 생각하므로 입력을 중요하게 생각합니다.

그러나 이것은 내가 발을 딛고 있는 드문 경우일 것입니다. 접근 방식에 대해 토론하지 마십시오. 유효한 사용자 스크립트에 대한 링크가 있고 해당 링크를 클릭하고 설치 대화 상자만 보고 텍스트 파일로 이동하지 않으며 실제로 소스를 보지 않는 동작을 원합니다. 나는 Greasemonkey가 그런 식으로 행동하게 만드는 데 필요한 모든 것을 할 것입니다. 기간.

WebExt 이전에는 http-on-modify-request 를 사용하여 가능한 한 빨리 사용자 스크립트 모양의 요청을 일시 중단했습니다 . 설치 대화 상자를 트리거하고 RemoteScript 작업을 시작하여 새 요청의 모든 부분을 다운로드합니다. 이것이 사용자 스크립트 모양의 URL에서 사용자 스크립트가 아닌 것(예: HTML)을 감지하면 소유한 요청을 취소 하고 ... 무언가가 탐색을 다시 시작할 것입니다(채널을 정확히 재개하는 것으로 생각하지만 나는 그것을 찾을 수 없습니다).

느린 스크립트를 사용하면 처음에는 아무 일도 일어나지 않습니다. ==UserScript== 부분이 로드되면 설치 대화 상자가 나타나고 나머지가 다운로드되면 진행률 표시줄이 채워집니다. 스크립트의 나머지 부분인 리소스에는 다음이 필요합니다. , 등.

서버에 한 번만 연결하여 스크립트를 다운로드할 수 있습니다.

WebExt에서는 물론 모든 API가 다르지만, HEAD에 이미 onHeadersReceived 이벤트를 차단/필터링하는 것이 가장 좋은 방법인 것 같습니다. 아직 연구를 해야 합니다.

유효한 사용자 스크립트에 대한 링크가 있고 해당 링크를 클릭하고 설치 대화 상자만 보고 텍스트 파일로 이동하지 않으며 실제로 소스를 보지 않는 동작을 원합니다. 나는 Greasemonkey가 그런 식으로 행동하게 만드는 데 필요한 모든 것을 할 것입니다.

그러나 이것은 이전 동작에 대한 변경 사항입니다. GM 3.x 설치 대신 소스 보기를 클릭하는 옵션이 있었는데 아무 것도 설치되지 않았지만 스크립트 소스를 표시하는 탭이 있습니다. 거기에서 탭을 설치하거나 닫고 아무 것도 하지 않을 가능성이 있었습니다. 이것은 내가 적어도 다시 보고 싶은 행동일 것입니다. 나에게 항상 소스를 표시할 필요는 없지만 이전 과 같이 무엇이든 설치

이 요청을 하는 이유는 악성 스크립트가 야기할 수 있는 피해를 보았기 때문에 항상 설치하기 전에 소스를 검사합니다. 이것이 바로 자동 자동 업데이트가 사용자에게 새로운 악성 코드를 가져올 수 있기 때문에 문제로 보는 이유입니다.

webRequest 하면 가짜 URL 을 반환하여 로드를 중단하고 브라우저가 제자리에 머물게 할 수 있습니다. 그러나 그렇게 하면 연결이 즉시 중단되고 필터를 사용하여 콘텐츠를 관찰/분석/변경할 수도 없으므로 새 연결을 시작해야 합니다. 우리가 필요한 모든 데이터(요청 메서드, 응답 헤더)를 범위에 포함하고 있으므로 이것이 실제로 사용자 스크립트인지 아닌지에 대해 자신 있게 결정할 수 있기 때문에 이 경우에는 괜찮다고 생각합니다. 요청 주기의 매우 초기에.

나는 .. 무엇이든 설치하기 전에 검사할 수 있는 옵션이 있었습니다 ...

2567

사용자 스크립트처럼 보이지만 그렇지 않은 경우 어떻게 합니까? 예를 들어 느린 로드를 예로 들어 초기 // ==UserScript== 제거하면 됩니다. 3.x에서 열면 설치 대화 상자가 열리지 않고(올바른) 텍스트 내용이 탭/페이지에 기록됩니다. WebEx를 사용하여 백그라운드에서 새 연결을 만드는 경우 페이지에 내용을 쓰는 방법을 알 수 없습니다. 내가 아는 한 백그라운드에서 페이지에 일부 콘텐츠를 쓰는 유일한 직접적인 방법은 스트림 필터를 사용하는 것입니다.

나는 그것을 '해결'하는 몇 가지 방법을 생각할 수 있습니다. 다시 좋은 솔루션이 없습니다. 내용을 반영하는 내용 스크립트에 데이터를 전달합니다(가능해야 한다고 생각합니다). 확장 페이지로 리디렉션하지만 기록이 깨집니다. 또는 스크립트 검사를 무시하도록 설정된 일부 플래그로 FF가 요청을 다시 시작하도록 합니다. 근데 3번째 부탁인데..

뭔가 빠진게 아닐까..

3.x에서 열면 설치 대화 상자가 열리지 않고(올바른) 텍스트 내용이 탭/페이지에 기록됩니다.

아, 이 점을 수정하고 싶습니다. 제가 틀렸습니다. 처음에 테스트할 때 user 오타가 있었습니다.

@Sxderp 는 귀하가 지금까지 기여한 바를 매우 소중하게 생각하며 계속 이어나가기를 바랍니다.

그러나 위에 설명된 내 결정에 대해 좀 더 명확하게 하기 위해: 진행 중인 작업을 정리했습니다. 먼저 관련 없는 작업을 별도의 커밋 으로 옮겼습니다. 남은 것은 파일 이름을 바꾼 다음 +425-491에 불과한 이 큰 커밋 입니다.

Downloader 클래스는 소스에 관계없이 스크립트를 다운로드 및 설치하는 모든 논리를 캡슐화합니다. 입력을 설정하기만 하면 됩니다. 설치를 위한 URL뿐 아니라 기본 스크립트 소스와 필수/리소스 콘텐츠도 이미 알려진 경우(편집 사례의 경우) 누락된 다른 항목을 다운로드합니다(즉, 새 요구 사항에서 편집 /resource) 항상 동일한 형식을 user-script-regstry 전달하여 한 가지 방식으로만 유지합니다. 전체 downloader.js 는 250줄 미만입니다. 결과적으로 백그라운드/컨텐츠 간에 전달되는 메시지가 줄어들고 새 포트가 없습니다.

크고 복잡한 코드를 더 작고 단순한 조각으로 나누는 것이 합리적일 때가 있습니다. 그러나 IMO는 이것이 아닙니다. 우리가 "새" 스크립트를 설치하든, 업데이트하든, 제자리에서 편집하든 상관없이 흐르는 데이터는 동일합니다. 사소한 부분만 변경됩니다(이미 설치된 스크립트의 UUID를 이미 알고 있습니까? 이미 알고 있거나 다운로드해야 합니까?).

이것은 또한 parsedDetails 의 재귀 구조를 해결합니까(문제가 어딘가에 있는데 찾을 시간이 없습니까?)

모르겠어요. 나는 그것을 의심?

이것은 또한 parsedDetails의 재귀 구조를 해결합니까(어딘가에 문제가 있습니다. 찾을 시간이 없습니다)?

#2806 말씀하시는 건가요?