Greasemonkey: 에 정의된 변수에 액세스할 수 없습니다.<script>tags on the actual page.</script>

실제로 Greasemonkey 문제가 아니라 Firefox 콘텐츠 스크립트 문제에 가깝습니다.
https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Content_scripts#Accessing_page_script_objects_from_content_scripts

자신의 window.wrappedJSObject 할당하거나 Greasemonkey가 이미 래핑된 개체를 할당한 unsafeWindow 를 사용하십시오.

@Sxderp "Greasemonkey 문제가 아님"에 대해서는 잘 모르겠습니다. Tampermonkey와 Violentmonkey 모두 문제 없이 바로 이 경우를 처리합니다. 뿐만 아니라 이것은 블로그 게시물에 언급되지 않은 주요 변경 사항입니다.

기존 사용자 스크립트에서 예상대로 작동하고 다른 인기 있는 사용자 스크립트 관리자와 상호 호환되도록 하려면 이 문제를 수정해야 하지 않습니까?

또한 ... 이것이 실제로 문제를 설명합니까? 왜 스크립트가 정지되고 실패한 조회만 발생하지 않습니까?

동결에 대해서는 잘 모르겠습니다. 귀하의 코드를 복사했는데 저를 위해 고정되지 않습니다.

편집: 죄송합니다. '동결' 댓글을 오해했습니다. 나는 Greasemonkey가 더 이상 작동하지 않는다는 것을 의미한다고 생각했습니다. Javascript가 선언 오류 전에 사용에 도달하기 때문에 해당 행에서 '정지'(실행 중지)합니다. 그것은 '치명적인' 것으로 간주되는 것이 확실합니다. 에서와 같이 코드 실행을 계속하지 않습니다.

Violentmonkey 코드를 간략히 살펴보면 <script> 요소 를 생성하여 스크립트를 삽입하는 것처럼 보입니다. tabs.executeScripts() API 메서드를 사용하는 대신.

물론 그것을 사용하는 것 자체의 단점도 있습니다.

그래서... Firefox가 해당 라인에 들어가면 자동으로 실행을 멈춥니다? 오류 메시지 없이? 엄청나게 이상한 일입니다.

어쨌든 기존 사용자 스크립트와의 호환성을 유지하는 것이 목표가 아닌가요? 이것은 틈새 기능이 아닙니다. 결국 페이지의 자체 JavaScript와 인터페이스하는 것은 매우 일반적인 일입니다.

어쨌든 기존 사용자 스크립트와의 호환성을 유지하는 것이 목표가 아닌가요?

당연하지. 우리는 완벽하지 않습니다. 이것은 자유 시간이 너무 많은 자원 봉사자들이 만든 무료 오픈 소스 프로젝트입니다.

이 시점에서 저는 이것을 개선하는 방법에 대한 계획을 가지고 있지만 Mozilla가 안전하게 수행할 수 있는 기능을 구현하기를 기다리고 있습니다. #2549

@arantius 제가 꺼냈을 것 같은데... 죄송합니다.

여기서 유용성보다 보안을 우선시하는 것은 신중한 결정이라고 생각합니다. 상황이 해결될 때까지 스크립트 작성자 측에서 해결 방법으로 무엇을 할 수 있습니까? 내 경우에는 스크립트 상단에서 var $ = window.wrappedJSObject.$; 및 var $= unsafeWindow.$; 를 모두 시도했지만 $(document).ready(...) 를 사용하려고 할 때 또 다른 오류가 발생했습니다. Error: Permission denied to access property Symbol.toStringTag .

오류: Symbol.toStringTag 속성에 대한 액세스 권한이 거부되었습니다.

나는 그것이 window.wrappedJSObject.$ 의 문제라고 생각하지 않지만 오히려 사용자 스크립트에서 개체 리터럴 또는 new 생성자로 만든 다른 개체가 제대로 가져오지 않았습니다. 액세스하려는 범위(아마도 페이지의 창 범위).

위의 링크는 필요한 cloneInto 에 대한 세부 정보를 제공합니다.

아니요, 문제가 window.wrappedJSObject.$ 있다고 확신합니다. 다음은 동일한 오류로 실패합니다.

