From a065e04d529da1d847b5062a12c46d916408bf32 Mon Sep 17 00:00:00 2001 From: Peter Bengtsson Date: Tue, 8 Dec 2020 21:46:22 -0500 Subject: update based on https://github.com/mdn/yari/issues/2028 --- .../ja/mozilla/add-ons/add-on_debugger/index.html | 66 --- .../mozilla/add-ons/add-on_guidelines/index.html | 129 ----- .../add-ons/add-on_manager/addonauthor/index.html | 31 -- .../add-on_manager/addonscreenshot/index.html | 34 -- .../add-ons/add-on_manager/code_samples/index.html | 75 --- files/ja/mozilla/add-ons/add-on_manager/index.html | 68 --- files/ja/mozilla/add-ons/amo/index.html | 12 - files/ja/mozilla/add-ons/amo/policy/index.html | 26 -- .../index.html | 518 --------------------- .../mozilla/add-ons/firefox_for_android/index.html | 79 ---- .../mozilla/add-ons/overlay_extensions/index.html | 53 --- .../add-ons/sdk/guides/content_scripts/index.html | 484 ------------------- files/ja/mozilla/add-ons/sdk/guides/index.html | 115 ----- files/ja/mozilla/add-ons/sdk/index.html | 99 ---- .../sdk/tutorials/display_a_popup/index.html | 142 ------ .../sdk/tutorials/getting_started/index.html | 167 ------- .../sdk/tutorials/getting_started_(jpm)/index.html | 174 ------- files/ja/mozilla/add-ons/sdk/tutorials/index.html | 146 ------ .../add-ons/sdk/tutorials/installation/index.html | 72 --- .../sdk/tutorials/troubleshooting/index.html | 112 ----- .../ja/mozilla/add-ons/themes/obsolete/index.html | 46 -- .../webextensions/api/bookmarks/export/index.html | 114 ----- .../webextensions/api/bookmarks/import/index.html | 114 ----- 23 files changed, 2876 deletions(-) delete mode 100644 files/ja/mozilla/add-ons/add-on_debugger/index.html delete mode 100644 files/ja/mozilla/add-ons/add-on_guidelines/index.html delete mode 100644 files/ja/mozilla/add-ons/add-on_manager/addonauthor/index.html delete mode 100644 files/ja/mozilla/add-ons/add-on_manager/addonscreenshot/index.html delete mode 100644 files/ja/mozilla/add-ons/add-on_manager/code_samples/index.html delete mode 100644 files/ja/mozilla/add-ons/add-on_manager/index.html delete mode 100644 files/ja/mozilla/add-ons/amo/index.html delete mode 100644 files/ja/mozilla/add-ons/amo/policy/index.html delete mode 100644 files/ja/mozilla/add-ons/creating_custom_firefox_extensions_with_the_mozilla_build_system/index.html delete mode 100644 files/ja/mozilla/add-ons/firefox_for_android/index.html delete mode 100644 files/ja/mozilla/add-ons/overlay_extensions/index.html delete mode 100644 files/ja/mozilla/add-ons/sdk/guides/content_scripts/index.html delete mode 100644 files/ja/mozilla/add-ons/sdk/guides/index.html delete mode 100644 files/ja/mozilla/add-ons/sdk/index.html delete mode 100644 files/ja/mozilla/add-ons/sdk/tutorials/display_a_popup/index.html delete mode 100644 files/ja/mozilla/add-ons/sdk/tutorials/getting_started/index.html delete mode 100644 files/ja/mozilla/add-ons/sdk/tutorials/getting_started_(jpm)/index.html delete mode 100644 files/ja/mozilla/add-ons/sdk/tutorials/index.html delete mode 100644 files/ja/mozilla/add-ons/sdk/tutorials/installation/index.html delete mode 100644 files/ja/mozilla/add-ons/sdk/tutorials/troubleshooting/index.html delete mode 100644 files/ja/mozilla/add-ons/themes/obsolete/index.html delete mode 100644 files/ja/mozilla/add-ons/webextensions/api/bookmarks/export/index.html delete mode 100644 files/ja/mozilla/add-ons/webextensions/api/bookmarks/import/index.html (limited to 'files/ja/mozilla/add-ons') diff --git a/files/ja/mozilla/add-ons/add-on_debugger/index.html b/files/ja/mozilla/add-ons/add-on_debugger/index.html deleted file mode 100644 index e2147f4582..0000000000 --- a/files/ja/mozilla/add-ons/add-on_debugger/index.html +++ /dev/null @@ -1,66 +0,0 @@ ---- -title: アドオンデバッガ -slug: Mozilla/Add-ons/Add-on_Debugger -translation_of: 'https://extensionworkshop.com/documentation/develop/debugging/' ---- -
-

The Add-on Debugger is new in Firefox 31.

-
- -

Starting in Firefox 31, the Add-on Debugger lets you run the JavaScript Debugger in the context of an add-on.

- -

From Firefox 32 onwards you can also use the Console, to see logged messages and evaluate JavaScript in the add-on's context, and Scratchpad, to conveniently evaluate multiline JavaScript in the add-on context and save it to a file.

- -

The Add-on Debugger is only available for restartless and SDK-based add-ons. It's still experimental: if you find bugs, we'd love it if you filed them in Bugzilla.

- -

For a quick introduction to the Add-on Debugger, see this screencast:

- -

{{EmbedYouTube("KU3Xsck7qy0")}}

- -

Opening the Add-on Debugger

- -

To enable the Add-on Debugger you need to check the "Enable chrome and addon debugging" and "Enable remote debugging" settings in Firefox.

- -

To do this, select "Toggle Tools" from the Web Developer menu in Firefox, open the Developer Tools Settings, and check "Enable chrome and addon debugging" and "Enable remote debugging".

- -

Now open the Add-on Manager. Next to the entry for your add-on you will see a button labeled "Debug". Click this button to launch the debugger.

- -

Next you'll see a dialog asking you to accept an incoming connection. Click "OK", and the debugger will start in a separate window. Note that sometimes the debugger window is hidden by the main Firefox window.

- -

{{EmbedYouTube("DvNpUVJcG_E")}}

- -

Using the Add-on Debugger

- -

The Add-on Debugger looks and behaves very much like the Browser Toolbox, except that while the scope of the Browser Toolbox is the whole browser, the Add-on Debugger is focused on a specific add-on. Like the Browser Toolbox, a toolbar along the top lets you switch between a number of different tools. In Firefox 31 there's only one such tool, the JavaScript Debugger, but with Firefox 32 you also get the Console and Scratchpad.

- -

The JavaScript Debugger

- -

This behaves just like the normal JavaScript Debugger, except its scope is the add-on rather than a web page. On the left-hand side it lists JavaScript sources:

- - - -

Content scripts

- -

Content scripts are only listed if they are currently loaded. Also, if you set a breakpoint in a content script, it will not be active for instances of the content script which are loaded after the breakpoint is set.

- -

For example, suppose you have an add-on that attaches a content script to every tab the user loads. The content script adds a click handler to the page. As soon as you open a tab, this content script will be listed in the debugger. If you then set a breakpoint in the content script's click handler, then execution will pause whenever you click the page. But if you open a new tab, there are now two instances of the content script, and the breakpoint will not be enabled for the second instance You'll need to set a new breakpoint now if you want to it work for the second instance.

- -

We're investigating improvements to this in bug 1016046.

- -

The Console

- -

The Console behaves just like the Web Console, but its scope is the add-on rather than the web page.

- -

However, note that it actually runs in the context of the add-on's bootstrap.js, which may not be what you expect if your add-on uses the SDK: you won't see any objects defined in your add-on's main.js, and you won't see require() either. This issue is being tracked as bug 1005193.

- -

You can execute Console statements in the context of main.js while execution is paused inside main.js.

- -

The Scratchpad

- -

The Scratchpad behaves just like the normal Scratchpad, but its scope is the add-on rather than the web page.

- -

Like the Console, the add-on Scratchpad runs in the context of the add-on's bootstrap.js even if the add-on uses the SDK, and as with the Console you can execute Scratchpad code in the context of main.js while execution is paused inside main.js.do

diff --git a/files/ja/mozilla/add-ons/add-on_guidelines/index.html b/files/ja/mozilla/add-ons/add-on_guidelines/index.html deleted file mode 100644 index f86dd2e18c..0000000000 --- a/files/ja/mozilla/add-ons/add-on_guidelines/index.html +++ /dev/null @@ -1,129 +0,0 @@ ---- -title: アドオン ガイドライン -slug: Mozilla/Add-ons/Add-on_guidelines -tags: - - Add-ons - - アドオン -translation_of: 'https://extensionworkshop.com/documentation/publish/add-on-policies/' ---- -
-

この文書はもはや無効です。現在のアドオンポリシー集については、 レビューポリシーの文書 をご覧ください。

-
- -

これらのアドオンガイドラインは、優れたユーザエクスペリエンスを確保する一方で、オープンかつ多様なアドオン開発者のコミュニティの育成をするために作成されました。ホストされている場所に関わらず、すべてのアドオンおよびアドオンの更新に適用されます。同様に、アドオンを使用せずに Firefox の設定をカスタマイズするインストーラにも適用されます。AMO にホストされているアドオンは、追加のポリシー に従う必要があります。

- -

Be Transparent（透明性）

- - - -

Be Respectful to Users（ユーザへの敬意）

- - - -

Be Safe（安全性）

- - - -

Be Stable（安定性）

- - - -

例外

- - - -

他の例外も追加される可能性があります。

- -

実施

- -

上記のガイドラインに従わないアドオンは、その違反の大きさにより、ブロックリスト入りの対象になる可能性があります。「してはならない」「しなければならない」(must) という制限されたガイドラインは特に重要です。これに違反したものは、すなわちブロックリスト入りの対象になります。

- -

Mozilla のアドオンチームは、アドオンの開発者との連絡に最善を尽くし、ブロックする前に、問題修正のために妥当な期間を提供します。アドオンに悪意が見られたり、その開発者と連絡が取れない、応答が無い、または違反を繰り返す場合は、即座にブロックリスト入りになります。

- -

ガイドライン違反は、Bugzilla 経由で報告 してください (Bugzilla の Tech Evangelism > Add-ons カテゴリ)。質問は、#addons IRC チャンネル に投稿できます。

- -

これらのガイドラインは将来変更される可能性があります。すべての更新事項は、 Add-ons ブログ でアナウンスされます。

diff --git a/files/ja/mozilla/add-ons/add-on_manager/addonauthor/index.html b/files/ja/mozilla/add-ons/add-on_manager/addonauthor/index.html deleted file mode 100644 index 03d58b8a15..0000000000 --- a/files/ja/mozilla/add-ons/add-on_manager/addonauthor/index.html +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: AddonAuthor -slug: Mozilla/Add-ons/Add-on_Manager/AddonAuthor -tags: - - Add-on Manager - - Add-ons -translation_of: Mozilla/JavaScript_code_modules/Add-on_Manager/AddonAuthor ---- -

作成者、開発者、貢献者、アドオンの翻訳者を表します。

- - -

属性

- - - - - - - - - - - - - - - - - - -
属性型説明
namestring人名
url {{optional_inline}}stringname 属性で指定した人物の詳細が記載された URL
diff --git a/files/ja/mozilla/add-ons/add-on_manager/addonscreenshot/index.html b/files/ja/mozilla/add-ons/add-on_manager/addonscreenshot/index.html deleted file mode 100644 index b3a81b55e5..0000000000 --- a/files/ja/mozilla/add-ons/add-on_manager/addonscreenshot/index.html +++ /dev/null @@ -1,34 +0,0 @@ ---- -title: AddonScreenshot -slug: Mozilla/Add-ons/Add-on_Manager/AddonScreenshot -tags: - - Add-on Manager - - Add-ons -translation_of: Mozilla/JavaScript_code_modules/Add-on_Manager/AddonScreenshot ---- -

アドオンのスクリーンショット

-

属性

- - - - - - - - - - - - - - - - - - - - - - - -
属性型説明
urlstringスクリーンショットの URL
thumbnailURL {{optional_inline}}stringスクリーンショットのサムネイルの URL
caption {{optional_inline}}stringスクリーンショットのキャプション
diff --git a/files/ja/mozilla/add-ons/add-on_manager/code_samples/index.html b/files/ja/mozilla/add-ons/add-on_manager/code_samples/index.html deleted file mode 100644 index 0cc6c7b6ee..0000000000 --- a/files/ja/mozilla/add-ons/add-on_manager/code_samples/index.html +++ /dev/null @@ -1,75 +0,0 @@ ---- -title: コードの実例 -slug: Mozilla/Add-ons/Add-on_Manager/Code_Samples -tags: - - Add-on Manager - - Add-ons -translation_of: Mozilla/JavaScript_code_modules/Add-on_Manager/Code_Samples ---- -

アドオンが格納されているディレクトリの取得

- -

あなたのアドオンがインストールされているディレクトリを確認する必要がある場合、次の様なトリックを用います。コード中の YOUREXTENSIONID はあなたのアドオンの ID で置き換えてください。

- -
Components.utils.import("resource://gre/modules/AddonManager.jsm");
-
-AddonManager.getAddonByID("YOUREXTENSIONID", function(addon) {
-  var addonLocation = addon.getResourceURI("").QueryInterface(Components.interfaces.{{ Interface( "nsIFileURL" ) }}).file.path;
-});
-
- -

ファイルとバージョン情報へのアクセス

- -
Components.utils.import("resource://gre/modules/AddonManager.jsm");
-
-AddonManager.getAddonByID("my-addon@foo.com", function(addon) {
-  alert("My extension's version is " + addon.version);
-  alert("Did I remember to include that file.txt file in my XPI? " +
-        addon.hasResource("file.txt") ? "YES!" : "No");
-  alert("Let's pretend I did, it's available from the URL " + addon.getResourceURI("file.txt").spec);
-});
-
- -

アドオンの削除

- -
Components.utils.import("resource://gre/modules/AddonManager.jsm");
-
-AddonManager.getAddonByID("youraddon@youraddon.com", function(addon) {
-  addon.uninstall();
-});
-
- -

アドオンの無効化

- -
Components.utils.import("resource://gre/modules/AddonManager.jsm");
-AddonManager.getAddonByID("youraddon@youraddon.com", function(addon) {
-  if (addon.isActive) addon.userDisabled = addon.isActive;
-});
-
- -

アドオンのアンインストールのリスニング

- - -

以下の例では、アドオンのアンインストール時にクリーンアップを実行する profile-before-change メッセージを取得する際に確認することができる変数 "beingUninstalled" を設定しています。

