Greasemonkey: WebExtension 호환성

이 무리에 대해 생각했습니다. 명확한 "결정"은 없지만 몇 가지 사항이 있습니다.

• 우리는 e10s 호환성을 위한 포팅 프로세스를 _그냥_ 마쳤습니다. 우리가 시작할 때 훨씬 더 어려웠습니다. 예를 들어 Services.ppmm와 .cpmm는 좋은 바로가기입니다. 처음부터 의존하는 것이 좋았겠지만 우리가 (책임있게) 시작할 때는 존재하지 않았습니다.
• 그 작업은 길고 매우 고통스러웠고, 나는 그것을 효과적으로 반복하기를 기대하지 않습니다.
• e10s 롤아웃은 Firefox 36 (2014년 9월 기준)에서 Firefox 42 (2015년 9월 현재)로, 또는 최소 9개월 동안 미끄러졌습니다.
• 발표에 따르면 webextensions-only는 최소 1년 또는 2년 남았습니다. 지금부터 2, 3, 4년으로 미끄러질까요?
• 우리가 이것을 할 것이라면, 지금이 완전히 휴식을 취하고 다시 설계해야 할 적기라고 생각합니다.
  
  
  
  • 나는 우리가 결코 잡을 수 없는 많은 문제를 가지고 있지만, 우리는 그들이 가지고 있는 일부도 가지고 있지만 좋은 단위 테스트를 반쯤 가지고 있기를 바랍니다.
  
  
  • 마침내 Android 지원을 추가할 수 있습니까?
  
  
  • 실제로 처음부터 다시 작성할 필요는 없지만 어떤 코드를 유지하고 어떤 코드를 삭제할지 신중하게 생각해야 합니다.
  
  
• 나는 우리가 이렇게 큰 다른 작업을 시작하기 전에 훨씬 더 강력한 Greasemonkey/Mozilla 관계가 형성되기를 정말로 원합니다. 나는 그것을 현실로 만드는 방법에 대한 약한 추측만 가지고 있습니다.
  
  
  
  • 나는 우리가 오늘날 webextensions와 같은 것으로 포팅하기 위한 고문 테스트라고 생각합니다. 수년에 걸쳐 우리는 몇 가지 고급 기능을 구축했습니다. 계획의 일부로 양방향 의사 소통이 아마 많은 도움이 될 것입니다.
  
  

디자인 문서로 시작하는 것은 좋은 생각이 될 것입니다. 본질적으로 우리는 모든 Greasemonkey가 계획되지 않은 유기적으로 재배된 방식이 아닌 좋은 방식을 위한 계획으로 존재하므로 모든 Greasemonkey를 리버스 엔지니어링해야 합니다.

예를 들어 Services.ppmm와 .cpmm는 좋은 바로가기입니다. 처음부터 의존하는 것이 좋았겠지만 우리가 (책임있게) 시작할 때는 존재하지 않았습니다.

나는 아직 WebExtensions를 사용하는 것을 옹호하는 것이 아닙니다. 그들은 GM과 같은 것에 대해 미성숙한 방법입니다.

실제로 처음부터 다시 작성할 필요는 없지만 어떤 코드를 유지하고 어떤 코드를 삭제할지 신중하게 생각해야 합니다.

흠, 글쎄요, 저는 주로 기술 관점에서 그것을 보고 있었습니다. 현재 UI는 공유 크롬 환경에서 XUL 오버레이와 직접 스크립트 실행을 사용합니다.

따라서 HTML로 변환하고 각각을 독립적인 창 컨텍스트에서 실행하고 메시지 전달을 통해서만 통신하는 것이 미래에 일이 어떻게 이루어져야 하는지 보여줍니다.

메시지 관리자는 기본적으로 구현되는 가장 낮은 수준입니다. 더 높은 수준의 추상화는 이를 기반으로 합니다. WebChannel.jsm/BroadcastChannel/MessageChannel/WebExtension 채널 등.

디자인 문서로 시작하는 것은 좋은 생각이 될 것입니다.

GH Wiki가 이에 적합한 장소가 될까요? 협업 작업을 단순화하기 위해 편집 시 알림을 제공합니까?

우리는 대부분 기능/내부 배관 목록과 각각을 깔끔한 방식으로 구현하는 방법이 필요하다고 생각합니다.

이 문제의 주제에 관심이 있으시면 다음을 읽어보십시오.

https://groups.google.com/d/topic/greasemonkey-dev/K6IyDUWnTQc/discussion

감사 해요!

관련있는:

• https://bugzilla.mozilla.org/show_bug.cgi?id=1271553
• https://bugzilla.mozilla.org/show_bug.cgi?id=1334174

https://developer.mozilla.org/en-US/docs/Web/API/File_and_Directory_Entries_API/소개

이것은 매우 흥미로운 API이지만 "이 기능은 비표준이며 표준 트랙에 있지 않습니다." 호환성이 매우 제한적입니다.

