Bug writing guidelines | MDN
Mozilla 製品 (Firefox や Thunderbird など) に関するサポートが必要なら、提供されているいずれかの サポートオプション をご利用ください。このページを編集しないようお願いします。 Mozilla の QA に初めて参加される場合は、より経験を積んだ貢献者の助けを借りてみましょう。QA ページの「コミュニティ」という項目に、他の貢献者と出会える場所が書かれています。 Firefox のバグを報告されるなら、irc.mozilla.org の #firefox チャンネルで協力を求めることもできます。 原則 有用なバグ報告ほど修正される可能性が上がります。このガイドラインではそうした報告の書き方について説明します。 正確に 明確に - 他の人もバグを再現できるよう、状況をはっきりと説明してください 報告 1 件につきバグ 1 件です どんな些細なバグでも報告してく
JavaScript style guide - Mozilla | MDN
else は上で示したように常に単独の行に書いてください。 return の後には else を使わないでください。 if (x < y) return -1; if (x > y) return 1; return 0; i++ も ++i も使用可能です。 インライン関数はそのデバッグが楽になるように名前を付けてください。関数をプロパティに代入しただけではその関数に名前を付けることはできません。次のようにしてください。 var offlineObserver = { observe: function OO_observe(aSubject, aTopic, aState) { if (aTopic == "network:offline-status-changed") setOfflineUI(aState == "offline"); } }; 名前や列挙値には interCap
Guide - Bugzilla-jp | MDN
はじめてのバグジラ このドキュメントはBugzilla-jpを利用するのに必要な知識やノウハウを提供しています。もし、このドキュメントの内容が不十分だったり、間違った記述を発見した場合、Bugzilla-jpにプロダクト:mozilla.gr.jp、コンポーネント:bugzilla-jpでバグとして報告してください。 このドキュメントの読み方 このドキュメントは目的に応じて読み分けることができるように、複数の章に分割されています。Bugzilla-jpを利用する全ての利用者は第一章と第二章は必ず目を通す必要があります。 そして、それ以外にもあなたのとりたい行動(たとえばバグを報告したい等)にあわせて、その手順を紹介したドキュメントを読む必要があります。 このドキュメントは各手順の単なる説明書ではなく、その際に決まっている様々なルールを明文化しています。このルールに従わない方の参加は多くの開
Mozilla CSS サポートチャート | MDN
このページでは、対応している CSS の セレクター、プロパティ、@-規則、メディアクエリ、値をアルファベット順で掲載しています。 「対応開始」の列は、対応が開始された Gecko のバージョン番号を示します。 Gecko 1.0 以前のバージョンは、 1.0 として一覧表示されています。 Gecko は、Firefox やその他のアプリケーションで用いられているレンダリングエンジンです。Firefox 及び Gecko のバージョン番号に関しての詳細については Gecko のページを参照して下さい。 「仕様書」の列は、その行の項目が策定された仕様書（基本的には最新のものの一つ）にリンクしています。但し古い仕様へのリンクのままになっており修正の必要がある項目を含む可能性がある点に注意して下さい。 Mozilla CSS 拡張 (プロパティ名の先頭に-moz-接頭辞をもつもの) に関しては、
Configuring Build Options - MDC
この記事は翻訳が完了していません。 この記事の翻訳にご協力ください デフォルトオプションの状態で configure および make を実行しても、動作するビルドを作り上げることはできません。.mozconfig ファイルを使って、相応のリリースビルドを入手してください。ビルドの前に次のガイドをよく読み、順番に従ってください。工程を 1 つでも飛ばせば、ソフトウェアをビルドできないか、使い物にならないビルドができるでしょう。 .mozconfig 設定ファイルを使う 手動でコマンドラインオプションを使って configure を実行することも可能ですが、推奨しません。代わりに、ソースディレクトリに .mozconfig ファイルを置いてください (mozilla/.mozconfig)。または HOME ディレクトリに .mozconfig ファイルを置いてください (~/.mozcon
Building Firefox with Debug Symbols | MDN
標準では、Firefox のリリースビルドは breakpad シンボルフォーマットのなかのデバッグや事後処理に適したデバッグシンボルを生成しません。シンボル付きでビルドするには以下の mozconfig 設定を使ってください: Windows export MOZ_DEBUG_SYMBOLS=1 ac_add_options --enable-debugger-info-modules=all 典型的なリリースビルドは --enable-static のようなさらなるオプションを持つでしょう。ナイトリービルドが利用している tools/tinderbox-configs/firefox/win32/mozconfig を参照してください。 Mac ac_add_options --enable-optimize='-O2 -g' Linux ac_add_options --enable
Build and Install - Mozilla | MDN
Mozilla のチェックアウトやビルドには必ず GNU make を使用してください。他の "make" プログラムは好ましくありません。Windows、Mac OS X および GNU/Linux では GNU make を実行するために "make" を使ってください。ほとんどの 非 GNU の unix では "gmake" を使ってください。 Windows、Mac OS X および GNU/Linux では必ずソースディレクトリの最上部 ("mozilla") で make コマンドを実行してください。 make -f client.mk build Mac OS X での注意：ソースの tar ボールを展開したときに作成されるソースディレクトリのパスにスペースが含まれないようにしてください。 ほとんどの非 GNU の unix の場合 $ gmake -f client.mk
XUL Explorer - Archive of obsolete content | MDN
XUL Explorer is a XULRunner application that provides an easy way to experiment with XUL. It’s a simple editor that can preview XUL inline or in a separate popup window. It has a list of code snippets (small fragments of XUL or JavaScript) that can be quickly inserted into the editor. The XUL can be loaded from and saved to files. A XUL validator and the Error Console are both available to help de
Canvas tutorial - MDC
このチュートリアルは、 <canvas> 要素を使用して二次元のグラフィックを描画する方法を、基本から説明します。ここでの例は、キャンバスで何ができるかを明確に示すものであり、独自のコンテンツを作成するためのコードスニペットも提供しています。 <canvas> は HTML の要素であり、スクリプト（ふつうは JavaScript）を使ってグラフィックを描くことができます。これは例えば、グラフを描いたり、写真を合成したり、簡単なアニメーションを作成したりすることができます。 <canvas> は Apple が macOS Dashboard のために WebKit に初めて導入した後、ブラウザーに実装されました。現在は、あらゆる主要ブラウザーが対応しています。 <canvas> を使うのはそれほど難しくはありませんが、 HTML と JavaScript の基本的な理解が必要です。一部の
Gecko hacking tutorial | MDN
はじめに この文書は、Mozilla の心臓部である Gecko を Hack するための手順を紹介します。 準備 環境 この文書は、以下の環境を想定しています。 OS ソースコードの取得 何よりもまず、Mozilla のソースコードが必要です。この記事では、（この記事の執筆時点で）Firefoxの最新リリースである Firefox 2.0.0.2 を使用します。Firefox 2.0.0.2 のソースコードは、以下から入手可能です。 http://ftp.mozilla.org/pub/mozilla.o....0.0.2/source/ ソースコードはbzipアーカイブです。後で展開作業を行いますので、適当な場所に保存しておいてください。 コンパイラの準備 Windows Build Prerequisitesによると、この記事が対象としている Firefox 2.0.x をビルドする
XUL accessibility guidelines - Archive of obsolete content | MDN
序文 XUL アクセシビリティガイドラインへようこそ。以下の原理と実践によって、身体障害または感覚障害、会話の困難なユーザを含むすべてのユーザを楽しませ、XUL アプリケーションを様々な方法で利用できるように書くことができます。Accessibility is not difficult, but does require a basic understanding of the different types of disabilities, commonly used assistive technologies, and special accessibility features built into the XUL languages. 特に必要なものは、あなたの意識的な努力とすべての人を考慮する願望です。 これらのガイドラインは、すべての人(アクセシビリティの前提がない人でも)
Building PyXPCOM | MDN
この記事は PyXPCOM のビルド方法を紹介します。 Python をインストール PyXPCOM に必要な条件 PyXPCOM は Python 2.3 もしくはそれ以降が必要です (Python 2.3 と 2.4 では現在テストが完了されています). PyXPCOM は Python の共有ライブラリにアクセスできる必要があります。 Linux Linux では、適切な Python の共有ライブラリを持っているかどうかをビルドスクリプトがチェックをします。 Compiling Mozilla に行き、もし共有ビルドされた Python が見つからなくエラーを受け取った場合、 後の方の記述に従い --enable-shared をつけて Python をコンパイルする必要があります。 現在の Fedora と Ubuntu 上でのビルド これらのディストリビューションではすでに利用
Mozilla XSLT Documentation
async function init() { const parser = new DOMParser(); const xsltProcessor = new XSLTProcessor(); // Load the XSLT file, example1.xsl const xslResponse = await fetch("example1.xsl"); const xslText = await xslResponse.text(); const xslStylesheet = parser.parseFromString(xslText, "application/xml"); xsltProcessor.importStylesheet(xslStylesheet); // process the file // ... } For the actual transform
Reading textual data | MDN
ネットワークチャンネル (nsIChannel) を使っているのであれば、その contentCharset プロパティを使うことができます。すべてのチャンネルからデータの文字エンコーディングがわかるわけではないので注意してください。代わりに、設定（intl.charset.default、ローカライズされた設定値）で保存されているデフォルトの文字エンコーディングを使うこともできます。 ファイルから読み込むとなると、これは答えづらい質問です。システムの文字エンコーディングを使うとうまくいくかもしれません。また、同様に設定からデフォルトの文字エンコーディングを取得し、それを使ってもいいでしょう。 文字列の読み込み Gecko 1.8 (SeaMonkey 1.0、Firefox 1.5) では、ストリーム (nsIInputStream) から文字列を読み込むのに nsIConverterI
Writing textual data - Archive of obsolete content | MDN
この記事では、国際化を考慮しつつ、テキストデータをストリーム、ファイル、ソケットに書き込む方法を説明します。 警告：この記事では仕様が未確定のインタフェースを使用しています。これらのインタフェースは新しい Mozilla では変更になる可能性があり、そのときはコードが機能しなくなるかもしれません。 テキストデータを出力ストリームやファイルに書き込むときは、文字エンコーディングを選択する必要があります。 UTF-8、UTF-16、UTF-32 といった文字エンコーディングは、その他が全レパートリの一部しか表せないのに対して、「すべての」文字（Unicode の全レパートリ）を表すことができます。 そのファイルがアプリケーションや拡張機能自身からしか読み込まれないのであれば UTF-8 の使用は最良の選択です。すべての文字を表すことができ、ASCII 文字も効率的に表されます。 ストリームへの
Getting Mozilla Source Code Using CVS - Mozilla | MDN
注記: このドキュメントは Gecko 1.9.0 や Firefox 3 より古いバージョンと、NSS および NSPR のすべてのバージョンのソースコードを取得する方法について書かれています。Gecko 1.9.1/Firefox 3.5 以降の開発は Mercurial ソースコードコントロールシステムを使用します。 精力的に開発に関わっている人は、CVS を使って最新のソースをチェックアウトできます。この方法は、パッチやバグ修正を提供したい場合におすすめの方法です。というのも、文字通り最新の変更を入手でき、それらとあなた独自の変更をマージできるからです。 リリースのために製品をコンパイルしたい場合は、tarball で Mozilla ソースコードをダウンロードする 方が良いでしょう。 はじめに CVS とは「Concurrent Versioning System」を意味します。
XPCNativeWrapper | MDN
「明示的」か「暗黙的」か XPCNativeWrapper の挙動が明示的 (explicit)か暗黙的 (implicit)かの違いは、 保護されていないスクリプトからの、暗黙的な XPCNativeWrapper 上のプロパティへのアクセスは、安全ではないという点です。 このときのプロパティへのアクセスは、XPCNativeWrapper の wrappedJSObject を通して転送されます。 このことは、保護されていないスクリプトでは、 暗黙の XPCNativeWrapper によって想定外のコードが渡されることで、バグが発生することを心配する必要はないことを意味します。 また、そういったスクリプトからは、安全ではないオブジェクトへアクセスする場合は、用心する必要があることも意味します。 明示的な XPCNativeWrapper 上のプロパティにアクセスする場合は、呼び出し元
OpenSearch 記述形式 | MDN
<OpenSearchDescription xmlns="http://a9.com/-/spec/opensearch/1.1/" xmlns:moz="http://www.mozilla.org/2006/browser/search/"> <ShortName>[SNK]</ShortName> <Description>[Search engine full name and summary]</Description> <InputEncoding>[UTF-8]</InputEncoding> <Image width="16" height="16" type="image/x-icon">[https://example.com/favicon.ico]</Image> <Url type="text/html" template="[searchURL]"/> <Ur
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Build Documentation - Mozilla | MDN
Mork Structure - Mozilla | MDN