- - -
var beingUninstalled;
-
-let listener = {
-  onUninstalling: function(addon) {
-    if (addon.id == "youraddon@youraddon.com") {
-      beingUninstalled = true;
-    }
-  },
-  onOperationCancelled: function(addon) {
-    if (addon.id == "youraddon@youraddon.com") {
-      beingUninstalled = (addon.pendingOperations & AddonManager.PENDING_UNINSTALL) != 0;
-    }
-  }
-}
-
-try {
-  Components.utils.import("resource://gre/modules/AddonManager.jsm");
-
-  AddonManager.addAddonListener(listener);
-} catch (ex) {}
-
diff --git a/files/ja/mozilla/add-ons/add-on_manager/index.html b/files/ja/mozilla/add-ons/add-on_manager/index.html deleted file mode 100644 index 292d5b739b..0000000000 --- a/files/ja/mozilla/add-ons/add-on_manager/index.html +++ /dev/null @@ -1,68 +0,0 @@ ---- -title: Add-on Manager -slug: Mozilla/Add-ons/Add-on_Manager -tags: - - Add-on Manager - - Add-ons - - NeedsEditorialReview - - NeedsTechnicalReview - - NeedsTranslation - - TopicStub -translation_of: Mozilla/JavaScript_code_modules/Add-on_Manager ---- -

{{ gecko_minversion_header("2.0") }}

- -

The Add-on Manager is responsible for managing all of the add-ons installed in the application. Through its APIs information about all installed add-ons can be retrieved and new add-ons can be installed. The APIs are designed to be generic and support many different types of add-ons.

- -

Many functions in the Add-on Manager interface operate asynchronously returning results through callbacks passed to the functions. The callbacks may be called immediately while the initial function is still executing or shortly after depending on when the requested data becomes available.

- -

Accessing installed add-ons

- -

Information about installed add-ons can be retrieved through the main AddonManager API. All of its functions are asynchronous meaning that a callback function must be passed to receive the Addon instances. The callback may well only be called after the API function returns. For example:

- -
Components.utils.import("resource://gre/modules/AddonManager.jsm");
-
-AddonManager.getAllAddons(function(aAddons) {
-  // Here aAddons is an array of Addon objects
-});
-// This code will execute before the code inside the callback
-
- -

Notifications about changes to installed add-ons are dispatched to any registered AddonListeners. They must be registered through the addAddonListener() method.

- -

Installing new add-ons

- -

New add-ons can be installed by using the getInstallForFile() or getInstallForURL() methods on the AddonManager object. These will pass an AddonInstall instance to the callback which can then be used to install the add-on:

- -
Components.utils.import("resource://gre/modules/AddonManager.jsm");
-
-AddonManager.getInstallForURL("http://www.foo.com/test.xpi", function(aInstall) {
-  // aInstall is an instance of AddonInstall
-  aInstall.install();
-}, "application/x-xpinstall");
-
- -

The progress of AddonInstalls can be monitored using an InstallListener. A listener can be registered either for a specific install using the addListener() method or for all installs using the addInstallListener() method.

- -

Finding updates

- -

Add-ons can be checked for updates using the findUpdates() method. It must be passed an UpdateListener to receive information about compatibility information and new update information. Any available update is returned as an AddonInstall which is ready to be downloaded and installed.

- -

{{ h1_gecko_minversion("Detecting add-on changes", "7.0") }}

- -

You can also get lists of add-ons that, at startup, were changed in various ways. The getStartupChanges() method lets you find out which add-ons were installed, removed, updated, enabled, or disabled at application startup.

- -

For example, to take a look at the add-ons that were disabled at startup:

- -
Components.utils.import("resource://gre/modules/AddonManager.jsm");
-
-let addonIDs = AddonManager.getStartupChanges(AddonManager.STARTUP_CHANGE_DISABLED);
-if (addonIDs.length > 0) {
-  // addonIDs is now an array of the add-on IDs that have been disabled
-alert("Note: " + addonIDs.length + " add-ons have been disabled.");
-}
-
- -

See also

- -

{{ ListSubpages() }}

diff --git a/files/ja/mozilla/add-ons/amo/index.html b/files/ja/mozilla/add-ons/amo/index.html deleted file mode 100644 index 3f6d8b219f..0000000000 --- a/files/ja/mozilla/add-ons/amo/index.html +++ /dev/null @@ -1,12 +0,0 @@ ---- -title: AMO -slug: Mozilla/Add-ons/AMO -translation_of: Mozilla/Add-ons/AMO ---- -

 

- -

addons.mozilla.org をドキュメント化しているページ：

- -

{{Listsubpages("/ja/Add-ons/AMO", 10)}}

- -

 

diff --git a/files/ja/mozilla/add-ons/amo/policy/index.html b/files/ja/mozilla/add-ons/amo/policy/index.html deleted file mode 100644 index ce6a579e34..0000000000 --- a/files/ja/mozilla/add-ons/amo/policy/index.html +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: AMO ポリシー -slug: Mozilla/Add-ons/AMO/Policy -tags: - - AMO - - Add-ons - - Firefox - - Policies -translation_of: Mozilla/Add-ons/AMO/Policy ---- -

{{AddonSidebar}}

- -

Mozilla はユーザーと開発者に対して、すばらしいアドオン体験を保証することにコミットします。アドオンを登録する前に、下記のポリシーを良く読んでください。

- -
-
Firefox アドオン配布契約
-
この契約は、2016年1月5日から有効になります。
-
アドオンポリシー
-
アドオンは Firefox のコア機能を拡張し、ユーザーが Web エクスペリエンスを変更したりパーソナライズしたりできるようにします。信頼に基づいて構築された健全なアドオンエコシステムは、開発者が成功し、ユーザーが Firefox を自分のものにしても安全に感じるために不可欠です。
-
これらの理由から、Mozilla はすべてのアドオンが許容される慣習に関するアドオンポリシーに従うことを要求しています。これらのポリシーは、法的な助言として機能することを意図したものではなく、アドオンのプライバシーポリシーに含める包括的な用語のリストとして機能することも意図していません。
-
Featured Add-ons
-
注目のアドオンがどのように注目されるようになり、そのプロセスに何が関与しているのか。
-
我々に連絡する -

このポリシーやあなたのアドオンに関して連絡を取る方法。

-
-
diff --git a/files/ja/mozilla/add-ons/creating_custom_firefox_extensions_with_the_mozilla_build_system/index.html b/files/ja/mozilla/add-ons/creating_custom_firefox_extensions_with_the_mozilla_build_system/index.html deleted file mode 100644 index 2a8d3507c7..0000000000 --- a/files/ja/mozilla/add-ons/creating_custom_firefox_extensions_with_the_mozilla_build_system/index.html +++ /dev/null @@ -1,518 +0,0 @@ ---- -title: Mozilla ビルドシステムによるカスタム Firefox 拡張機能の作成 -slug: >- - Mozilla/Add-ons/Creating_Custom_Firefox_Extensions_with_the_Mozilla_Build_System -tags: - - Mozilla 開発 - - XPCOM - - アドオン - - ガイド - - ビルドドキュメンテーション - - 拡張機能 -translation_of: >- - Archive/Add-ons/Creating_Custom_Firefox_Extensions_with_the_Mozilla_Build_System ---- -
-

Support for extensions using XUL/XPCOM or the Add-on SDK was removed in Firefox 57, released November 2017. As there is no supported version of Firefox enabling these technologies, this page will be removed by December 2020.

-
- -

{{LegacyAddonsNotice}}{{AddonSidebar}}

- -

Firefox 用の拡張機能を作成するための情報は豊富にあります。しかし現時点でこれら全てのドキュメントは、あなたが XUL または JavaScript のみを用いて拡張機能を作成することを想定しています。複雑な拡張機能を作成するためには、これらを実現するための C++ で作成されたコンポーネントを利用する必要が出てくることでしょう。あなたの作成する拡張機能に C++ によるコンポーネントを含めなければならないケースは次のとおりです。

- - - - - -
Note: Gecko の JIT による最新の JavaScript エンジンと js-ctypes により、より多くの拡張機能は JavaScript のみで記載できます。ネイティブな C++ コードをあなたの拡張機能で利用することを決断する前に、他の選択肢を十分検討してください。バイナリのコンポーネントの場合 Firefox のメジャーリリースの度に再コンパイルが必要となり面倒です。
- -

この記事では上記に記載したような条件の下、大規模で複雑な Firefox 拡張を作成するための開発環境をセットアップする方法について述べます。なお、 Mozilla 用の C++ コンポーネントを作成するために Mozilla をビルドする必要は無く、 Mozilla ビルドシステムを利用すればよいことを強調しておきます。あなたが単に XPCOM コンポーネント等の作成方法について調べているのであれば、本記事の内容はおそらく過剰であり、それよりもこちらのガイドを見るべきでしょう。言い換えると、あなたが個人またはチームでの開発経験者であり、かつ大規模で複雑な拡張機能を作成しようとしているのであれば、本記事に書かれている手法を検討することで、うまく作業を進めることができるでしょう。

- -

メモ: ここでは Firefox でのみこれらの手法の動作確認をしましたが、これらは追加の変更を加えずとも、おそらく大体の Gecko ベースのプラットフォーム (Thunderbird や Seamonkey など) で動作するでしょう。

- -

バンビ、モジラに会う

- -

臆病者の話ではありません。とりわけ最初のステップは、非常に大規模―そう、途方もなく―である Mozilla プロジェクトのビルドの話へと巻き込みます。多くの賢い開発者は、一度はそのビルドに挑戦し、精神異常の瀬戸際を経験してきました。もしあなたが C++ 開発者を経験していないなら、あなたを悩ませたくありませんので、 JavaScript を利用することをおすすめします。

- -

Windows 環境

- -

私はこのガイドを見て初めて Mozilla のビルドを実施しました。なぜかは思い出せませんが、幾度となくスタックしてしまい、これらの一連の事件は最初に思っていたよりも実に長い時間を掛けて終えました。多くの家具が破壊され、髪は殆ど根っこから抜け落ちました。あなたがお探しの高評価の付いた分かりやすいガイドはこちらにあります。几帳面に各ステップを実施していけば、おそらくうまく行くでしょう。あなたがきちんと動作するビルド環境を一度得られたのであれば、ある時点からはおそらく何の努力もせずにビルドできるようになったのでしょう。多分。

- -

その他のプラットフォーム

- -

Linux や MacOS などの他のプラットフォームでは、手順は幾分簡単です。ビルドに必要な全てのツール群は最初から組み込まれ利用可能な状態になっており、したがって、あなたがやるべきことは端末上でいくつかコマンドを実行するのみです。殆どの OS 向けの完全な手順はこちらから参照できます。

- -

プロジェクトの構築

- -

Mozilla には、そのビルド過程へ統合されている大量の複雑な拡張機能が含まれています。したがって、XPCOM コンポーネントの作成や登録、 JAR ファイルやマニフェストのビルド、 Firefox の extension/ ディレクトリへの多数のファイルのインストールなどの全ての問題を解決する必要があります。すなわち、これらの問題を解決することと拡張機能をビルドするための開発環境は、切っても切れない関係であると言えます。

- -

まず最初に、あなたの拡張機能に付けるキャッチーな名前を考えてください。そして、その名前のディレクトリを /mozilla/extensions/ ディレクトリの下に作成します。名前には小文字のみ利用可能です。ビルドツリーの同じ階層には inspector/, reporter/ などの仲間のディレクトリも確認できるはずです。

- -

ビルドを行う前に、 Mozilla ビルドシステムは Makefile.in と呼ばれるメイクファイルのテンプレートを元にしてビルド時に実際に利用するメイクファイルを生成するコンフィギュレーションと呼ばれる処理を実施します。実際のメイクファイルはテンプレートと類似もしくは一致していることがしばしばありますが、動的に生成されたメイクファイルを利用することで得られる柔軟性が、ビルドシステムをより強力にする要素の一つとなっています。

- -

単純な C++ 拡張機能の分析

- -

ここではあなたが C++ または JavaScript の両方から利用可能な XPCOM コンポーネントを記述するために C++ を利用することを想定します。コンポーネントを作成するプロセスは、 Mozilla ビルドシステムを利用した場合、実際のところ比較的簡単です。

- -

最も単純なケースでは、コンポーネントは public/ と src/ の 2 つのサブディレクトリを持つ、単一のメインディレクトリから成ります。メインディレクトリと各サブディレクトリには必ず Makefile.in を含める必要があります (これ以降は単にこれらのファイルをメイクファイルと呼びますが、本当のところは真のメイクファイルを生成するために利用されるファイルであることを忘れないようにしてください) 。このメイクファイルは 2 つのことを宣言します。 1 つ目は、拡張機能の生成先であるサブディレクトリをリスティングしています。そのためビルドシステムは、追加のメイクファイルの検索場所を知る必要があります。 2 つ目は、ビルドシステムに対して新しい拡張機能を作成する方法 (コンポーネントのディレクトリを Firefox のバイナリのあるディレクトリへコピーする、などではなく) を指示します。拡張機能を利用する主な利点は、全てをパッケージングしてそれを他のマシンへインストールできることです。

- -

それでは、以下に基礎的なごく普通の最上位のメイクファイルを示します (拡張機能のメインディレクトリ内にある Makefile.in) 。

- -
DEPTH		= ../..
-topsrcdir	= @top_srcdir@
-srcdir		= @srcdir@
-VPATH		= @srcdir@
-
-include $(DEPTH)/config/autoconf.mk
-
-MODULE = myextension
-
-DIRS		= public src
-
-XPI_NAME		= myextension
-INSTALL_EXTENSION_ID	= myextension@mycompany.com
-XPI_PKGNAME		= myextension
-
-DIST_FILES = install.rdf
-
-include $(topsrcdir)/config/rules.mk
- -

このメイクファイルの主な機能を表現するメイク処理の詳細な記述については こちら から確認できます。 MODULE と XPI_NAME の両方は、あなたの拡張機能の名前に設定します。これは、 XPI と同じ場所 (下記参照) へ全てのファイルを配置するために、全てのプロジェクトのメイクファイルで繰り返し記述しなければなりません。 INSTALL_EXTENSION_ID はあなたの拡張機能のユニークな ID です。これは GUID でもよいですが、上に示したような ID の方がかなり、そして見たときに思い出しやすいです。 XPI_PKGNAME は記述する必要がありませんが、もし配布に適した XPI を利用するならば、この値は自動的に XPI と同じ場所に作成されます (/mozilla/$(MOZ_OBJDIR)/dist/xpi-stage/) 。

- -

全ての拡張機能は、 Firefox に対してインストール方法を指示する install.rdf ファイルを含める必要があります。このファイルは拡張機能のメインディレクトリに配置する必要があり、以下のような見た目をしています。

- -
<?xml version="1.0"?>
-
-<RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
-     xmlns:em="http://www.mozilla.org/2004/em-rdf#">
-  <Description about="urn:mozilla:install-manifest">
-    <em:id>myextension@mycompany.com</em:id>
-    <em:version>0.1</em:version>
-
-    <em:targetApplication>
-      <!-- Firefox -->
-      <Description>
-        <em:id>{ec8030f7-c20a-464f-9b0e-13a3a9e97384}</em:id>
-        <em:minVersion>1.0+</em:minVersion>
-        <em:maxVersion>1.0+</em:maxVersion>
-      </Description>
-    </em:targetApplication>
-
-    <!-- front-end metadata -->
-    <em:name>My First Extension</em:name>
-    <em:description>Just an example.</em:description>
-    <em:creator>allpeers.com</em:creator>
-    <em:homepageURL>http://www.allpeers.com/blog/</em:homepageURL>
-  </Description>
-</RDF>
-
- -