모든 기능을 갖춘 Greasemonkey-under-WebExtensions를 설계하려는 최근의 모든 시도(#2483, #2484 참조)는 실망스러웠습니다. 저는 좀 더 진보적인 개발 스타일을 고려하기 시작했습니다. 더 제한된 기능 세트를 선택하고 그 세트만 지원합니다. 조금 유용하게 사용하고 나중에 더 많은 기능을 사용할 수 있는 경로를 찾으시기 바랍니다.

내 3.x 설치를 검사하면 모든 단일 스크립트가 <strong i="6">@grant</strong> none 임을 알 수 있습니다. 27개 중 6개만 @run-at document-start 을 사용하고, 그 중 대부분은 지원되지 않는 경우 최소한 어느 정도 정상적으로 작동합니다. @require 기능은 많이 사용되며 @resource 꽤 많이 사용됩니다.

따라서 먼저 목표로 삼기에 적절한 목표인 것 같습니다. <strong i="12">@grant</strong> none 모드에서 일반 사용자 스크립트를 지원하고 GM_ API는 지원하지 않습니다. 지원 @require . 어떻게든, 아마도 비효율적으로 @resource 를 지원하기를 바랍니다.

(참고로, 계속 잊고 있기 때문에: sourceURL 을 사용하여 오류를 약간 더 읽기 쉽게 만들 계획입니다. 여러 sourceURL이 지원되는지 또는 @require 인수로 sourceMap을 생성해야 하는지(할 수 있습니까?) 확인하십시오.

WebExtension API 외에도 일반 웹 API에 액세스할 수 있으므로 다음과 같습니다.

https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API

? WebExtension에 대한 IndexedDB의 스토리지 제한은 얼마입니까? 이것은 storage.local 보다 훨씬 더 나은 옵션으로 보입니다. 인터페이스가 가장 단순하지는 않지만 스크립트를 서로 분리하고 선택적 읽기를 수행할 수 있는 더 많은 권한을 제공합니다. 제 생각에는. 문서도구도 사용하기 쉽지 않습니다.

https://github.com/mdn/webextensions-examples/pull/171 은 IndexedDB에 대한 귀중한 토론과 예가 있는 것 같습니다.

나는 약간의 진전을 이루었다.

https://github.com/arantius/greasemonkey/tree/webbymonkey (88d53b4c67b7825858405eb2591f27c8487ce413에서)

처음부터 다시 구현합니다. 확인하고 about:debugging 로 이동하여 "임시 추가 기능 로드"를 누르고 루트 위치에서 파일을 선택하십시오. 사용자 스크립트를 설치하고 겨우 실행할 수 있습니다. 아직 다른 기능은 전혀 없습니다. (음, 원숭이 메뉴가 있지만 괜찮아 보이는 것 외에는 아무 것도 하지 않는 빈 가짜입니다.) 이 작은 기능 세트에도 많은 TODO가 코드 주위에 흩어져 있습니다. 이 중 어느 것도 더 많은 기능에 대한 "올바른 경로"인지 여부를 보장할 수 없습니다.

이전 버전의 Tampermonkey와 Violentmonkey는 오픈 소스이므로 WebExtensions가 Chromium Extensions와 유사하기 때문에 해당 코드 중 일부를 여기에서 사용할 수 있습니까?
편집: 사실, 그것을 보면 이전 Tampermonkey와의 라이선스 호환성에 대해 잘 모르겠습니다. 그러나 Violentmonkey는 MIT 라이센스이므로 호환됩니다.

@PorygonZRocks : Violentmonkey가 Greasemonkey가 되다?

코딩에 대한 경험이 많지는 않지만 최소한 구현에 대한 지침이 있을 수 있다고 생각했습니다. 다시 말하지만, 경험이 많지 않거나 지식이 없으므로 틀릴 수 있습니다.

FF56이 다중 프로세스와 호환되지 않는 모든 애드온을 비활성화했기 때문에 기한을 변경해야 할 수도 있습니다.

내 dev 분기를 참조하십시오. 상당히 거칠지만 최소한의 기능입니다. 이 작업이 완료되고 있으며 이 광범위한 문제에서 구체적으로 추적할 것이 없습니다.

@arantius 호기심에 새 코드를 작성하고 있습니까 아니면 이전 코드를 재사용하고 있습니까?

도움이 필요하세요?

예를 들어 "parse-meta-line.js"의 목적은 단순히 메타 데이터를 객체로 구문 분석하는 것뿐입니까?

@arantius 호기심에 새 코드를 작성하고 있습니까 아니면 이전 코드를 재사용하고 있습니까?

대부분 새롭습니다. 도움이 될 때/어디서나 복사합니다. (지금까지는 스크립트 구문 분석이 큰 예입니다.)

도움이 필요하세요?

도움이 될 것입니다. 조정이 어려울 것입니다.

예를 들어 "parse-meta-line.js"의 목적은 단순히 메타 데이터를 객체로 구문 분석하는 것뿐입니까?

한 줄, 그렇습니다.

한 줄, 그렇습니다.
내 말은, 다음 사이의 메타 데이터를 구문 분석하는 것 외에 다른 작업을 수행합니까?

// ==UserScript==
....
// ==/UserScript==

그것이 유일한 목적이라면 많은 코드처럼 보입니다.

네, 그게 하는 일입니다. 생성된 코드입니다. 이 토론을 https://groups.google.com/d/topic/greasemonkey-dev 로 가져

Google 그룹을 사용하지 않습니다 :(
저라면... 아마 다르게 했을 겁니다.

Google 그룹이 더 이상 존재하지 않습니다.

잘못된 링크: https://groups.google.com/forum/#!forum/greasemonkey -dev

이것이 정확한 위치인지 확실하지 않지만 어쨌든 여기에 있습니다. 저에게 별도의 이슈 @arantius를 열길 원하신다면 , 물론입니다.
4.0.0은 기존 스크립트를 마이그레이션해야 하는 것 아닌가요? 알파 3(최신 비베타 버전에서 제공)으로 업데이트했고 더 이상 스크립트가 없다는 것을 알았습니다.

@Phyxion , 3.14를 설치하면 스크립트를 마이그레이션해야 합니다. 설치 후 브라우저를 다시 시작해야 합니다.

그런 다음 4.x를 설치할 때 스크립트가 있어야 합니다. 그렇지 않은 경우 새 문제의 몇 가지 세부적인 재생산 단계가 도움이 될 것입니다.

Greasemonkey 4 알파는 Firefox 57과 호환되지 않습니다.

@erkinalp , 자세히

@Sxderp 글쎄, 내 컴퓨터에서 그것을 재현하는 것은 쉽습니다. 10개의 사용자 스크립트와 함께 3.14가 설치되어 있습니다. AMO로 이동하여 최신 알파를 다운로드하십시오. 요청하면 다시 시작합니다. 그런 다음 설치된 사용자 스크립트가 없다고 말합니다. 이것이 재생산에 얼마나 유용한지 확실하지 않습니다.

아직 테스트하지 않았지만 GM4는 제거 후 구성이 손실 되어야 하고 GM3는

1. Greasemonkey를 완전히 제거
2. Firefox 다시 시작
3. Greasemonkey 3.14 설치(재시작 포함)
4. 적절한 조치를 위해 Firefox를 다시 시작하십시오.
5. Greasemonkey 4 설치(점수)

그게 도움이 되나요?

최상위 수준 await - 즉, 모든 것을 비동기 함수로 래핑하는 것은 미래 구현을 제한하기 때문에 좋은 디자인 선택이 아니라고 생각합니다(예: 샌드박스를 다시 얻거나 es-future 영역을 얻는 경우). 최상위 수준의 대기를 사용할 수 없고 스크립트가... 음... 최상위 수준에서 실행되는 바닐라 JS 실행과 일치하지 않습니다.

@arantius
아직 아무것도 없습니다 :(
BTW는 4.0입니다. https://i.imgur.com/CPuWWKM.png
스크립트를 추가할 버튼이나 아무것도 없습니다.

... 모든 것을 비동기 함수로 래핑 ...

이제 사용할 수 있는 기능을 사용하여 범위 목적으로 함수를 래핑해야 합니다. 나는 그것을 비동기로 만들지 않는 것에 대한 당신의 추론을 구입한다고 생각합니다. (적어도 스크립트 자체에 비동기 래퍼 함수를 ​​추가하는 것은 간단합니다.)

예, 현재 의도적으로 javascript 에서 스크립트 에서 활성화하는 것은 향후 변경에 대한 위험처럼 보입니다. 래퍼가 현재 피할 수 없다는 것을 알고 있지만 나중에는 최상위 수준으로 다시 이동할 수 있기를 바랍니다.

@arantius 왜 반대 투표를 합니까?

@arantius 가 2017년에 댓글을 28. 14:57 CEST :

... 모든 것을 비동기 함수로 래핑 ...

이제 사용할 수 있는 기능을 사용하여 범위 목적으로 함수를 래핑해야 합니다. 나는 그것을 비동기로 만들지 않는 것에 대한 당신의 추론을 구입한다고 생각합니다. (적어도 스크립트 자체에 비동기 래퍼 함수를 ​​추가하는 것은 간단합니다.)

[mozilla 프로필]\storage\default\의 내용을 삭제해 보세요. (백업 후)
그런 다음 다시 시도하십시오.

UserScript 객체에 대해 말하자면, 저는 세 개의 UserScript 클래스를 갖는 디자인 결정을 잘 이해하지 못합니다. 현재 그들은 약간 어리석은 단일 상속 트리를 가지고 있습니다.

또한 RemoteUserScript는 한 번만 사용 되며 id 를

단지 정보를 위해 ...

저는 FF57.0a1을 사용 중이고 레거시 애드온과 GM 3.13을 실행 중입니다.
안타깝게도 최대 버전이 56으로 설정되어 있기 때문에 업데이트(3.14, 3.15)를 받지 못합니다.*

수동설치도 가능하지만..

GM 3.16은 여전히 ​​시작할 때 브라우저를 멈춥니다(DB를 업데이트하고 있는 것 같습니다)