// ==UserScript==
// <strong i="7">@name</strong>        Variable access test
// <strong i="8">@namespace</strong>   example.com
// ==/UserScript==

var $ = window.wrappedJSObject.$;

$(document).ready(function() {});

그러나 이것은 자동으로 실패합니다.

// ==UserScript==
// <strong i="12">@name</strong>        Variable access test
// <strong i="13">@namespace</strong>   example.com
// ==/UserScript==

var $ = window.wrappedJSObject.$;

$.ready(function() {});

cloneInto 사용해 보았지만 도움이 되지 않습니다. 페이지의 $ 인스턴스를 사용하는 짧은 예제 사용자 스크립트를 제공할 수 있다고 생각하십니까?

아, 그렇다면 해당 기능에 액세스할 수 있는 권한이 없습니다. 그런 다음 exportFunction 를 사용해야 합니다.

// ==UserScript==
// <strong i="7">@name</strong>         ExampleJQuery
// <strong i="8">@version</strong>      1
// <strong i="9">@include</strong>      *
// <strong i="10">@grant</strong>        none
// ==/UserScript==

var unsafeWindow = window.wrappedJSObject;
var $;

// For sanity just return if we don't have the object
if (typeof unsafeWindow.$ === 'undefined') {
  console.log('No jQuery object, returning');
  return;
} else {
  $ = unsafeWindow.$;
}

// Create the function we want to export
function onReady() {
  console.log("I'm ready!");
}
// Export it. Some details on this.
// Argument 1. The function to export
// Argument 2. The scope to export it to. In general this will be window,
//             or some object in the scope. While it is valid to use
//             "window", I prefer to use "unsafeWindow" if I'm exporting
//             into that scope. I find it less confusing.
// Return      This is a reference to exported function. In general you'll
//             assign this to some property of the scope you're exporting
//             into. However, it's not always neccessary. For example, if
//             you're going to use it as a callback (like for .ready())
//             then you don't need to assign it into the exported scope.
//             But if you want it globally (or scopally) accessable then
//             you need to assign it.
let exported_onReady = exportFunction(onReady, unsafeWindow);
// OR
// unsafeWindow.onReady = exportFunction(onReady, unsafeWindow);

$(document).ready(exported_onReady);
// OR
// $(document).ready(unsafeWindow.onReady);

나는 지금 (다른 구성에서) 그 접근 방식을 시도했고, 무엇을 하든 계속 권한 오류가 발생합니다. 이 시점에서 번거롭게 할 가치가 없습니다.

가혹하게 들리지만 이것이 방해가 될 때까지 사람들에게 Tampermonkey를 사용하도록 권장해야 한다고 생각합니다. 현재 구현된 콘텐츠 스크립트는 실제로 사용자 스크립트 사용 사례에 전혀 적합하지 않습니다.

@obskyr에 동의합니다. 사람들에게 tampermonkey를 사용하도록 권장하십시오.

+1, Tampermonkey(https://addons.mozilla.org/en-US/firefox/addon/tampermonkey/)로 이동했으며 모든 스크립트가 거기에서 작동하는 것 같습니다.

+1, Tampermonkey(https://addons.mozilla.org/en-US/firefox/addon/tampermonkey/)로 이동했으며 모든 스크립트가 거기에서 작동하는 것 같습니다.

이것은 단기적으로는 효과가 있을 수 있고 스크립트를 계속 실행하는 데에는 문제가 없지만 장기적으로는 완전한 대체에 의존하는 것은 잘못된 결정일 수 있습니다. 단기적 성공은 근시안적일 수 있습니다... ;-)

나는 TM을 대용으로 사용하지만, 거기에는 몇 가지 문제가 있습니다. 부정할 수 없습니다. 또한 FF Quantum에는 몇 가지 보안 문제가 있을 수 있으므로 작동하지만 단일 솔루션에만 의존해서는 안됩니다...

글쎄, 모든 사람이 Firefox를 사용하는 것은 아니기 때문에 어쨌든 내 스크립트에서 TM을 지원해야 합니다. 그래서 제가 GM과 TM을 지원하기 전에는 지금은 TM일 뿐입니다. 지금까지 문제를 발견하지 못했습니다.