install.rdf ファイルフォーマットの詳細についてはこちらから確認できます。メイクファイルの中で DIST_FILES 変数を指定すると、ファイルを拡張機能のディレクトリと (任意の) XPI ファイルへコピーするよう make へ伝えることができます。

- -

Public Interfaces

- -

The public/ directory contains any interfaces that need to be accessed by other modules. These can be IDL files describing XPCOM interfaces, which are used to generate normal C++ header files for inclusion in your source files. They can also be normal C++ header files that are to be used directly by other modules. The easiest way to accomplish the latter is to use inline implementations for all methods so you don’t have any additional linking dependencies. Otherwise you will have to link statically to your module if you use these public headers in other modules. Personally I would discourage this practice (among other things, static linking means the same code gets loaded more than once into memory, and the code won’t be available from JavaScript or other non-C++ languages) and encourage the use of XPCOM wherever possible.

- -

The makefile in the public/ directory should follow this model:

- -
DEPTH		= ../../..
-topsrcdir	= @top_srcdir@
-srcdir		= @srcdir@
-VPATH		= @srcdir@
-
-include $(DEPTH)/config/autoconf.mk
-
-MODULE		= myextension
-XPIDL_MODULE	= myextension
-
-XPI_NAME = myextension
-
-EXPORTS = \
-  myHeader.h \
-  $(NULL)
-
-XPIDLSRCS = \
-  myIFirstComponent.idl \
-  myISecondComponent.idl \
-  $(NULL)
-
-include $(topsrcdir)/config/rules.mk
-
- -

XPIDL_MODULE is the name of the generated XPT file that contains type information about your IDL interfaces. If you have multiple modules, make absolutely sure that you use a different value for XPIDL_MODULE for each one. Otherwise the first module’s XPT file will be overwritten by the second and you’ll get NS_ERROR_XPC_BAD_IID errors when you try to access its IDL interfaces from your code. The files under EXPORTS are copied directly to the /mozilla/$(MOZ_OBJDIR)/dist/include/ directory and are thus accessible from other modules (the value of MOZ_OBJDIR is defined in /mozilla/.mozconfig). XPIDLSRCS are run through the IDL processor, and the generated C++ headers are copied into the same include directory. In addition, an XPT (type library) file is generated and placed in the components/ subdirectory of your extension.

- -

Source Files

- -

Now it’s time to create the makefile and source files in the src/ subdirectory. If you're implementing interfaces that you've described using IDL, the easiest way to do this is to leave the src/ directory empty and run make on the public/ directory only; this will be explained shortly.

- -

Then open the generated header file for your interface from /mozilla/$(MOZ_OBJDIR)/dist/include/. It contains stubs for the component .H and .CPP files that you can copy and paste into your implementation files. All you have to do is fill in the implementation stubs in the C++ file and you’re good to go.

- -

Here’s an example of the makefile you need to place into your src directory:

- -
DEPTH		= ../../..
-topsrcdir	= @top_srcdir@
-srcdir		= @srcdir@
-VPATH		= @srcdir@
-
-include $(DEPTH)/config/autoconf.mk
-
-IS_COMPONENT = 1
-MODULE = myextension
-LIBRARY_NAME =  myExtension
-USE_STATIC_LIBS = 1
-
-XPI_NAME = myextension
-
-CPPSRCS	= \
-  myFirstComponent.cpp \
-  mySecondComponent.cpp \
-  myExtension.cpp \
-  $(NULL)
-
-include $(topsrcdir)/config/rules.mk
-
-EXTRA_DSO_LDOPTS += \
-  $(MOZ_COMPONENT_LIBS) \
-  $(NSPR_LIBS) \
-  $(NULL)
-
- -

In this example, the first two files contain the implementation of the extension’s two components. The final file, myExtension.cpp, contains the code necessary to register these components, as described in the next section.

- -

Registering Your Components

- -

This article explains how to register XPCOM components in Gecko 2.0 and later.

- -

Building It

- -

As mentioned above, you’ll probably want to build your extension immediately after creating your IDL files in order to generate the C++ stubs for your component implementations. I’m assuming that you’ve already built Firefox successfully. If not, return immediately to the beginning of this article and don’t come back til you have a functioning firefox.exe. Do not pass go. Do not collect $200.

- -

Still here? Okay, now we have to modify your .mozconfig (in the /mozilla/ root directory) so that your extension is built along with Mozilla. Add the following line at the end of the file:

- -
ac_add_options --enable-extensions=default,myextension
-
- -

Now launch make from the Mozilla root:

- -
make -f client.mk build
-
- -

Even if you have an up-to-date Firefox build, you’ll have to wait a while for make to recurse over the entire Mozilla source tree looking for new stuff (on my machine, which is pretty fast, this takes a good 10-15 minutes). Eventually it will reach your extension and generate a bunch of stuff under /mozilla/$(MOZ_OBJDIR)/:

- - - -

A lot of this stuff won’t get created on this first pass since make will gag when it doesn’t find the source files for your components. Don’t worry about this; all you need are the generated header files that contain the C++ implementation stubs. Go back and flesh out the C++ implementation of your components so that the build can complete next time. Remember that you should never, ever modify any of these generated files. Always modify the files used to generate them and rerun make. If you’re changing the generated files directly, you’re probably doing something wrong.

- -

The process of walking the entire Mozilla tree takes a long time. If you already have a Mozilla build, you can avoid this by creating a makefile for your extension directly. Go to the root of your $(MOZ_OBJDIR) and (from a bash-compatible shell) enter:

- -
../build/autoconf/make-makefile extensions/myextension
-
- -

If your $(MOZ_OBJDIR) is located outside your $(TOPSRCDIR), you'll need to do:

- -
$(TOPSRCDIR)/build/autoconf/make-makefile -t $(TOPSRCDIR) extensions/myextension
-
- -

in order for the script to know where your source is (it'll use the extension path you gave it relative to the current dir to figure out where you want your makefiles to go).

- -

This will generate the proper makefile for your extension. Whether you build the whole Mozilla tree or take this shortcut, you can build from now on by going to /mozilla/$(MOZ_OBJDIR)/extensions/myextension/ and typing "make" on the command line. It should build your component without bothering with the rest of Mozilla. If everything works out, you’ll see your XPI file in the XPI staging area. You’ll also see the "exploded" version of the XPI (i.e. the unzipped directory structure) underneath /mozilla/$(MOZ_OBJDIR)/dist/bin/extensions. (If something goes wrong, figure out what, fix it and then come back here and add it to this article.)

- -

To make sure that the build really finished, launch Firefox and check that your extension is listed when you select Tools/Extensions. If you are using Firefox as your regular browser (and if you’re not, why not!?), you might be annoyed by the fact that you have to close regular Firefox before running your custom-built version. If so, try setting the MOZ_NO_REMOTE environment variable to "1" before running the development version of Firefox. You’ll also need to use a different profile for your development version:

- -
firefox -P development
-
- -

Where development is replaced with the name of the extra profile you’ve created. This will let you run both versions of Firefox simultaneously, saving you oodles of time over the course of the build/test cycle.

- -

No Place Like Chrome

- -

Yippee-ki-yay! Now you have an extension that does, well, absolutely nothing. It’s time to do something with those groovy components that you’ve implemented and registered. The simplest way to do this is to write some JavaScript and XUL code. At this point, it would be very helpful to have a bit of experience writing "regular" extensions (i.e. without using custom C++ components). If you’ve never done this, I strongly recommend that you think of a cool idea for something simple that you’ve always wanted to tweak in Firefox and write it. Just displaying a new menu item that opens a "Hello, World!" dialog box would be already be a great exercise to get warmed up with.

- -

Assuming you know how to write XUL/JavaScript extensions, you’re aware that the most important stuff goes in the chrome/ directory of your extension. Well, the fact that you’re also using C++ components doesn’t change that one whit. So now you need to create the normal content/, locale/ and skin/ directories in which to place your chrome files. Personally I like placing these directly under the root directory of my module, but I don’t suppose it makes any difference if you prefer putting them under a chrome/ subdirectory or whatever. Let freedom reign!

- -

Once you’ve written the necessary chrome files (for instance, an overlay that adds a menu item to instantiate and use one of your components), you need to package them up as part of your extension. This is accomplished through the use of a JAR Manifest. For our simple extension example, this file might look something like this:

- -
myextension.jar:
-%  content myextension %content/
-%  locale myextension en-US %locale/en-US/
-%  skin myextension classic/1.0 %skin/classic/
-%  overlay chrome://browser/content/browser.xul chrome://myextension/content/MyExtensionOverlay.xul
-	content/MyExtensionOverlay.js		(content/MyExtensionOverlay.js)
-	content/MyExtensionOverlay.xul		(content/MyExtensionOverlay.xul)
-	locale/en-US/MyExtension.dtd		(locale/en-US/MyExtension.dtd)
-	locale/en-US/MyExtension.properties	(locale/en-US/MyExtension.properties)
-	skin/classic/MyExtension.css		(skin/classic/MyExtension.css)
-
- -

Place this code in a file called jar.mn in the root directory of your extension, making sure that the paths in parentheses point to actual files (when interpreted relative to the root directory). You also have to make one small change to the makefile in the same directory, adding the following line:

- -
USE_EXTENSION_MANIFEST = 1
-
- -

This tells make to create a single manifest file called chrome.manifest instead of creating separate manifests with goofy names for each package.

- -

Now launch make again, and you should see a chrome subdirectory appear in your extension (/mozilla/$(MOZ_OBJDIR)/dist/bin/extensions/myextension@mycompany.com/). Note that the chrome directory contains a JAR (i.e. ZIP) file with all the chrome files listed in jar.mn as well as a complete directory structure mirroring that of the JAR file. The directory structure, however, is empty. Why? I don’t know. Don’t worry about this, the files in the JAR are the ones that are actually used.

- -

Keeping it Complex

- -

If you’re developing a really complex extension with lots of XPCOM components, you’ll probably want to divide your code up into smaller modules.

- -
Kinda, Sorta Complex Extensions
- -

For a moderately complex extension, it’s probably enough just to subdivide the code into a single level of modules. Let’s assume that you have a base/ module that defines a bunch of basic XPCOM components and an advanced/ module that defines some chrome as well as other components that use the basic components. Your complete directory structure will look something like this:

- - - -

Other than that, nothing really changes. The makefiles in the base/ and advanced/ directories should look more or less like your original root makefile, remembering to change the DEPTH variable to account for the fact that they’ve moved a level further away from the Mozilla root. You also need to remove the DIST_FILES variable since that’s going to be in the top-level makefile. Every makefile that generates anything should define the XPI_NAME variable to make sure generated files go into your extension and not into the global components/ directory. In fact, just define this in every makefile to be safe. You can use the same MODULE in both base/ and advanced/ so that all the generated include files go into the same directory, but make sure that you don’t use the same XPIDL_MODULE in the two public/ directories or one of the component type libraries (i.e. XPT files) will overwrite the other one and all hell will break loose.

- -

Each module must also have a different value for the LIBRARY_NAME variable. This is the name of the generated dynamic library, so if we call the libraries "myBase" and "myAdvanced", we’ll end up with myBase.dll and myAdvanced.dll (on Windows, at least). And each of these modules is going to have a separate C++ file for registering components. So there will be two files that look like myExtension.cpp in the original example, say Base.cpp and Advanced.cpp. Finally, each module will obviously have its own jar.mn, though they can reference the same JAR filename and package name if you want all the chrome files to be organized in a single JAR file and package. The only file that really stays put is install.rdf, which still exists once and only once in the extension root directory.

- -

As for the top-level makefile, it will now look like this:

- -
DEPTH		= ../..
-topsrcdir	= @top_srcdir@
-srcdir		= @srcdir@
-VPATH		= @srcdir@
-
-include $(DEPTH)/config/autoconf.mk
-
-MODULE = myextension
-
-DIRS		= base advanced
-
-XPI_NAME               = myextension
-INSTALL_EXTENSION_ID   = myextension@mycompany.com
-XPI_PKGNAME		= myextension
-
-DIST_FILES = install.rdf
-
-include $(topsrcdir)/config/rules.mk
-
- -
Seriously Complex Extensions
- -

At some point, even a single module may grow to the point where you want to divide it further into submodules. The difference between having separate modules and having a single module with separate submodules is that the submodules all share the same file for registering components (the famous myExtension.cpp file), and when compiled they create a single dynamic library. The decision to split a module into submodules is all about code organization; it doesn’t really affect the final product at all.

- -

To split a module into submodules, first create a subdirectory for each submodule. Then create an additional directory called build/. Each submodule will be configured to create a static library, and the build/ directory will pull these libraries together to create a single dynamic component library. Confused? Here’s an example, showing just the advanced/ subbranch of the myextension/ directory:

- - - -

As you can see, we’ve split advanced/ into two submodules: intricate/ and multifarious/, and we’ve added an additional build/ subdirectory. We’ve left the chrome directories directly under advanced/, since they aren’t tied to any specific submodule. This means that jar.mn will stay in the same place.

- -

The intricate/ and multifarious/ makefiles will look a lot like the original advanced/ makefile, but we’ll need to tweak them a bit. As always, we have to adjust the DEPTH variable since the makefiles are deeper in the directory structure. And we should change the LIBRARY_NAME to indicate that we’re generating a static library for each submodule. By convention the "_s" suffix is used for this purpose. So let’s call them "myIntricate_s" and "myMultifarious_s". Finally, we define the variable FORCE_STATIC_LIB, resulting in a makefile that starts something like this:

- -
DEPTH		= ../../../../..
-topsrcdir	= @top_srcdir@
-srcdir		= @srcdir@
-VPATH		= @srcdir@
-
-include $(DEPTH)/config/autoconf.mk
-
-MODULE = myextension
-LIBRARY_NAME = myIntricate_s
-FORCE_STATIC_LIB = 1
-USE_STATIC_LIBS = 1
-
-XPI_NAME = myextension
-
-...more stuff here...
-
- -

The build makefile pulls together the static libraries generated by the submodules and creates a single (dynamic) component library:

- -
DEPTH		= ../../../..
-topsrcdir	= @top_srcdir@
-srcdir		= @srcdir@
-VPATH		= @srcdir@
-
-include $(DEPTH)/config/autoconf.mk
-
-IS_COMPONENT = 1
-MODULE = myextension
-LIBRARY_NAME = myAdvanced
-USE_STATIC_LIBS = 1
-
-XPI_NAME = myextension
-
-DEFINES += XPCOM_GLUE
-
-SHARED_LIBRARY_LIBS = \
-		$(DIST)/lib/$(LIB_PREFIX)myIntricate_s.$(LIB_SUFFIX) \
-		$(DIST)/lib/$(LIB_PREFIX)myMultifarious_s.$(LIB_SUFFIX) \
-                $(DIST)/lib/$(LIB_PREFIX)xpcomglue_s.$(LIB_SUFFIX) \
-                $(DIST)/lib/$(LIB_PREFIX)xul.$(LIB_SUFFIX) \
-                $(DIST)/lib/$(LIB_PREFIX)nss3.$(LIB_SUFFIX) \
-		$(NULL)
-
-CPPSRCS		= \
-		Advanced.cpp \
-		$(NULL)
-
-include $(topsrcdir)/config/rules.mk
-
-LOCAL_INCLUDES += \
-        -I$(srcdir)/../intricate/src \
-        -I$(srcdir)/../multifarious/src \
-        $(NULL)
-
- -

The makefile in the advanced/ directory should list the intricate/, multifarious/ and build/ directories in its DIRS variable. Make sure that build/ comes last since it can’t create the component library until the other makefiles have completed.

- -

Other Topics

- -

Adding Data Files to Your Extensions

- -

In some cases, you may wish to include additional files in your extension that don’t belong in the chrome/ subdirectory. Examples might be database files or XML schemas. This can be achieved by adding a custom step to your makefile that copies the files from the source tree into the extension’s target directory.

- -
Copying Data Files Into Target Directory
- -

Let’s say that you have some data files containing statistical information that you want to include in your extension and make available to your components. You’ve placed these files, which have the extension .TXT, into a stats/ subdirectory under your extension directory in the source tree. The following makefile rule can be used to copy these files into the final target directory of the extension:

- -
export::
-	if test ! -d $(FINAL_TARGET)/stats; then \
-		$(NSINSTALL) -D $(FINAL_TARGET)/stats; \
-	fi
-	$(INSTALL) $(srcdir)/*.txt $(FINAL_TARGET)/stats
-
- -
Accessing Data Files From Components
- -

The trick to accessing your data files is to figure out where the home directory of your extension is. Rumor has it that at some future date, this will possible through the nsIExtensionManager interface or something similar. In the meantime, there is a simple and reliable hack that can be used to achieve this. In the implementation of any JavaScript XPCOM component, there is a special __LOCATION__ (two leading and two trailing underscores) symbol that points to the component’s implementation file. So you can write a simple component which deduces the root directory of your extensions by extrapolating from its location.

- -

This article explains how to create an XPCOM component in JavaScript. You’ll need an IDL file for an interface that looks something like this:

- -
interface myILocation : nsISupports
-{
-    readonly attribute nsIFile locationFile;
-};
-
- -

Place the IDL file in the public/ directory of your project or subproject. In the src/ directory, place the JavaScript file that implements the component. The component implementation will include the methods for retrieving the path or file for the extension’s home directory:

- -
myLocation.prototype =
-{
-  QueryInterface: function(iid)
-  {
-    if (iid.equals(nsISupports))
-      return this;
-    if (iid.equals(myILocation))
-      return this;
-
-    Components.returnCode = Components.results.NS_ERROR_NO_INTERFACE;
-    return null;
-  },
-
-  get locationFile()
-  {
-     return __LOCATION__.parent.parent;
-  }
-}
-
- -

This assumes that the component resides in a subdirectory of the extension directory (by convention, this directory is called components/). The parent property of __LOCATION__ returns the components/, and the parent of this is the extension directory.

- -

The last step is to modify the makefile of the source directory where you placed your JavaScript file so that it is copied into the appropriate location in the extension:

- -
export::
-	$(INSTALL) $(srcdir)/*.js $(FINAL_TARGET)/components
-
- -

Now you can instantiate an instance of this component and use the locationFile property to get an nsIFile interface that points to your extension’s home directory.

- -

Using Third-Party Libraries

- -

For more sophisticated extensions, you may want to integrate third-party libraries that provide specialized functionality for database connectivity, image processing, networking and the like. If you want your extension to run on all Firefox platforms, you will need to have the source code for the library in question, so I assume that this is available.

- -

The most convenient approach from the perspective of the development cycle is to create a Mozilla-style makefile for the library. This works well for libraries that have a straightforward make process without extensive configuration. A good example of this is the SQLite library included in the Mozilla build tree at db/sqlite. By adapting the makefile in this way, the library is created as part of the standard Mozilla build process, which eliminates additional build steps. The downside is that you will need to update the modified makefile any time a new version of the library is released.

- -

For libraries that have complex configuration processes, use a non-standard compiler or have other special characteristics, it may be unfeasible to create a Mozilla-compliant makefile. In this case, I would recommend placing the entire library distribution inside the project or subproject that uses it. So if library acmelib is used inside the multifarious/ subproject in the above example, it would be placed as a subdirectory underneath that subproject (at the same level as public/ and src/).

- -

Of course, this means that you will have to build acmelib manually on all platforms before launching the Mozilla build. But at least you can then refer to include files and import libraries from your component using relative paths.

- -

Building for Multiple Platforms

- -

TODO

- -
-

Original Document Information

- - -
- -

 

diff --git a/files/ja/mozilla/add-ons/firefox_for_android/index.html b/files/ja/mozilla/add-ons/firefox_for_android/index.html deleted file mode 100644 index 9adfb1d464..0000000000 --- a/files/ja/mozilla/add-ons/firefox_for_android/index.html +++ /dev/null @@ -1,79 +0,0 @@ ---- -title: Android用Firefoxのアドオン -slug: Mozilla/Add-ons/Firefox_for_Android -translation_of: Archive/Add-ons/Legacy_Firefox_for_Android ---- -

{{LegacyAddonsNotice}}{{AddonSidebar}}

- -
-

このページと、そのサブページは、古い技術を使った Android 用 Firefox のアドオン開発の方法を記しています。この技術は Firefox 57 で動作が停止します。 Android 用 Firefox のアドオン開発するのに WebExtensions を使用可能です。

-
- -

既にデスクトップ版のFirefoxで動いているアドオンは修正を加えないとAndroid版で動かないので注意してください

- - - -

以下の記事はAndroid用のFirefoxの拡張機能を開発する手助けになります。加えてすべてのMozilla アプリケーションに適用できる general extension documentation も参照してください。

- -
-
-

チュートリアル

- -
-
事前準備
-
アドオンを書いてデバイスに送り、直接つながっているデバイスでテストするための、あなたのデスクトップ側の設定です。
-
WebIDEを使用してAndroid用Firefoxアドオンをデバッグする
-
前提条件のチュートリアルからの記事です。アドオンのデバッグやスニペットテストはWebIDEなしでは不可能です。
-
Walkthrough
-
Android用のFirefoxのシンプルなアドオンを開発し、パッケージ化して、インストールします。
-
Firefox Hub Walkthrough
-
Android用のFirefoxのホームページにコンテンツを加えるFirefox Hubアドオンをどのようにして開発するかの解説です。
-
Add-on SDK
-
Add-on SDKを使用したAndroid用のFirefoxのアドオンを開発する方法です。
-
- -

サンプルコード

- -
-
 
-
Code Snippets
-
一般的なタスクのためのコードサンプル。
-
初期化とクリーンアップ
-
アドオンを開始時に初期化したり、シャットダウン時にクリーンアップする方法の解説です。
-
Firefox for Android Add-ons Github Repo
-
Android用Firefoxのアドオンを作成する手助けとなる、JS モジュールやサンプルコード、ボイラープレートリポジトリのコレクションです。
-
-
- -
-

API リファレンス

- -
-
NativeWindow
-
ネイティブ Androidの UI widgetを作成します。
-
BrowserApp
-
ブラウザーのタブとその内容にアクセスします。
-
Prompt.jsm
-
ネイティブ Android の dialog を表示します。
-
HelperApps.jsm
-
システムにインストールされているネイティブアプリを照会して起動します。
-
Notifications.jsm
-
Android システム通知用の拡張プロパティを使います。
-
Home.jsm
-
ホームページをカスタマイズします。
-
HomeProvider.jsm
-
ホームページに表示するデータを保存します。
-
PageActions.jsm
-
URLバーにページ固有のアクションを表示します。
-
JNI.jsm
-
アドオンからネイティブ Java Android API をタップします。
-
Sound.jsm
-
ブラウザーから簡単に音を鳴らします。
-
-
-
diff --git a/files/ja/mozilla/add-ons/overlay_extensions/index.html b/files/ja/mozilla/add-ons/overlay_extensions/index.html deleted file mode 100644 index 1598fd8ca3..0000000000 --- a/files/ja/mozilla/add-ons/overlay_extensions/index.html +++ /dev/null @@ -1,53 +0,0 @@ ---- -title: Legacyアドオン -slug: Mozilla/Add-ons/Overlay_Extensions -translation_of: Archive/Add-ons/Overlay_Extensions ---- -

{{AddonSidebar}}

- -

このページは下記の機能を使っているGecko-baseのアプリケーションのアドオンを開発するための方法のドキュメントへのリンクです。

- - - -

Prior to Firefox 4, and the Gecko 2 engine that powers it, this was the only way to develop extensions. This methodology has largely been superseded by restartless extensions, and the Add-on SDK, which is built on top of them. The privileged JavaScript APIs described here can still be used in these newer types of add-ons.

- -

XUL School

- -

XUL Schoolは体系的なアドオン開発のチュートリアルです。これはfirefoxアドオン開発のチュートリアルですが、他のおおよそのGecko-baseのアプリケーションに応用できます。

- -

その他の情報

- -
-
-
-
Setting up your environment
-
拡張機能を開発するための環境設定です。
-
XUL
-
XUL extensionを使ったユーザーインターフェースを記述するチュートリアルとリファレンスです。
-
Code snippets
-
Sample code for many of the things you'll want to do.
-
Installing extensions
-
How to install an extension by copying the extension files into the application's install directory.
-
Firefox add-ons developer guide
-
オーバーレイextension(bootstrap extensionかな？)の開発ガイドです。
-
-
- -
-
-
JavaScript code modules
-
アドオン開発者の使用できるJavaScript モジュールです。
-
Extension preferences
-
How to specify the preferences for your extension that will appear in the Add-ons Manager.
-
Extension packaging
-
アドオンのパッケージングとインストールの方法です。
-
Binary Firefox extensions
-
Firefoxのバイナリ拡張を作成します。
-
-
-
- -

 

diff --git a/files/ja/mozilla/add-ons/sdk/guides/content_scripts/index.html b/files/ja/mozilla/add-ons/sdk/guides/content_scripts/index.html deleted file mode 100644 index 071cf1fb6f..0000000000 --- a/files/ja/mozilla/add-ons/sdk/guides/content_scripts/index.html +++ /dev/null @@ -1,484 +0,0 @@ ---- -title: Content Scripts -slug: Mozilla/Add-ons/SDK/Guides/Content_Scripts -translation_of: Archive/Add-ons/Add-on_SDK/Guides/Content_Scripts ---- -
-

アドオンの多くはウェブページへアクセスし修正する必要があります。しかしアドオンのメインのコードは直接ウェブコンテンツにアクセスできません。 代わりにアドオン SDK は content scripts と呼ばれる別のスクリプトからウェブコンテンツにアクセスします。このページでは content scripts の開発・実装方法を記述します。

- -

SDK を扱う上で content scripts はあなたを混乱させてしまうかもしれませんが、おそらくそれを使わなければなりません。下記は５つの基本原則です:

- - - -

This complete add-on illustrates all of these principles. Its "main.js" attaches a content script to the current tab using the tabs module. In this case the content script is passed in as a string. The content script simply replaces the content of the page:

- -
// main.js
-var tabs = require("sdk/tabs");
-var contentScriptString = 'document.body.innerHTML = "<h1>this page has been eaten</h1>";'
-
-tabs.activeTab.attach({
-  contentScript: contentScriptString
-});
- -

The following high-level SDK modules can use content scripts to modify web pages:

- - - -

Additionally, some SDK user interface components - panel, sidebar, frame - are specified using HTML, and use separate scripts to interact with this content. In many ways these are like content scripts, but they're not the focus of this article. To learn about how to interact with the content for a given user interface module, please see the module-specific documentation: panel, sidebar, frame.

- -

Almost all the examples presented in this guide are available as complete, but minimal, add-ons in the addon-sdk-content-scripts repository on GitHub.

- -

Loading content scripts

- -
-

You can load a single script by assigning a string to either the contentScript or the contentScriptFile option. The contentScript option treats the string itself as a script:

- -
// main.js
-
-var pageMod = require("sdk/page-mod");
-var contentScriptValue = 'document.body.innerHTML = ' +
-                         ' "<h1>Page matches ruleset</h1>";';
-
-pageMod.PageMod({
-  include: "*.mozilla.org",
-  contentScript: contentScriptValue
-});
- -

The contentScriptFile option treats the string as a resource:// URL pointing to a script file stored in your add-on's data directory. jpm doesn't make a "data" directory by default, so you must add it and put your content scripts in there.

- -

This add-on supplies a URL pointing to the file "content-script.js", located in the data subdirectory under the add-on's root directory:

- -
// main.js
-
-var data = require("sdk/self").data;
-var pageMod = require("sdk/page-mod");
-
-pageMod.PageMod({
-  include: "*.mozilla.org",
-  contentScriptFile: data.url("content-script.js")
-});
- -
// content-script.js
-
-document.body.innerHTML = "<h1>Page matches ruleset</h1>";
- -
-

From Firefox 34 onwards, you can use "./content-script.js" as an alias for self.data.url("content-script.js"). So you can rewrite the above main.js code like this:

- -
var pageMod = require("sdk/page-mod");
-
-pageMod.PageMod({
-  include: "*.mozilla.org",
-  contentScriptFile: "./content-script.js"
-});
-
-
- -
-

Unless your content script is extremely simple and consists only of a static string, don't use contentScript: if you do, you may have problems getting your add-on approved on AMO.

- -

Instead, keep the script in a separate file and load it using contentScriptFile. This makes your code easier to maintain, secure, debug and review.

-
- -

You can load multiple scripts by passing an array of strings to either contentScript or contentScriptFile:

- -
// main.js
-
-var tabs = require("sdk/tabs");
-
-tabs.on('ready', function(tab) {
-  tab.attach({
-      contentScript: ['document.body.style.border = "5px solid red";', 'window.alert("hi");']
-  });
-});
-
- -
// main.js
-
-var data = require("sdk/self").data;
-var pageMod = require("sdk/page-mod");
-
-pageMod.PageMod({
-  include: "*.mozilla.org",
-  contentScriptFile: [data.url("jquery.min.js"), data.url("my-content-script.js")]
-});
- -

If you do this, the scripts can interact directly with each other, just like scripts loaded by the same web page.

- -

You can also use contentScript and contentScriptFile together. If you do this, scripts specified using contentScriptFile are loaded before those specified using contentScript. This enables you to load a JavaScript library like jQuery by URL, then pass in a simple script inline that can use jQuery:

- -
// main.js
-
-var data = require("sdk/self").data;
-var pageMod = require("sdk/page-mod");
-
-var contentScriptString = '$("body").html("<h1>Page matches ruleset</h1>");';
-
-pageMod.PageMod({
-  include: "*.mozilla.org",
-  contentScript: contentScriptString,
-  contentScriptFile: data.url("jquery.js")
-});
- -
-

Unless your content script is extremely simple and consists only of a static string, don't use contentScript: if you do, you may have problems getting your add-on approved on AMO.

- -

Instead, keep the script in a separate file and load it using contentScriptFile. This makes your code easier to maintain, secure, debug and review.

-
- -

Controlling when to attach the script

- -

The contentScriptWhen option specifies when the content script(s) should be loaded. It takes one of:

- -
    -
  • "start": load the scripts immediately after the document element for the page is inserted into the DOM. At this point the DOM content hasn't been loaded yet, so the script won't be able to interact with it.
    • -
  • "ready": load the scripts after the DOM for the page has been loaded: that is, at the point the DOMContentLoaded event fires. At this point, content scripts are able to interact with the DOM content, but externally-referenced stylesheets and images may not have finished loading.
    • -
  • "end": load the scripts after all content (DOM, JS, CSS, images) for the page has been loaded, at the time the window.onload event fires.
    • -
- -

The default value is "end".

- -

Note that tab.attach() doesn't accept contentScriptWhen, because it's generally called after the page has loaded.

- -

Passing configuration options

- -

The contentScriptOptions is a JSON object that is exposed to content scripts as a read-only value under the self.options property:

- -
// main.js
-
-var tabs = require("sdk/tabs");
-
-tabs.on('ready', function(tab) {
-  tab.attach({
-      contentScript: 'window.alert(self.options.message);',
-      contentScriptOptions: {"message" : "hello world"}
-  });
-});
- -

Any kind of jsonable value (object, array, string, etc.) can be used here.

- -

Accessing the DOM

- -

Content scripts can access the DOM of a page, of course, just like any scripts that the page has loaded (page scripts). But content scripts are insulated from page scripts:

- -
    -
  • content scripts don't see any JavaScript objects added to the page by page scripts
    • -
  • if a page script has redefined the behavior of some DOM object, the content script sees the original behavior.
    • -
- -

The same applies in reverse: page scripts can't see JavaScript objects added by content scripts.

- -

For example, consider a page that adds a variable foo to the window object using a page script:

- -
<!DOCTYPE html">
-<html>
-  <head>
-    <script>
-    window.foo = "hello from page script"
-    </script>
-  </head>
-</html>
- -

Another script loaded into the page after this script will be able to access foo. But a content script will not:

- -
// main.js
-
-var tabs = require("sdk/tabs");
-var mod = require("sdk/page-mod");
-var self = require("sdk/self");
-
-var pageUrl = self.data.url("page.html")
-
-var pageMod = mod.PageMod({
-  include: pageUrl,
-  contentScript: "console.log(window.foo);"
-})
-
-tabs.open(pageUrl);
- -
console.log: my-addon: null
-
- -

There are good reasons for this insulation. First, it means that content scripts don't leak objects to web pages, potentially opening up security holes. Second, it means that content scripts can create objects without worrying about whether they might clash with objects added by page scripts.

- -

This insulation means that, for example, if a web page loads the jQuery library, then the content script won't be able to see the jQuery object added by the library - but the content script can add its own jQuery object, and it won't clash with the page script's version.

- -

Interacting with page scripts

- -

Usually the insulation between content scripts and page scripts is what you want. But sometimes you might want to interact with page scripts: you might want to share objects between content scripts and page scripts or to send messages between them. If you need to do this, read about interacting with page scripts.

- -

Event listeners

- -

You can listen for DOM events in a content script just as you can in a normal page script, but there are two important differences:

- -

First, if you define an event listener by passing it as a string into setAttribute(), then the listener is evaluated in the page's context, so it will not have access to any variables defined in the content script.

- -

For example, this content script will fail with the error "theMessage is not defined":

- -
var theMessage = "Hello from content script!";
-anElement.setAttribute("onclick", "alert(theMessage);");
- -

Second, if you define an event listener by direct assignment to a global event handler like onclick, then the assignment might be overridden by the page. For example, here's an add-on that tries to add a click handler by assignment to window.onclick:

- -
var myScript = "window.onclick = function() {" +
-               "  console.log('unsafewindow.onclick: ' + window.document.title);" +
-               "}";
-
-require("sdk/page-mod").PageMod({
-  include: "*",
-  contentScript: myScript,
-  contentScriptWhen: "start"
-});
- -

This will work fine on most pages, but will fail on pages which also assign to onclick:

- -
<html>
-  <head>
-  </head>
-  <body>
-    <script>
-    window.onclick = function() {
-      window.alert("it's my click now!");
-    }
-    </script>
-  </body>
-</html>
- -

For these reasons, it's better to add event listeners using addEventListener(), defining the listener as a function:

- -
var theMessage = "Hello from content script!";
-
-anElement.onclick = function() {
-  alert(theMessage);
-};
-
-anotherElement.addEventListener("click", function() {
-  alert(theMessage);
-});
- -

Communicating with the add-on

- -

To enable add-on scripts and content scripts to communicate with each other, each end of the conversation has access to a port object.

- -
    -
  • to send messages from one side to the other, use port.emit()
    • -
  • to receive messages sent from the other side, use port.on()
    • -
- -

Messages are asynchronous: that is, the sender does not wait for a reply from the recipient but just emits the message and continues processing.

- -

Here's a simple add-on that sends a message to a content script using port:

- -
// main.js
-
-var tabs = require("sdk/tabs");
-var self = require("sdk/self");
-
-tabs.on("ready", function(tab) {
-  worker = tab.attach({
-    contentScriptFile: self.data.url("content-script.js")
-  });
-  worker.port.emit("alert", "Message from the add-on");
-});
-
-tabs.open("http://www.mozilla.org");
- -
// content-script.js
-
-self.port.on("alert", function(message) {
-  window.alert(message);
-});
- -
-

The context-menu module doesn't use the communication model described here. To learn about communicating with content scripts loaded using context-menu, see the context-menu documentation. 

-
- -

Accessing port in the content script

- -

In the content script the port object is available as a property of the global self object. So to emit a message from a content script:

- -
self.port.emit("myContentScriptMessage", myContentScriptMessagePayload);
- -

To receive a message from the add-on code:

- -
self.port.on("myAddonMessage", function(myAddonMessagePayload) {
-  // Handle the message
-});
- -
-

Note that the global self object is completely different from the self module, which provides an API for an add-on to access its data files and ID.

-
- -

Accessing port in the add-on script

- -

In the add-on code, the channel of communication between the add-on and a particular content script context is encapsulated by the worker object. So the port object for communicating with a content script is a property of the corresponding worker object.

- -

However, the worker is not exposed to add-on code in quite the same way in all modules.

- -

From page-worker

- -

The page-worker object integrates the worker API directly. So to receive messages from a content script associated with a page-worker you use pageWorker.port.on():

- -
// main.js
-
-var pageWorkers = require("sdk/page-worker");
-var self = require("sdk/self");
-
-var pageWorker = require("sdk/page-worker").Page({
-  contentScriptFile: self.data.url("content-script.js"),
-  contentURL: "http://en.wikipedia.org/wiki/Internet"
-});
-
-pageWorker.port.on("first-para", function(firstPara) {
-  console.log(firstPara);
-});
- -

To emit user-defined messages from your add-on you can just call pageWorker.port.emit():

- -
// main.js
-
-var pageWorkers = require("sdk/page-worker");
-var self = require("sdk/self");
-
-pageWorker = require("sdk/page-worker").Page({
-  contentScriptFile: self.data.url("content-script.js"),
-  contentURL: "http://en.wikipedia.org/wiki/Internet"
-});
-
-pageWorker.port.on("first-para", function(firstPara) {
-  console.log(firstPara);
-});
-
-pageWorker.port.emit("get-first-para");
- -
// content-script.js
-
-self.port.on("get-first-para", getFirstPara);
-
-function getFirstPara() {
-  var paras = document.getElementsByTagName("p");
-  if (paras.length > 0) {
-    var firstPara = paras[0].textContent;
-    self.port.emit("first-para", firstPara);
-  }
-}
- -

From page-mod

- -

A single page-mod object might attach its scripts to multiple pages, each with its own context in which the content scripts are executing, so it needs a separate channel (worker) for each page.

- -

So page-mod does not integrate the worker API directly. Instead, each time a content script is attached to a page, the page-mod emits an attach event, whose listener is passed the worker for that context. By supplying a listener to attach you can access the port object for content scripts attached to that page by this page-mod:

- -
// main.js
-
-var pageMods = require("sdk/page-mod");
-var self = require("sdk/self");
-
-var pageMod = pageMods.PageMod({
-  include: ['*'],
-  contentScriptFile: self.data.url("content-script.js"),
-  onAttach: startListening
-});
-
-function startListening(worker) {
-  worker.port.on('click', function(html) {
-    worker.port.emit('warning', 'Do not click this again');
-  });
-}
- -
// content-script.js
-
-window.addEventListener('click', function(event) {
-  self.port.emit('click', event.target.toString());
-  event.stopPropagation();
-  event.preventDefault();
-}, false);
-
-self.port.on('warning', function(message) {
-  window.alert(message);
-});
-
- -

In the add-on above there are two messages:

- -
    -
  • click is sent from the page-mod to the add-on, when the user clicks an element in the page
    • -
  • warning sends a silly string back to the page-mod
    • -
- -

From Tab.attach()

- -

The Tab.attach() method returns the worker you can use to communicate with the content script(s) you attached.

- -

This add-on adds a button to Firefox: when the user clicks the button, the add-on attaches a content script to the active tab, sends the content script a message called "my-addon-message", and listens for a response called "my-script-response":

- -
//main.js
-
-var tabs = require("sdk/tabs");
-var buttons = require("sdk/ui/button/action");
-var self = require("sdk/self");
-
-buttons.ActionButton({
-  id: "attach-script",
-  label: "Attach the script",
-  icon: "./icon-16.png",
-  onClick: attachScript
-});
-
-function attachScript() {
-  var worker = tabs.activeTab.attach({
-    contentScriptFile: self.data.url("content-script.js")
-  });
-  worker.port.on("my-script-response", function(response) {
-    console.log(response);
-  });
-  worker.port.emit("my-addon-message", "Message from the add-on");
-}
-
- -
// content-script.js
-
-self.port.on("my-addon-message", handleMessage);
-
-function handleMessage(message) {
-  alert(message);
-  self.port.emit("my-script-response", "Response from content script");
-}
- -

The port API

- -

See the reference page for the port object.

-
- -

The postMessage API

- -

Before the port object was added, add-on code and content scripts communicated using a different API:

- - - -

The API is still available and documented, but there's no reason to use it instead of the port API described here. The exception is the context-menu module, which still uses postMessage.

- -

Content script to content script

- -

Content scripts can only communicate with each other directly if they have been loaded into the same context. For example, if a single call to Tab.attach() attaches two content scripts, then they can see each other directly, just as page scripts loaded by the same page can. But if you call Tab.attach() twice, attaching a content script each time, then these content scripts can't communicate with each other. You must then relay messages through the main add-on code using the port API.

- -

Cross-domain content scripts

- -

By default, content scripts don't have any cross-domain privileges. In particular, they can't access content hosted in an iframe, if that content is served from a different domain, or make cross-domain XMLHttpRequests.

- -

However, you can enable these features for specific domains by adding them to your add-on's package.json under the "cross-domain-content" key, which itself lives under the "permissions" key. See the article on cross-domain content scripts.

-
diff --git a/files/ja/mozilla/add-ons/sdk/guides/index.html b/files/ja/mozilla/add-ons/sdk/guides/index.html deleted file mode 100644 index 0a6a4422d6..0000000000 --- a/files/ja/mozilla/add-ons/sdk/guides/index.html +++ /dev/null @@ -1,115 +0,0 @@ ---- -title: ガイド -slug: Mozilla/Add-ons/SDK/Guides -translation_of: Archive/Add-ons/Add-on_SDK/Guides ---- -

This page lists more theoretical in-depth articles about the SDK.

-
-

Contributor's guide

-
-
-
-
- Getting Started
-
- Learn how to contribute to the SDK: getting the code, opening/taking a bug, filing a patch, getting reviews, and getting help.
-
- Modules
-
- Learn about the module system used by the SDK (which is based on the CommonJS specification), how sandboxes and compartments can be used to improve security, and about the built-in SDK module loader, known as Cuddlefish.
-
- Classes and Inheritance
-
- Learn how classes and inheritance can be implemented in JavaScript, using constructors and prototypes, and about the helper functions provided by the SDK to simplify this.
-
-
-
-
-
- Private Properties
-
- Learn how private properties can be implemented in JavaScript using prefixes, closures, and WeakMaps, and how the SDK supports private properties by using namespaces (which are a generalization of WeakMaps).
-
- Content Processes
-
- The SDK was designed to work in an environment where the code to manipulate web content runs in a different process from the main add-on code. This article highlights the main features of that design.
-
-
-
-
-

SDK infrastructure

-
-
-
-
- Module structure of the SDK
-
- The SDK, and add-ons built using it, are of composed from reusable JavaScript modules. This explains what these modules are, how to load modules, and how the SDK's module tree is structured.
-
- SDK API lifecycle
-
- Definition of the lifecycle for the SDK's APIs, including the stability ratings for APIs.
-
-
-
-
-
- Program ID
-
- The Program ID is a unique identifier for your add-on. This guide explains how it's created, what it's used for and how to define your own.
-
- Firefox compatibility
-
- Working out which Firefox releases a given SDK release is compatible with, and dealing with compatibility problems.
-
-
-
-
-

SDK idioms

-
-
-
-
- Working With Events
-
- Write event-driven code using the the SDK's event emitting framework.
-
- Content scripts guide
-
- An overview of content scripts, including: what they are, what they can do, how to load them, how to communicate with them.
-
-
-
-
-
- Two Types of Scripts
-
- This article explains the differences between the APIs available to your main add-on code and those available to content scripts.
-
-
-
-
-

XUL migration

-
-
-
-
- XUL Migration Guide
-
- Techniques to help port a XUL add-on to the SDK.
-
- XUL versus the SDK
-
- A comparison of the strengths and weaknesses of the SDK, compared to traditional XUL-based add-ons.
-
-
-
-
-
- Porting Example
-
- A walkthrough of porting a relatively simple XUL-based add-on to the SDK.
-
-
-
-

 

diff --git a/files/ja/mozilla/add-ons/sdk/index.html b/files/ja/mozilla/add-ons/sdk/index.html deleted file mode 100644 index d1a2754a26..0000000000 --- a/files/ja/mozilla/add-ons/sdk/index.html +++ /dev/null @@ -1,99 +0,0 @@ ---- -title: Add-on SDK -slug: Mozilla/Add-ons/SDK -translation_of: Archive/Add-ons/Add-on_SDK ---- -

Add-on SDKを使って、JavaScript、HTML、CSSなどのウェブ技術を用いたFirefoxのアドオンを作成することができます。SDKにはアドオンを作成するためのJavaScript APIや、アドオンの作成、実行、テスト、そしてパッケージングを行うためのツールが含まれています。

-
-

チュートリアル

-
-
-
-
- はじめに
-
- SDKのインストール方法と、アドオンの開発、テストおよびパッケージングのためのcfxツールの使い方について。
-
- ブラウザと対話する
-
- ウェブページを開き、ページが読み込まれたことを確認し、 開いているタブの一覧を取得してみましょう。
-
- 開発のためのテクニック
-
- ユニットテスト、 ログの出力、再利用可能なモジュールの作成、 ローカライズ、 そしてモバイル向けの開発などの、アドオン開発のための一般的なテクニックについて学びましょう。
-
-
-
-
-
- ユーザーインターフェースの作成
-
- ツールバーボタン、 コンテキストメニュー、メニュー項目、そしてダイアログなどの、ユーザーインターフェースの構成要素を作成しましょう。
-
- ウェブページを変化させる
-
- 特性のパターンにマッチしたURLのページや、特性のタブに表示されているページの内容を修正してみましょう。
-
- まとめ
-
- Annotatorアドオンを例とした、アドオン開発の概略。
-
-
-
-
-

ガイド

-
-
-
-
- コントリビューターズガイド
-
- SDKへのコントリビュートの始め方をお知らせします。また、モジュールやクラスと継承、プライベートプロパティ、そしてコンテンツの処理などの、SDKのコードで使われている最も重要な手法についてお知らせします。
-
- SDKの下部構造
-
- SDKの根底にあるテクノロジーについて。モジュール、プログラムID、Firefoxの互換性を定義する規則など。
-
- Content script
-
- content scriptの扱い方についての詳細なガイド。content scriptの読み込み、DOMへのアクセス、content script同士またはほかのアドオンとのやり取りの方法など。
-
-
-
-
-
- SDKのイディオム
-
- SDKにおけるイベントの扱い方、およびadd-on scriptとcontent scriptの区別について。
-
- XULからのマイグレーション
-
- XULで作成されたアドオンをSDKに移植するためのガイドです。 二つのツールセットの比較や移植の実施例を含みます。
-
-
-
-
-

リファレンス

-
-
-
-
- 高レベルAPI
-
- SDKの高レベルなAPIについてのドキュメント。
-
- ツール
-
- アドオンの開発、テストおよびパッケージングに利用するcfxツール、ログの出力に利用するconsoleオブジェクト、およびpackage.jsonについてのドキュメント。
-
-
-
-
-
- 低レベルAPI
-
- SDKの低レベルなAPIについてのドキュメント。
-
-
-
-

 

diff --git a/files/ja/mozilla/add-ons/sdk/tutorials/display_a_popup/index.html b/files/ja/mozilla/add-ons/sdk/tutorials/display_a_popup/index.html deleted file mode 100644 index 32e4e520f8..0000000000 --- a/files/ja/mozilla/add-ons/sdk/tutorials/display_a_popup/index.html +++ /dev/null @@ -1,142 +0,0 @@ ---- -title: ポップアップを表示する -slug: Mozilla/Add-ons/SDK/Tutorials/Display_a_Popup -translation_of: Archive/Add-ons/Add-on_SDK/Tutorials/Display_a_Popup ---- -
-

このチュートリアルを行うには SDK をインストール し、cfx の基本 について学んでいる必要があります。

-

このチュートリアルは、Firefox 29 以降で使用可能な アクションボタン API を使用しています。

-
-

ポップアップダイアログを表示するには、panel モジュールを使用します。パネルのコンテンツは HTML を使用して定義されます。パネル内でコンテンツのスクリプトを実行できます: パネル内で実行されるスクリプトは、アドオンのメインコードには直接アクセスできませんが、パネルのスクリプトとアドオンのコードの間でメッセージを交換できます。

-

このチュートリアルでは、クリックした際にパネルを表示する アクションボタン をツールバーに追加したアドオンを作成します。パネルには、<textarea> 要素のみが含まれています: return キーを押すと、<textarea> 内のコンテンツがメインのアドオンコードに送信されます。メインのアドオンコードでは、メッセージをコンソールログに表示 します。

-

アドオンは 6 つのファイルで構成されています:

- -

"main.js" は以下のようになっています:

-
var data = require("sdk/self").data;
-// Construct a panel, loading its content from the "text-entry.html"
-// file in the "data" directory, and loading the "get-text.js" script
-// into it.
-var text_entry = require("sdk/panel").Panel({
-  contentURL: data.url("text-entry.html"),
-  contentScriptFile: data.url("get-text.js")
-});
-
-// Create a button
-require("sdk/ui/button/action").ActionButton({
-  id: "show-panel",
-  label: "Show Panel",
-  icon: {
-    "16": "./icon-16.png",
-    "32": "./icon-32.png",
-    "64": "./icon-64.png"
-  },
-  onClick: handleClick
-});
-
-// Show the panel when the user clicks the button.
-function handleClick(state) {
-  text_entry.show();
-}
-
-// When the panel is displayed it generated an event called
-// "show": we will listen for that event and when it happens,
-// send our own "show" event to the panel's script, so the
-// script can prepare the panel for display.
-text_entry.on("show", function() {
-  text_entry.port.emit("show");
-});
-
-// Listen for messages called "text-entered" coming from
-// the content script. The message payload is the text the user
-// entered.
-// In this implementation we'll just log the text to the console.
-text_entry.port.on("text-entered", function (text) {
-  console.log(text);
-  text_entry.hide();
-});
-

コンテンツスクリプト "get-text.js" は、以下のようになっています:

-
- 
// When the user hits return, send the "text-entered"
-// message to main.js.
-// The message payload is the contents of the edit box.
-var textArea = document.getElementById("edit-box");
-textArea.addEventListener('keyup', function onkeyup(event) {
-  if (event.keyCode == 13) {
-    // Remove the newline.
-    text = textArea.value.replace(/(\r\n|\n|\r)/gm,"");
-    self.port.emit("text-entered", text);
-    textArea.value = '';
-  }
-}, false);
-// Listen for the "show" event being sent from the
-// main add-on code. It means that the panel's about
-// to be shown.
-//
-// Set the focus to the text area so the user can
-// just start typing.
-self.port.on("show", function onShow() {
-  textArea.focus();
-});
-
-  
-
-

そして、"text-entry.html" ファイルで <textarea> 要素を定義します:

-
-
- 
<html>
-<head>
-    <style type="text/css" media="all">
-      textarea {
-        margin: 10px;
-      }
-      body {
-        background-color: gray;
-      }
-    </style>
-  </head>
-<body>
-    <textarea rows="13" cols="33" id="edit-box"></textarea>
-  </body>
-</html>
-
-  
-
-
-

3 種類のアイコンファイルを "data" ディレクトリに保存します:

- - - - - - - - - - - - - - - -
icon-16.png
icon-32.png
icon-64.png
-

試してください: "main.js" をアドオン内の lib ディレクトリに保存し、他の 5 つのファイルをアドオン内のdata ディレクトリに保存してください:

-
my-addon/
-         data/
-              get-text.js
-              icon-16.png
-              icon-32.png
-              icon-64.png
-              text-entry.html
-         lib/
-             main.js
-
-

アドオンを実行し、ボタンをクリックすると、パネルが表示されます。テキストを入力し、"return" を押すと、コンソールに出力されます。

-

Firefox 30 以降では、トグルボタン を使用すると、 ボタンからパネルを呼び出せます。

-

詳しく学ぶ

-

panel モジュールについてさらに学ぶには、panel API リファレンス をご覧ください。

-

ボタンについてさらに学ぶには、アクションボタン と トグルボタン API リファレンスをご覧ください。

diff --git a/files/ja/mozilla/add-ons/sdk/tutorials/getting_started/index.html b/files/ja/mozilla/add-ons/sdk/tutorials/getting_started/index.html deleted file mode 100644 index 3eb0b80ec6..0000000000 --- a/files/ja/mozilla/add-ons/sdk/tutorials/getting_started/index.html +++ /dev/null @@ -1,167 +0,0 @@ ---- -title: 入門 -slug: Mozilla/Add-ons/SDK/Tutorials/Getting_started -translation_of: Mozilla/Add-ons/SDK/Tutorials/Getting_Started_%28jpm%29 ---- -

SDK を使用してシンプルなアドオンの作成を始めるための手順の概略です。

-

必要条件

-

SDK を使用してアドオンを作成するには、まず最初に SDKをインストールして起動するための手順に従ってください。インストールは一度だけ行えばよく、SDK の起動はコマンドプロンプトごとに行う必要があります。準備が整ったら、コマンドプロンプトを見てください。

-

Linux または Mac OS X の場合、コマンドプロンプトの先頭は SDK のルートディレクトリ名となります。

-
(addon-sdk)~/mozilla/addon-sdk >
-
-

Windows の場合、コマンドプロンプトの先頭は SDK がインストールされたディレクトリの絶対パスとなります。

-
(C:\Users\mozilla\sdk\addon-sdk) C:\Users\Work\sdk\addon-sdk>
-
-

アドオンの初期化

-

コマンドプロンプトで新しいディレクトリを作成してください。SDK のルートディレクトリ以下の場所以外であれば、任意の場所に作成することができます。作成後はそのディレクトリに移動し、cfx init を実行してください。

-
mkdir my-addon
-cd my-addon
-cfx init
-
-

そうした場合、以下のように出力されるでしょう。

-
* lib directory created
-* data directory created
-* test directory created
-* doc directory created
-* README.md written
-* package.json written
-* test/test-main.js written
-* lib/main.js written
-* doc/main.md written
-Your sample add-on is now ready for testing:
-try "cfx test" and then "cfx run". Have fun!"
-
-

アドオンを実装する

-

lib ディレクトリにある main.js ファイルに、アドオンのコードを書くことができます。これは前のステップで作成されたものです。main.js を開き、以下のコードを追加してください。

-
var buttons = require('sdk/ui/button/action');
-var tabs = require("sdk/tabs");
-
-var button = buttons.ActionButton({
-  id: "mozilla-link",
-  label: "Visit Mozilla",
-  icon: {
-    "16": "./icon-16.png",
-    "32": "./icon-32.png",
-    "64": "./icon-64.png"
-  },
-  onClick: handleClick
-});
-
-function handleClick(state) {
-  tabs.open("http://www.mozilla.org/");
-}
-
-

コードを追加したら、ファイルを保存してください。

-

次に、以下の3つのアイコンファイルを data ディレクトリに保存してください。

- - - - - - - - - - - - - - - -
icon-16.png
icon-32.png
icon-64.png
-
-

上記のコードは、Firefox 29 以降においてのみ使用できる action button モジュールを使用していることに注意してください。それ以前のバージョンの Firefox を使用する場合、アイコンがブラウザウィンドウの右下に表示されることを除けば、以下のコードを使用して同じものを実装できます。

- 
var widgets = require("sdk/widget");
-var tabs = require("sdk/tabs");
-var widget = widgets.Widget({
-  id: "mozilla-link",
-  label: "Mozilla website",
-  contentURL: require("sdk/self").data.url("icon-16.png"),
-  onClick: function() {
-    tabs.open("http://www.mozilla.org/");
-  }
-});
-
-

コマンドプロンプトに戻り、以下のコマンドを実行します。

-
cfx run
-
-

これは、開発中のアドオンがインストールされた状態でFirefoxの新規インスタンスを実行する、 SDK のコマンドです。Firefox が起動されると、ブラウザの右上にFirefox ロゴのアイコンが表示されます。そのアイコンをクリックすると、http://www.mozilla.org/ が読み込まれた新しいタブが開きます。

-
-

cfx run と入力したとき、以下のようなメッセージが表示される場合があります。

- 
A given cfx option has an inappropriate value:
-  ZIP does not support timestamps before 1980
-

もし表示されたのであれば、bug 1005412 に行き当たったことになります。これは、ダウンロードしたアイコンファイルに1970年のタイムスタンプが付与されていることを意味します。このバグが修正されるまでは、touch コマンドを使ってタイムスタンプをアップデートすることによってバグを回避してください。

- 
touch icon-16.png
-
-

このアドオンが行うことは、これで全部です。このアドオンは2つの SDK モジュールを使用しています。一つは、ボタンをブラウザに追加することができる action button モジュール、もう一つは、基本的なタブの操作を可能にする tabs モジュールです。今回は、Firefox アイコンのボタンを作成し、それをクリックすると新しいタブで Mozilla ウェブサイトのホームページを読み込むためのハンドラを追加しました。

-

先述のファイルを編集してみましょう。例えば、読み込むページを変更することができます。

-
var buttons = require('sdk/ui/button/action');
-var tabs = require("sdk/tabs");
-
-var button = buttons.ActionButton({
-  id: "mozilla-link",
-  label: "Visit Mozilla",
-  icon: {
-    "16": "./icon-16.png",
-    "32": "./icon-32.png",
-    "64": "./icon-64.png"
-  },
-  onClick: handleClick
-});
-
-function handleClick(state) {
-  tabs.open("https://developer.mozilla.org/");
-}
-
-

上記のコードは、Firefox 29 以降においてのみ使用できる action button モジュールを使用していることに注意してください。それ以前のバージョンの Firefox を使用する場合、アイコンがブラウザウィンドウの右下に表示されることを除けば、以下のコードを使用して同じものを実装できます。

- 
var widgets = require("sdk/widget");
-var tabs = require("sdk/tabs");
-var widget = widgets.Widget({
-  id: "mozilla-link",
-  label: "Mozilla website",
-  contentURL: require("sdk/self").data.url("icon-16.png"),
-  onClick: function() {
-    tabs.open("http://developer.mozilla.org/");
-  }
-});
-
-

コマンドプロンプトで、再び cfx run を実行してください。今度は https://developer.mozilla.org/ が表示されます。

-

アドオンをパッケージ化する

-

アドオンが完成して配布する準備ができたとき、XPI ファイルとしてパッケージ化する必要があります。これは Firfox アドオンとしてインストール可能なファイル形式です。XPI ファイルを独自の手段で配布するか、https://addons.mozilla.org で公開しましょう。そうすれば、ほかのユーザーがそのアドオンをダウンロードし、インストールすることできます。

-

アドオンのディレクトリで cfx xpi コマンドを実行するだけで、XPI をビルドすることができます。

-
cfx xpi
-
-

そうした場合、以下のようなメッセージが表示されるでしょう。

-
Exporting extension to my-addon.xpi.
-
-

アドオンが動くかどうかテストするために、あなたがインストールした Firefox に XPI ファイルをインストールしてみましょう。Firefox で Ctrl+O の組み合わせ（Mac であれば Cmd+O）でキーを入力するか、Firefox の「ファイル」メニューから「ファイルを開く」を選択します。すると、ファイル選択ダイアログが表示されます。アドオンの XPI ファイルがある場所まで移動してファイルを開き、アドオンをインストールするためのプロンプトに従ってください。

-

要約

-

このチュートリアルでは、3つのコマンドを使ってアドオンの構築およびパッケージ化を行いました。

- -

これら3つのコマンドは、SDK を用いてアドオンを開発するときに使用する主要なコマンドです。利用可能な全てのコマンドとオプションを網羅したリファレンスも用意してます。

-

アドオン自体のコードは、action button と tabs の2つのモジュールを使用しています。SDKの高レベルなAPI および 低レベルなAPI のリファレンスも用意しています。

-

次のステップ

-

SDKのAPIを使ってできることに慣れるためには、いくつかのチュートリアルを進めてみてください。 

-

上級テクニック

-

組み込みのモジュールの上書き

-

アドオンを実装するために使用する SDK モジュールは、Firefox に組み込まれているものです。アドオンを cfx run コマンドで実行したり、cfx xpi コマンドでパッケージ化したりする場合は、アドオンは Firefox が提供するバージョンのモジュールを使用します。

-

アドオン開発者としては、通常これは望ましい挙動です。しかし、SDK のモジュール自体を開発する場合には、当然それは望ましくない挙動でしょう。この場合、仮にSDKを GitHub リポジトリからチェックアウトし、そのルートディレクトリで bin/activate スクリプトを実行するものとします。

-

そのときは、"-o" オプションを渡して cfx run または cfx xpi コマンドを実行します。

-
cfx run -o
-
-

これにより、cfx は Firefox 組み込みのモジュールではなく、SDK モジュールのローカルコピーを使用するようになります。

-

cfx を実行せずに開発する

-

cfx run を呼び出すたびにブラウザが再起動されるため、アドオンを頻繁に変更する場合、開発効率をいくらか損なうことになるでしょう。それに代わるものとして、特定のポートの新しい XPI ファイルを自動的にインストールする Extension Auto-Installer アドオンを利用した開発があります。これにより、ブラウザを再起動する必要なく新しい変更点をテストすることができます。

- -

さらに、このワークフローを簡単なスクリプトで自動化できます。例えば、以下のようなスクリプトです。

-
while true ; do cfx xpi ; wget --post-file=codesy.xpi http://localhost:8888/ ; sleep 5 ; done
-
-

この方法を使った場合、アドオンを cfx run コマンドにより実行した場合と比べて、コンソールへのログ出力のレベルが異なることに注意してください。つまり、 console.log() が出力するメッセージを見たい場合、設定を微調整する必要があります。詳細については、ログ出力のレベルに関するドキュメントを参照してください。

diff --git a/files/ja/mozilla/add-ons/sdk/tutorials/getting_started_(jpm)/index.html b/files/ja/mozilla/add-ons/sdk/tutorials/getting_started_(jpm)/index.html deleted file mode 100644 index 26fa4e6c4b..0000000000 --- a/files/ja/mozilla/add-ons/sdk/tutorials/getting_started_(jpm)/index.html +++ /dev/null @@ -1,174 +0,0 @@ ---- -title: Getting Started (jpm) -slug: Mozilla/Add-ons/SDK/Tutorials/Getting_Started_(jpm) -translation_of: Archive/Add-ons/Add-on_SDK/Tutorials/Getting_Started_(jpm) ---- -

{{AddonSidebar}}

- -
-

Support for extensions using XUL/XPCOM or the Add-on SDK was removed in Firefox 57, released November 2017. As there is no supported version of Firefox enabling these technologies, this page will be removed by December 2020.

-
- -

{{LegacyAddonsNotice}}

- -

 

- -
-

Add-on SDK は開発環境の作成, 実行, テスト, アドオンのパッケージング等を行うことができるコマンドラインツールを含みます. Node.js  を元に作成された jpm と呼ばれるクライアントツールは古い cfx tool を置き換えるものです.

-jpm は Firefox 38 以上で使用可能です. - -

この記事では jpm を使ってどのように開発を行うのかを説明します.

-
- -

このチュートリアルでは SDK を使ってシンプルなアドオンを作成していきます.

- -

前提条件

- -

SDK を使って Firefox のアドオンを作成するには, 以下の環境が必要です:

- - - -

最初のアドオンの初期化

- -

コマンドプロンプト上で, 新規ディレクトリを作成します. そのディレクトリに移動し jpm init , と入力し, エンターを押します:

- -
mkdir my-addon
-cd my-addon
-jpm init
-
- -

作成するアドオンに関する情報を入力するように求められます: この情報はこれから作成するアドオンの package.json ファイルを 生成するために使用されます. 今回は, それぞれのプロパティをデフォルトにするため, ただ Enter を押していきます. jpm init に関する詳細な情報は, jpm command reference を参照してください.

- -

これらのプロパティの,値を入力, または デフォルト値に設定した後に "package.json" の完全な内容が表示され、それを受け入れるように求められます.

- -

アドオンの実装

- -

それでは, アドオンのコードを書いて行きましょう. "entry point" の値 (これは package.json の "main" にあります) を変更していない限り, アドオンの root 直下の "index.js" です. このファイルは前のステップで作成されたものです. このファイルを開き以下のコードを追加します:

- -
var buttons = require('sdk/ui/button/action');
-var tabs = require("sdk/tabs");
-
-var button = buttons.ActionButton({
-  id: "mozilla-link",
-  label: "Visit Mozilla",
-  icon: {
-    "16": "./icon-16.png",
-    "32": "./icon-32.png",
-    "64": "./icon-64.png"
-  },
-  onClick: handleClick
-});
-
-function handleClick(state) {
-  tabs.open("http://www.mozilla.org/");
-}
-
- -
-

jpm では "entry point" のデフォルト値は "index.js" であることに注意してください. これは, アドオンの主要なファイルが "index.js" であることを意味しています. また, これはアドオンの root ディレクトリを検索します. and it is found directly in your add-on's root.

- -

cfx では, entry point はデフォルトに "main.js" になります. これは, アドオンの root 直下の "lib" ディレクトリに置かれています.

-
- -

ファイルをセーブします.

- -

続いて, "data" という名前のディレクトリをアドオンの root 直下に作成し,

- -
mkdir data
-
- -

そして以下の 3 つのアイコンファイルを "data" ディレクトリに保存します:

- - - - - - - - - - - - - - - - -
icon-16.png
icon-32.png
icon-64.png
- -

コマンドプロンプトに戻り, 以下のコマンドを入力します:

- -
jpm run
- -

この jpm コマンドは作成したアドオンをインストールした状態の新規 Firefox インスタンスを実行します.

- -

Firefox は見つからない場合や, Firefox Developer を代理のブラウザとしてインストールしている場合には, そこまでの path を渡す必要があるかもしれません. 例えば Ubuntu の場合:

- -
jpm run -b /usr/bin/firefox
- -

Firefox が起動すると, ブラウザの右上端に Firefox のロゴにアイコンが見えるはずです. このアイコンをクリックすると, 新しいタブが開き, http://www.mozilla.org/ が読み込まれます.

- -

これでこのアドオンでやることは終了です. ここでは, 二つの SDK モジュール を使っています: action button モジュール, これはブラウザにボタンを追加することができるモジュールです, tabs モジュール, これはタブの基本的な操作を行うことができるモジュールです. 今回のケースでは, 我々は Firefox アイコンのボタンを作成しました. また, 新規タブに Mozilla のホームページを読み込むクリックハンドラを追加しました.

- -

このファイルを編集してみましょう. 例えば, 読み込むページを変更することができます.

- -
var buttons = require('sdk/ui/button/action');
-var tabs = require("sdk/tabs");
-
-var button = buttons.ActionButton({
-  id: "mozilla-link",
-  label: "Visit Mozilla",
-  icon: {
-    "16": "./icon-16.png",
-    "32": "./icon-32.png",
-    "64": "./icon-64.png"
-  },
-  onClick: handleClick
-});
-
-function handleClick(state) {
-  tabs.open("https://developer.mozilla.org/");
-}
- -

コマンドプロンプトで, jpm run を再度実行します. この時に, ボタンをクリックすると https://developer.mozilla.org/ に移動します.

- -

アドオンのパッケージング

- -

アドオンを作成し終え, 配布準備をする際には, アドオンを XPI にパッケージングする必要があります. これは Firefox アドオンをインストールするためのファイルフォーマットです. XPI を自分で配布したり, 他のユーザーがアドオンをダウンロードまたは, インストールできるようにするために, https://addons.mozilla.org に 公開することが可能です.

- -

XPIをビルドするためには, jpm xpi コマンドをアドオンのディレクトリで実行するだけです:

- -
jpm xpi
- -

次のようなメッセージを見ることができます:

- -
JPM info Successfully created xpi at /path/to/my-addon/@my-addon-0.0.1.xpi
-
- -

これが機能することをテストするために, XPI ファイルを自身がインストールしている Firefox にインストールしてみましょう. これは Firefox から Ctrl+O (Mac では Cmd+O)キーで行うことができます. もしくは, Firefox の "File" メニューから, "Open" を選択してもよいです. するとファイル選択ダイアログが開きます: "@my-addon.xpi" ファイルを選択すると アドオンインストールプロンプトが開きます.

- -

Firefoxでは, 基本的にローカルで開発されたアドオンでも署名が必要であることに注意してください. インストールが終了した後で, インストールされたアドオンのリストで disabled が示されている場合, 署名の不足を確認してください.注意してください。 開発中や, 公開する予定がない場合, 署名の無いアドオンを実行できるように about:config を開き, xpinstall.signatures.required を false に設定してください. この設定を全てのアドオンに適応されてしまうため, 他の場所から悪意のあるものを誤ってインストールしないように特別な注意を払ってください.

- -

アドオンを配布するために, XPI を addons.mozilla.org に提出 します. また自身のサーバーにアドオンを配布したい場合, jpm sign を 実行します.

- -

結論

- -

このチュートリアルでは, 3 つのコマンドを使いアドオンのビルドやパッケージングを行いました:

- - - -

これらは, SDK アドオン開発している時に使用する 3 つの主要なコマンドです. これらがとれるオプションや利用できるすべてのコマンドをカバーした包括的な リファレンス があります.

- -

アドオンコードでは 二つの SDK モジュール, action button や tabs を使用しました. SDK における 全てのAPIs, high-level や low-level に関するレファレンスは存在します.

- -

What's next?

- -

SDK APIs を使ってできるいくつかのことを把握するために, tutorials に挑戦してみてください.

diff --git a/files/ja/mozilla/add-ons/sdk/tutorials/index.html b/files/ja/mozilla/add-ons/sdk/tutorials/index.html deleted file mode 100644 index e7be834a87..0000000000 --- a/files/ja/mozilla/add-ons/sdk/tutorials/index.html +++ /dev/null @@ -1,146 +0,0 @@ ---- -title: チュートリアル -slug: Mozilla/Add-ons/SDK/Tutorials -translation_of: Archive/Add-ons/Add-on_SDK/Tutorials ---- -

{{AddonSidebar}}

- -

SDK を使用したアドオンの開発方法を実践的に説明したページの一覧です。

- -
-

はじめに

- -
-
-
-
インストール
-
Windows、OS X および Linux 上で、SDK をダウンロード、インストール、および初期化します。
-
- -
-
トラブルシューティング
-
よくある問題を解決する場合や、支援を求める場合のヒントを説明します。
-
-
- -
-
-
入門
-
jpm を使用してシンプルなアドオンを作成を始めるための手順の概略です
-
-
-
-
- -
-

ユーザーインターフェイスの作成

- -
-
-
-
ツールバーボタンの追加
-
Firefox アドオンツールバーにボタンを追加します。
-
Firefoxへのメニュー項目の追加
-
Firefox のメインメニューにアイテムを追加します。
-
-
- -
-
-
ポップアップの表示
-
HTML および JavaScript を使用して実装したポップアップダイアログを表示します。
-
コンテキストメニュー項目の追加
-
Firefox のコンテキストメニューに項目を追加します。
-
-
-
- -
-

ブラウザの操作

- -
-
-
-
Webページを開く
-
モジュールを用いて、新しいタブまたはウィンドウでWebページを開き、そのコンテンツにアクセスします。
-
ページの読み込みを確認する
-
モジュールを用いて、新しい Web ページが読み込まれたときに通知を受け取り、それらの Web ページのコンテンツにアクセスします。
-
-
- -
-
-
開いているタブの一覧を表示する
-
tabs モジュールを用いて、現在開いているすべてのタブに対して反復処理を行い、それらのコンテンツにアクセスします。
-
-
-
- -
-

Webページの変更

- -
-
-
-
URLに基づいたWebページの変更
-
URL に基づいて Web ページを検索するフィルタを作成します。フィルタに一致する URL の Web ページを読み込んだときに、フィルタ内の指定したスクリプトを実行します。
-
-
- -
-
-
アクティブなWebページの変更
-
現在アクティブな Web ページに、動的にスクリプトを読み込みます。
-
-
-
- -
-

開発テクニック

- -
-
-
-
ログの出力
-
診断を行うために、メッセージをコンソールにログとして出力します。
-
再利用可能なモジュールの作成
-
アドオンを別個のモジュールとして体系化し、開発、デバッグ、およびメンテナンスを容易にします。 また、作成したモジュールが入った再利用可能なパッケージを作成し、他の開発者もそのモジュールを使用できるようにします。
-
ユニットテスト
-
SDK のテストフレームワークを使用して、ユニットテストを作成し実行します。
-
Chrome 権限
-
この権限を使用すると、アドオンが Components オブジェクトにアクセスできるので、どんな XPCOM オブジェクトでも読み込んで使用できるようになります。
-
イベントターゲットの作成
-
定義したオブジェクトがイベントを発生させられるようにします。
-
-
- -
-
-
読み込みと読み込み解除の確認
-
Firefox にアドオンが読み込まれたり、読み込み解除されたりしたときに通知を受け取ります。またコマンドラインからアドオンに引数を渡します。
-
サードパーティーモジュールの使用
-
SDK 自体に含まれていない追加のモジュールをインストールして使用します。
-
ローカライゼーション
-
ローカライズ可能なコードを作成します。
-
モバイル開発
-
Android 用 Firefox モバイルのアドオン開発を始める手順を説明します。
-
- -
-
アドオン用のデバッガー
-
アドオン内のJavaScriptのデバッグを行います。
-
-
-
- -
-

応用 

- -
-
-
-
アノテーターアドオン
-
より複雑なアドオンの開発作業を順を追って説明します。
-
-
-
diff --git a/files/ja/mozilla/add-ons/sdk/tutorials/installation/index.html b/files/ja/mozilla/add-ons/sdk/tutorials/installation/index.html deleted file mode 100644 index b01e14ded3..0000000000 --- a/files/ja/mozilla/add-ons/sdk/tutorials/installation/index.html +++ /dev/null @@ -1,72 +0,0 @@ ---- -title: インストール -slug: Mozilla/Add-ons/SDK/Tutorials/Installation -translation_of: Mozilla/Add-ons/SDK/Tools/jpm#Installation ---- -

前提条件

-

アドオン SDK を使用して開発を行うには、以下が必要です。

- -

Mac OS Xでの Homebrew を使ったインストール

-

アドオン SDK を Homebrew を用いてインストールするには、以下のコマンドを実行してください。

-
brew install mozilla-addon-sdk
-

Mac OS X / Linux でのインストール

-

shell や commnd prompt を用いて、任意の場所にアドオン SDK のファイルを展開し、SDK のルートディレクトリに移動してください。以下はコマンドの一例です。

-
tar -xf addon-sdk.tar.gz
-cd addon-sdk
-
-

次に、 Bash を使用している場合は以下を実行します。

-
source bin/activate
-
-

Bash 以外を使用している場合は、以下を実行します。

-
bash bin/activate
-
-

コマンドプロンプトの先頭に、SDK のルートディレクトリ名が追加されます。

-
(addon-sdk)~/mozilla/addon-sdk >
-
-

Windows でのインストール

-

shell や commnd prompt を用いて、任意の場所にアドオン SDK のファイルを展開し、SDK のルートディレクトリに移動してください。以下はコマンドの一例です。

-
7z.exe x addon-sdk.zip
-cd addon-sdk
-
-

次に、以下を実行します。

-
bin\activate
-
-

コマンドプロンプトの先頭に、SDK のルートディレクトリ名が追加されます。

-
(C:\Users\mozilla\sdk\addon-sdk) C:\Users\Work\sdk\addon-sdk>
-
-

SDK 仮想環境

-

上記のようにコマンドプロンプトが変更されていれば、シェルで仮想環境が起動し、アドオン SDK コマンドラインツールにアクセスできます。

-

仮想環境は deactivate を実行していつでも終了することができます。

-

仮想環境は、そのコマンドプロンプトにおいてのみ有効です。コマンドプロンプトを閉じると仮想環境が終了するので、再び仮想環境を起動するには、新しいコマンドプロンプトを起動し source bin/activate または bin¥activate と入力する必要があります。新しいコマンドプロンプトを開くだけでは、SDK は起動されません。

-

ディスク上の異なる場所に SDK の複数のコピーを置き、切り替えて使用することもできます。さらには、別個のコマンドプロンプトで、それぞれのコピーを同時に起動することも可能です。

-

activate 永続化

-

activate が行う処理は単に、最上位レベルの bin ディレクトリにあるスクリプトを使用して、現在のコマンドプロンプトに関する複数の環境変数を設定することだけです。そこで、使用する環境でこれらの変数が永続化されるように設定すれば、新しくコマンドプロンプトを開くだけでそれらの変数が読み込まれ、仮想環境が常に使用できます。これにより、新しいコマンドプロンプトを開くたびに activate と入力する必要がなくなります。

-

ただし、コマンドプロンプトに関する変数が、新しい SDK のリリース時に変更されることがあります。設定が必要な変数を特定するために SDK の起動スクリプトを参照するのが最良の方法です。 Bash 環境（Linux および Mac OS X）と Windows 環境では、起動に使用するスクリプトも、それによって設定される変数も異なります。

-

Windows

-

Windows では、 bin\activate を実行すると  activate.bat が使用されます。SDK を常に有効にするには、コマンドラインから setx ツールを使用するか、コントロール パネルを使用します。

-

Linux/Mac OS X

-

Linux および Mac OS X では、 source bin/activate により activate Bash スクリプトが実行されます。SDK を常に有効にするには、Linuxの場合は ~/.bashrc を、Mac OS Xの場合は ~/.bashprofile を使用します。

-

あるいは、‾/bin ディレクトリにある cfx プログラムへのシンボリックリンクを作成する方法もあります。

-
ln -s PATH_TO_SDK/bin/cfx ~/bin/cfx
-
-

サニティチェック

-

シェルプロンプトで以下を実行します。

-
cfx
-
-

一行目には以下のように表示されるでしょう。それに続いて、多数の使用方法の情報が表示されます。

-
Usage: cfx [options] [command] 
-

これが cfx コマンドラインプログラム です。cfx は、アドオン SDK の主要なインターフェイスで、Firefox の起動とアドオンのテスト、アドオンを配布するためのパッケージング、説明書の表示、および単体テストの実行に使用します。

-

問題が発生した場合

-

トラブルシューティング のページを参照してください。

-

次のステップ

-

cfx 入門のチュートリアルに目を通してください。cfx ツールによってアドオンを作成する方法を説明します。

diff --git a/files/ja/mozilla/add-ons/sdk/tutorials/troubleshooting/index.html b/files/ja/mozilla/add-ons/sdk/tutorials/troubleshooting/index.html deleted file mode 100644 index 80db0e8976..0000000000 --- a/files/ja/mozilla/add-ons/sdk/tutorials/troubleshooting/index.html +++ /dev/null @@ -1,112 +0,0 @@ ---- -title: トラブルシューティング -slug: Mozilla/Add-ons/SDK/Tutorials/Troubleshooting -translation_of: Archive/Add-ons/Add-on_SDK/Tutorials/Troubleshooting ---- -

アドオン SDKを起動したり実行したりする際に問題があっても、慌てる必要はありません！問題を突き止めるにはどこから着手すれば良いのかを順番に見ていきましょう。

-

Quarantine Problem on Mac OS X

-

On Mac OS X, you might see the following error when you try to run cfx:

-
/path/to/sdk/bin/cfx: /usr/bin/env: bad interpreter: Operation not permitted
-
-

This might be because the cfx executable file has been placed in quarantine during download from the Internet.

-

To get it out of quarantine, use the xattr -d command, specifying com.apple.quarantine as the name of the attribute to delete, and cfx as the file from which to delete that attribute:

-
xattr -d com.apple.quarantine /path/to/sdk/bin/cfx
-
-

Check Your Python

-

The SDK's cfx tool runs on Python. If you're having trouble getting cfx to run at all, make sure you have Python correctly installed.

-

Try running the following from a command line:

-
  python --version
-
-

cfx currently expects Python 2.5 or 2.6. Older and newer versions may or may not work.

-

Check Your Firefox or XULRunner

-

cfx searches well known locations on your system for Firefox or XULRunner. cfx may not have found an installation, or if you have multiple installations, cfx may have found the wrong one. In those cases you need to use cfx's --binary option. See the cfx Tool guide for more information.

-

When you run cfx to test your add-on or run unit tests, it prints out the location of the Firefox or XULRunner binary that it found, so you can check its output to be sure.

-

Check Your Text Console

-

When errors are generated in the SDK's APIs and your code, they are logged to the text console. This should be the same console or shell from which you ran the cfx command.

-

Don't Leave Non-SDK Files Lying Around

-

Currently the SDK does not gracefully handle files and directories that it does not expect to encounter. If there are empty directories or directories or files that are not related to the SDK inside your addon-sdk directory or its sub-directories, try removing them.

-

Search for Known Issues

-

Someone else might have experienced your problem, too. Other users often post problems to the project mailing list. You can also browse the list of known issues or search for specific keywords.

-

Contact the Project Team and User Group

-

SDK users and project team members discuss problems and proposals on the project mailing list. Someone else may have had the same problem you do, so try searching the list. You're welcome to post a question, too.

-

You can also chat with other SDK users in #jetpack on Mozilla's IRC network.

-

And if you'd like to report a bug in the SDK, that's always welcome! You will need to create an account with Bugzilla, Mozilla's bug tracker.

-

Run the SDK's Unit Tests

-

The SDK comes with a suite of tests which ensures that its APIs work correctly. You can run it with the following command:

-
  cfx testall
-
-

Some of the tests will open Firefox windows to check APIs related to the user interface, so don't be alarmed. Please let the suite finish before resuming your work.

-

When the suite is finished, your text console should contain output that looks something like this:

-
  Testing cfx...
-  .............................................................
-  ----------------------------------------------------------------------
-  Ran 61 tests in 4.388s
-
-OK
-  Testing reading-data...
-  Using binary at '/Applications/Firefox.app/Contents/MacOS/firefox-bin'.
-  Using profile at '/var/folders/FL/FLC+17D+ERKgQe4K+HC9pE+++TI/-Tmp-/tmpu26K_5.mozrunner'.
-  .info: My ID is 6724fc1b-3ec4-40e2-8583-8061088b3185
-  ..
-  3 of 3 tests passed.
-  OK
-  Total time: 4.036381 seconds
-  Program terminated successfully.
-  Testing all available packages: nsjetpack, test-harness, api-utils, development-mode.
-  Using binary at '/Applications/Firefox.app/Contents/MacOS/firefox-bin'.
-  Using profile at '/var/folders/FL/FLC+17D+ERKgQe4K+HC9pE+++TI/-Tmp-/tmp-dzeaA.mozrunner'.
-  .........................................................................
-  .........................................................................
-  .........................................................................
-  .........................................................................
-  .........................................................................
-  .........................................................................
-  .........................................................................
-  .........................................................................
-  .........................................................................
-  .........................................................................
-  .........................................................................
-  .........................................................................
-  .........................................................................
-  .........................................................................
-  .........................................................................
-  .........................................................................
-  .........................................................................
-  .........................................................................
-  .........................................................................
-  .........................................................................
-  .........................................................................
-  .........................................................................
-  .........................................................................
-  .........................................................................
-  .........................................................................
-  .........................................................................
-  .........................................................................
-  .........................................................................
-  .........................................................................
-  .........................................................................
-  .........................................................................
-  .........................................................................
-  .........................................................................
-  .........................................................................
-  .........................................................................
-  .........................................................................
-  .........................................................................
-  .........................................................................
-  .........................................................................
-  .........................................................................
-  .........................................................................
-  .........................................................................
-  .........................................................................
-  .........................................................................
-  .........................................................................
-  .........................................................................
-  ...............................................
-
-3405 of 3405 tests passed.
-  OK
-  Total time: 43.105498 seconds
-  Program terminated successfully.
-  All tests were successful. Ship it!
-
-

If you get lots of errors instead, that may be a sign that the SDK does not work properly on your system. In that case, please file a bug or send a message to the project mailing list. See the previous section for information on doing so.

diff --git a/files/ja/mozilla/add-ons/themes/obsolete/index.html b/files/ja/mozilla/add-ons/themes/obsolete/index.html deleted file mode 100644 index 48bf1f18f0..0000000000 --- a/files/ja/mozilla/add-ons/themes/obsolete/index.html +++ /dev/null @@ -1,46 +0,0 @@ ---- -title: Obsolete -slug: Mozilla/Add-ons/Themes/Obsolete -tags: - - Obsolete - - アドオン - - アーカイブ - - テーマ - - ルックアンドフィール -translation_of: Mozilla/Add-ons/Themes/Obsolete ---- -

 

- -

{{AddonSidebar}}

- -
-

このページには、これまでに更新されることはないテーマドキュメントやリソースが含まれていますが、当面は更新されたドキュメントのソースとして使用されています。

- - - - -
- -

 

diff --git a/files/ja/mozilla/add-ons/webextensions/api/bookmarks/export/index.html b/files/ja/mozilla/add-ons/webextensions/api/bookmarks/export/index.html deleted file mode 100644 index 381e471807..0000000000 --- a/files/ja/mozilla/add-ons/webextensions/api/bookmarks/export/index.html +++ /dev/null @@ -1,114 +0,0 @@ ---- -title: bookmarks.export() -slug: Mozilla/Add-ons/WebExtensions/API/bookmarks/export -tags: - - API - - Add-ons - - Bookmarks - - Extensions - - Method - - Non-standard - - Reference - - WebExtensions - - export -translation_of: Archive/Add-ons/bookmarks.export ---- -

{{AddonSidebar()}}

- -

ブックマークを HTML ブックマークファイルにエクスポートします。

- -

構文

- -
browser.bookmarks.export(
-  function() {...} // 関数（省略可）
-)
-
- -

Parameters

- -
-
callback{{optional_inline}}
-
function.
-
- -

ブラウザ実装状況

- -

{{ CompatibilityTable() }}

- -
- - - - - - - - - - - - - - - - - -
機能ChromeEdgeFirefox (Gecko)Opera
基本サポート{{ CompatVersionUnknown }}{{ CompatUnknown }}{{ CompatNo() }}{{ CompatOpera('33') }}
-
- -
- - - - - - - - - - - - - - - -
機能EdgeFirefox OSFirefox Mobile (Gecko)
基本サポート{{ CompatNo() }}{{ CompatNo() }}{{ CompatNo() }}
-
- -

{{WebExtExamples}}

- -
謝辞 - -

この API は Chromium の chrome.bookmarks API に基づいています。また、このドキュメントは bookmarks.json における Chromium のコードから作成されています。

-
- - diff --git a/files/ja/mozilla/add-ons/webextensions/api/bookmarks/import/index.html b/files/ja/mozilla/add-ons/webextensions/api/bookmarks/import/index.html deleted file mode 100644 index 758b72dbfa..0000000000 --- a/files/ja/mozilla/add-ons/webextensions/api/bookmarks/import/index.html +++ /dev/null @@ -1,114 +0,0 @@ ---- -title: bookmarks.import() -slug: Mozilla/Add-ons/WebExtensions/API/bookmarks/import -tags: - - API - - Add-ons - - Bookmarks - - Extensions - - Method - - Non-standard - - Reference - - WebExtensions - - import -translation_of: Archive/Add-ons/bookmarks.import ---- -

{{AddonSidebar()}}

- -

ブックマークを HTML ブックマークファイルからインポートします。

- -

構文

- -
browser.bookmarks.import(
-  function() {...} // 関数（省略可）
-)
-
- -

引数

- -
-
callback{{optional_inline}}
-
function.
-
- -

ブラウザ実装状況

- -

{{ CompatibilityTable() }}

- -
- - - - - - - - - - - - - - - - - -
機能ChromeEdgeFirefox (Gecko)Opera
基本サポート{{ CompatVersionUnknown }}{{ CompatUnknown }}{{ CompatNo() }}{{ CompatOpera('33') }}
-
- -
- - - - - - - - - - - - - - - -
機能EdgeFirefox OSFirefox Mobile (Gecko)
基本サポート{{ CompatNo() }}{{ CompatNo() }}{{ CompatNo() }}
-
- -

{{WebExtExamples}}

- -
謝辞 - -

この API は Chromium の chrome.bookmarks API に基づいています。また、このドキュメントは bookmarks.json における Chromium のコードから作成されています。

-
- - -- cgit v1.2.3-54-g00ecf