diff options
| author | Peter Bengtsson <mail@peterbe.com> | 2020-12-08 21:46:22 -0500 |
|---|---|---|
| committer | Peter Bengtsson <mail@peterbe.com> | 2020-12-08 21:46:22 -0500 |
| commit | a065e04d529da1d847b5062a12c46d916408bf32 (patch) | |
| tree | fe0f8bcec1ff39a3c499a2708222dcf15224ff70 /files/es/mozilla/firefox | |
| parent | 218934fa2ed1c702a6d3923d2aa2cc6b43c48684 (diff) | |
| download | translated-content-a065e04d529da1d847b5062a12c46d916408bf32.tar.gz translated-content-a065e04d529da1d847b5062a12c46d916408bf32.tar.bz2 translated-content-a065e04d529da1d847b5062a12c46d916408bf32.zip | |
update based on https://github.com/mdn/yari/issues/2028
Diffstat (limited to 'files/es/mozilla/firefox')
20 files changed, 0 insertions, 1683 deletions
diff --git a/files/es/mozilla/firefox/compilar_firefox_con_codigo_en_rust/index.html b/files/es/mozilla/firefox/compilar_firefox_con_codigo_en_rust/index.html deleted file mode 100644 index 76ea78e7b0..0000000000 --- a/files/es/mozilla/firefox/compilar_firefox_con_codigo_en_rust/index.html +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: Compilar Firefox con código en Rust -slug: Mozilla/Firefox/Compilar_Firefox_con_codigo_en_Rust -tags: - - Compilación - - Gecko - - rust -translation_of: Archive/Mozilla/Firefox/Building_Firefox_with_Rust_code ---- -<div>{{FirefoxSidebar}}</div><p>En mayo de 2015, <a href="https://www.rust-lang.org/">el lenguaje de programación Rust</a> alcanzó su objetivo de estabilidad 1.0 y se comenzaron diversos experimentos que consistieron en escribir partes de Gecko en Rust. Esta página contiene una guía de orientación aproximada para las personas que trabajan en esta área.</p> - -<p>Consulte el <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1135640">informe n.º 1135640</a> (<em>oxidation</em>) para ver el seguimiento integral de la integración de componentes en el lenguaje Rust.</p> - -<h2 id="Activación_del_código_en_Rust">Activación del código en Rust</h2> - -<p>Con el trabajo realizado en el <a class="bz_bug_link - bz_status_RESOLVED bz_closed" href="https://bugzilla.mozilla.org/show_bug.cgi?id=1161339" title="RESOLVED FIXED - Support rust files in moz.build SOURCES">informe n.º 1161339</a> se implementó compatibilidad básica para compilar código en Rust. Esta compatibilidad está activada para las compilaciones oficiales de la mayoría de las plataformas, con la excepción de las compilaciones que realice localmente. Si en su «path» tiene «rustc», puede añadir:</p> - -<pre>ac_add_options --enable-rust</pre> - -<p>… a su archivo <a href="/en-US/docs/Configuring_Build_Options">mozconfig</a> y la compilación probablemente funcionará. Normalmente apuntamos a versiones estables de Rust pero, en ocasiones, para admitir algunas plataformas nuevas se necesitan versiones especiales de las herramientas de compilación. Si aún no tiene Rust, utilice la herramienta «<a href="https://www.rustup.rs/">rustup</a>» para instalarlo.</p> - -<h2 id="Poner_a_prueba_el_código_en_Rust">Poner a prueba el código en Rust</h2> - -<p>En el árbol hay una sencilla prueba unitaria de vinculación. Es posible utilizarla para comprobar que Rust esté activado y funcione correctamente con su configuración de compilaciones.</p> - -<pre>./mach gtest rust.*</pre> - -<p>Revise que la prueba <strong>rust.CallFromCpp</strong> se supere, junto con cualquier otra que haya.</p> - -<h2 id="Adición_de_código_en_Rust">Adición de código en Rust</h2> - -<p>Para agregar código nuevo en Rust se requiere añadir el archivo .rs de nivel superior para agruparlo en un cajón (<em>crate</em>) de SOURCES en moz.build.</p> - -<p>Debido a límites de Cargo y al sistema de compilaciones de Firefox, por el momento solo admitimos cajones sencillos, sin dependencias. No empleamos Cargo, sino que creamos un archivo rlib a partir de todos los archivos rust enumerados en SOURCES. El compilador de Rust buscará los módulos internos según los nombres de archivo de código fuente, pero las referencias de <code>extern crate</code> no se resolverán.</p> - -<p>El sistema de compilaciones generará un cajón especial para una «biblioteca unificada de Rust», compilada como una biblioteca estática (<code>librul.a</code>) que a su vez se enlaza en <code>XUL</code>, de modo que todos sus símbolos públicos estén disponibles para el código en C++.</p> diff --git a/files/es/mozilla/firefox/edición_de_desarrollador/index.html b/files/es/mozilla/firefox/edición_de_desarrollador/index.html deleted file mode 100644 index 12642f7044..0000000000 --- a/files/es/mozilla/firefox/edición_de_desarrollador/index.html +++ /dev/null @@ -1,59 +0,0 @@ ---- -title: Edición de Desarrollador -slug: Mozilla/Firefox/Edición_de_Desarrollador -tags: - - Firefox - - Iniciado - - Lanzamiento -translation_of: Mozilla/Firefox/Developer_Edition ---- -<div>{{FirefoxSidebar}}</div><p style="text-align: center;"><img alt="" src="https://mdn.mozillademos.org/files/9143/firefox-dev-ed_logo-only_1024.png" style="display: block; height: 256px; margin-left: auto; margin-right: auto; width: 256px;">La versión de Firefox a la medida de los desarrolladores web. (Versión Actualizada)</p> - -<p><a href="https://download.mozilla.org/?product=firefox-aurora-latest-l10n&os=win&lang=es-ES" style="width: 250px; display: block; margin-left: auto; margin-right: auto; padding: 10px; text-align: center; border-radius: 4px; background-color: #81BC2E; white-space: nowrap; color: white; text-shadow: 0px 1px 0px rgba(0, 0, 0, 0.25); box-shadow: 0px 1px 0px 0px rgba(0, 0, 0, 0.2), 0px -1px 0px 0px rgba(0, 0, 0, 0.3) inset;">Descarga Firefox Developer Edition </a></p> - -<hr> -<div class="column-container"> -<div class="column-half"> -<h3 id="Las_últimas_funciones_de_Firefox"><strong>Las últimas funciones de Firefox</strong></h3> - -<p>Firefox Developer Edition sustituye al canal Aurora en el <a href="https://wiki.mozilla.org/Release_Management/Release_Process">Proceso de lanzamiento de versiones de Firefox</a>. En Developer Edition, como en Aurora, las caracteristicas se lanzan cada seis semanas, despues de que se hayan estabilizado en Nightly builds.</p> - -<p>Utilizando Firefox Developer Edition, tienes acceso a las herramientas y a las caracteristicas de la plataforma al menos 12 semanas antes de que lleguen a alcanzar el canal principal de lanzamiento Firefox.</p> - -<p><a href="/en-US/Firefox/Releases/35">Descubre las novedades de Firefox Developer Edition.</a><a href="https://developer.mozilla.org/en-US/Firefox/Releases/52">.</a></p> -</div> - -<div class="column-half"> -<h3 id="Herramientas_de_Desarrollo_Experimentales"><strong>Herramientas de Desarrollo Experimentales</strong></h3> - -<p>Incluiremos herramientas de desarrollo que aún no están todavía del todo listas para ser lanzadas en la versión final de Firefox. Por ejemplo <a href="https://developer.mozilla.org/es/docs/Tools/Valence">Valence add-on (Adaptador de Herramientas Firefox) </a>, la cual te permite conectar las <a href="https://developer.mozilla.org/es/docs/Tools">Herramientas de Desarrollo Firefox</a> con las de otros navegadores , como Chrome en android o Safari en IOS.</p> -</div> -</div> - -<div class="column-container"> -<div class="column-half"> -<h3 id="Un_Perfil_Separado"><strong>Un Perfil Separado</strong></h3> - -<p>Firefox Developer Edition utiliza un perfil separado de las otras versiones de Firefox instaladas en tu ordenador. Esto hace que puedas intercambiar más facilmente entre las versiones ya lanzadas o las betas de Firefox.</p> -</div> - -<div class="column-half"> -<h3 id="Configuración_para_Desarrolladores_Web"><strong>Configuración para Desarrolladores Web</strong></h3> - -<p><span id="result_box" lang="es"><span>Hemos establecido valores de preferencia predeterminados adaptados a los desarrolladores web.</span> <span>Por ejemplo, {{glossary ("chrome")}} y depuración remota están habilitados de forma predeterminada.</span></span></p> -</div> -</div> - -<div class="column-container"> -<div class="column-half"> -<h3 id="Una_Apariencia_Distinta"><strong>Una Apariencia Distinta</strong></h3> - -<p>Incluidos accesos directos a las herramientas de desarrollo</p> -</div> - -<div class="note"> -<div dir="ltr" style="zoom: 1;"><span id="result_box" lang="es"><span><strong>Nota</strong>: Esto significa que la primera vez que inicie Developer Edition, verá un navegador totalmente no personalizado, sin complementos, marcadores o historial.</span> <span>Puedes <a href="https://support.mozilla.org/es/kb/como-configuro-firefox-sync?redirectlocale=en-US&redirectslug=how-do-i-set-up-firefox-sync">utilizar Firefox Sync</a> si quieres unificar tu configuración entre Developer Edition y otras ediciones de Firefox.</span></span></div> -</div> -</div> - -<p> </p> diff --git a/files/es/mozilla/firefox/edición_de_desarrollador/revertir/index.html b/files/es/mozilla/firefox/edición_de_desarrollador/revertir/index.html deleted file mode 100644 index a4df9a3ba6..0000000000 --- a/files/es/mozilla/firefox/edición_de_desarrollador/revertir/index.html +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: Revertir -slug: Mozilla/Firefox/Edición_de_Desarrollador/Revertir -translation_of: Mozilla/Firefox/Developer_Edition/Reverting ---- -<div>{{FirefoxSidebar}}</div><h2 id="Revertir_el_tema_Firefox_Developer_Edition">Revertir el tema Firefox Developer Edition</h2> - -<p><br> - Si quieres usar Firefox Developer Edition, pero prefieres el tema 'Australis' usado en Firefox y Firefox Beta, puedes cambiarlo: simplemente abre el panel "Personalizar" y haz clic en el botón "Usar el tema Firefox Developer Edition".</p> - -<p>{{EmbedYouTube("OvJwofTjsNg")}}</p> - -<p>Ten en cuenta que el tema Firefox Developer Edition no es aún compatible con temas ligeros. Si quieres usar un tema ligero, tendrás que volver al tema 'Australis'.</p> - -<h2 id="Revertir_a_Firefox_Aurora">Revertir a Firefox Aurora</h2> - -<p><br> - Si quieres disfrutar de todas las características pre-Beta de Firefox Developer Edition, descartando el resto de cambios, puedes revertir el navegador a algo parecido al viejo Firefox Aurora. Esto también restaurará tu perfil y datos de sesión previos a la actualización. Es un proceso de dos pasos, que debes de seguir en este orden:</p> - -<ol> - <li>Abre Preferencias y desmarca la opción "Permitir a Firefox Developer Edition y Firefox ejecutarse al mismo tiempo". Se te avisará de que es necesario reiniciar el navegador.</li> - <li>Tras reiniciar, podrás revertir la aplicación del tema Firefox Developer Edition abriendo el panel "Personalizar" y haciendo clic en el botón "Usar el tema Firefox Developer Edition".</li> -</ol> - -<p> </p> diff --git a/files/es/mozilla/firefox/firefox_esr/index.html b/files/es/mozilla/firefox/firefox_esr/index.html deleted file mode 100644 index af8625e1c3..0000000000 --- a/files/es/mozilla/firefox/firefox_esr/index.html +++ /dev/null @@ -1,13 +0,0 @@ ---- -title: Firefox ESR -slug: Mozilla/Firefox/Firefox_ESR -tags: - - Necesita revisión -translation_of: Mozilla/Firefox/Firefox_ESR ---- -<div>{{FirefoxSidebar}}</div> - -<p><em>Firefox Extended Support Release (ESR)</em> se basa en una versión oficial de Firefox para el escritorio para su uso por organizaciones que necesitan soporte extendido para implementaciones masivas. La diferencia de otros canales de lanzamiento, las ESR no se actualizan con nuevas características cada seis semanas. En su lugar, son compatibles durante alrededor de un año, actualizándose con importantes soluciones de seguridad o estabilidad. La versión actual de ESR es basa en Firefox 52 emitida el 7 de marzo de 2017. La próxima versión de ESR será el número 59.<br> - <br> - <br> - Animamos firmemente a los usuarios de Firefox ESR que se inscriban en la lista de correo del grupo <em><a href="https://www.mozilla.org/en-US/firefox/organizations/">Enterprise Working Group (EWG)</a></em>.</p> diff --git a/files/es/mozilla/firefox/multiprocess_firefox/index.html b/files/es/mozilla/firefox/multiprocess_firefox/index.html deleted file mode 100644 index 139a345752..0000000000 --- a/files/es/mozilla/firefox/multiprocess_firefox/index.html +++ /dev/null @@ -1,75 +0,0 @@ ---- -title: Firefox multiproceso -slug: Mozilla/Firefox/Multiprocess_Firefox -translation_of: Mozilla/Firefox/Multiprocess_Firefox ---- -<div>{{FirefoxSidebar}}</div><p>En las versiones actuales de Firefox para escritorio, todo el navegador se ejecuta en un solo proceso del sistema operativo. Esto quiere decir que el código JavaScript que ejecuta la IU (interfaz de usuario) del navegador (también conocido como "código chrome") se ejecuta en el mismo proceso que el código de las página web (también conocido como "contenido" o "contenido web").<br> - <br> - Las versiones futuras de Firefox ejecutarán la interfaz de usuario del navegador en un proceso separado del contenido web. En la primera etapa de esta arquitectura, todas las pestañas del navegador se ejecutarán en el mismo proceso y la IU del navegador en un proceso diferent. En futuras etapas, esperamos tener más de un proceso de contenido. El proyecto de Firefox multiproceso es llamado Electrolysis, en ocasiones abreviado como e10s.</p> - -<p>Las páginas web normales no estarán afectadas por Firefox multiproceso. Quienes trabajen en Firefox en sí mismo y desarrolladores de complementos para Firefox estarán afectados si su código se basa en acceder al contenido web directamente.</p> - -<p>En lugar de acceder al contenido web directamente, el código JavaScript deberá usar el <a href="/Firefox/Multiprocess_Firefox/Message_manager">administrador de mensajes</a> para acceder al contenido. Para facilitar la transición hemos implementado <a href="/Firefox/Multiprocess_Firefox/Cross_Process_Object_Wrappers">contenedores de objetos de multiproceso</a> y algunas <a href="/Firefox/Multiprocess_Firefox/Limitations_of_chrome_scripts#Compatibility_shims">capas de compatibilidad para complementos</a>. Si eres un desarrollador de complementos y deseas saber cómo estrás afectado, revisa la <a href="/Mozilla/Add-ons/Working_with_multiprocess_Firefox">guía para trabajar con Firefox multiproceso</a>.</p> - -<hr> -<div class="column-container"> -<div class="column-half"> -<dl> - <dt><a href="/Firefox/Multiprocess_Firefox/Technical_overview">Repaso técnico</a></dt> - <dd>Una vista de alto nivel acerca de cómo se está implementando Firefox multiproceso.</dd> - <dt><a href="/en-US/Firefox/Multiprocess_Firefox/Web_content_compatibility">Guía de compatibilidad para contenido web</a></dt> - <dd>Directrices y detalles acerca de problemas potenciales de compatiblidad en sitios web que podrían ocurrir debido a la transición. Tip: ¡No son muchos!</dd> - <dt><a href="/Firefox/Multiprocess_Firefox/Glossary">Glosario</a></dt> - <dd>Una referencia de la jerga usada en Firefox multiproceso.</dd> - <dt><a href="/Firefox/Multiprocess_Firefox/Message_Manager">Administrador de mensajes</a></dt> - <dd>Una guía completa a los objetos usados para comunicarse entre el código chrome y el contenido.</dd> - <dt><a href="/en-US/Mozilla/Add-ons/SDK/Guides/Multiprocess_Firefox_and_the_SDK">Complementos basados en el SDK</a></dt> - <dd>Cómo migrar complementos creados utilizando el SDK de complementos.</dd> - <dt><a href="/Firefox/Multiprocess_Firefox/Which_URIs_load_where">Dónde se carga cada URI</a></dt> - <dd>Una guía rápida a qué URIs - chrome:, about:, file:, resource: - se cargan en cada proceso.</dd> -</dl> -</div> - -<div class="column-half"> -<dl> - <dt><a href="/Firefox/Multiprocess_Firefox/Motivation">Motivación</a></dt> - <dd>Por qué estamos implementando Firefox multiproceso: rendimiento, seguridad y estabilidad.</dd> - <dt><a href="/Mozilla/Add-ons/Working_with_multiprocess_Firefox">Guía para la migración de complementos</a></dt> - <dd>Si eres un desarollador de complementos, entérate cómo estás afectado y cómo actualizar tu código.</dd> - <dt><a href="/Firefox/Multiprocess_Firefox/Cross_Process_Object_Wrappers">Contenedores de objetos multiproceso</a></dt> - <dd>Los contenedores de objetos multiproceso ayudan a la migración, dando al código chrome acceso síncrono al contenido.</dd> - <dt><a href="/Firefox/Multiprocess_Firefox/Debugging_frame_scripts">Depurando procesos de firefox</a></dt> - <dd>Cómo depurar código en el proceso de contenido, incluyendo scripts de marco y proceso.</dd> - <dt><a href="/docs/Mozilla/Firefox/Multiprocess_Firefox/Tab_selection_in_multiprocess_Firefox">Selección de pestañas en Firefox multiproceso</a></dt> - <dd>Cómo funciona el cambio de pestañas en Firefox multiproceso.</dd> -</dl> -</div> -</div> - -<hr> -<div class="column-container"> -<div class="column-half"> -<dl> - <dt><a href="/Firefox/Multiprocess_Firefox/Limitations_of_chrome_scripts">Limitaciones de los scripts chrome</a></dt> - <dd>Prácticas que ya no funcionan en el código chrome, y cómo solucionarlas.</dd> -</dl> -</div> - -<div class="column-half"> -<dl> - <dt><a href="/Firefox/Multiprocess_Firefox/Limitations_of_frame_scripts">Limitaciones de los scripts de marco</a></dt> - <dd>Prácticas que no funcionarán en los scripts de marco, y qué hacer en su lugar.</dd> -</dl> -</div> -</div> - -<hr> -<h2 id="Contáctanos">Contáctanos</h2> - -<p>Entérate más acerca del proyecto, involúcrate o pregúntanos tus dudas.</p> - -<ul> - <li><strong>Página del proyecto Electrolysis</strong>: <a href="https://wiki.mozilla.org/Electrolysis">https://wiki.mozilla.org/Electrolysis</a></li> - <li><strong>IRC</strong>: #e10s en <a href="https://wiki.mozilla.org/IRC">irc.mozilla.org</a></li> - <li><strong>Lista de correo</strong>: <a href="https://groups.google.com/forum/#!forum/mozilla.dev.tech.electrolysis">dev.tech.electrolysis</a></li> -</ul> diff --git a/files/es/mozilla/firefox/multiprocess_firefox/message_manager/index.html b/files/es/mozilla/firefox/multiprocess_firefox/message_manager/index.html deleted file mode 100644 index 5d3214a425..0000000000 --- a/files/es/mozilla/firefox/multiprocess_firefox/message_manager/index.html +++ /dev/null @@ -1,74 +0,0 @@ ---- -title: Message manager -slug: Mozilla/Firefox/Multiprocess_Firefox/Message_Manager -tags: - - API - - Guide - - JavaScript - - NeedsTranslation - - TopicStub -translation_of: Mozilla/Firefox/Multiprocess_Firefox/Message_Manager ---- -<div>{{FirefoxSidebar}}</div><p>Message managers provide a way for chrome-privileged JavaScript code to communicate across process boundaries. They are particularly useful for allowing chrome code, including the browser's code and extension's code, to access web content while the browser is running web content in a separate process.</p> - -<p>These guides explain how to use message managers in multiprocess Firefox.</p> - -<p>Note that none of this requires multiprocess Firefox: everything described here will work with single-process Firefox, so the same code will work on both variants.</p> - -<hr> -<h2 id="Guides">Guides</h2> - -<div class="column-container"> -<div class="column-half"> -<dl> - <dt><a href="/en-US/Firefox/Multiprocess_Firefox/Message_Manager/Message_manager_overview">Message manager overview</a></dt> - <dd> </dd> - <dt><a href="/en-US/Firefox/Multiprocess_Firefox/Message_Manager/Frame_script_loading_and_lifetime">Frame script loading and lifetime</a></dt> - <dd> </dd> - <dt><a href="/en-US/Firefox/Multiprocess_Firefox/Message_Manager/Communicating_with_frame_scripts">Communicating with frame scripts</a></dt> - <dd> </dd> - <dt><a href="/en-US/Firefox/Multiprocess_Firefox/Message_Manager/Performance">Performance Best Practices</a></dt> - <dd> </dd> -</dl> -</div> - -<div class="column-half"> -<dl> - <dt><a href="/en-US/Firefox/Multiprocess_Firefox/Message_Manager/Frame_script_environment">Frame script environment</a></dt> - <dd> </dd> - <dt><a href="/en-US/Firefox/Multiprocess_Firefox/Message_Manager/_Limitations_of_frame_scripts">Limitations of frame scripts</a></dt> - <dd> </dd> - <dt><a href="/en-US/Firefox/Multiprocess_Firefox/Message_Manager/Process_scripts">Process scripts</a></dt> - <dd> </dd> -</dl> -</div> -</div> - -<hr> -<h2 id="API_reference">API reference</h2> - -<div class="column-container"> -<div class="column-half"> -<dl> - <dt><a href="/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIFrameScriptLoader">nsIFrameScriptLoader</a></dt> - <dd> </dd> - <dt><a href="/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIMessageListenerManager">nsIMessageListenerManager</a></dt> - <dd> </dd> - <dt><a href="/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIMessageBroadcaster">nsIMessageBroadcaster</a></dt> - <dd> </dd> - <dt><a href="/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIMessageSender">nsIMessageSender</a></dt> - <dd> </dd> -</dl> -</div> - -<div class="column-half"> -<dl> - <dt><a href="/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsISyncMessageSender">nsISyncMessageSender</a></dt> - <dd> </dd> - <dt><a href="/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIContentFrameMessageManager">nsIContentFrameMessageManager</a></dt> - <dd> </dd> - <dt><a href="/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIProcessScriptLoader">nsIProcessScriptLoader</a></dt> - <dd> </dd> -</dl> -</div> -</div> diff --git a/files/es/mozilla/firefox/multiprocess_firefox/message_manager/process_scripts/index.html b/files/es/mozilla/firefox/multiprocess_firefox/message_manager/process_scripts/index.html deleted file mode 100644 index f6011c7836..0000000000 --- a/files/es/mozilla/firefox/multiprocess_firefox/message_manager/process_scripts/index.html +++ /dev/null @@ -1,81 +0,0 @@ ---- -title: Process scripts -slug: Mozilla/Firefox/Multiprocess_Firefox/Message_Manager/Process_scripts -tags: - - Necesita traducción -translation_of: Mozilla/Firefox/Multiprocess_Firefox/Message_Manager/Process_scripts ---- -<div>{{FirefoxSidebar}}</div><div class="geckoVersionNote"> -<p>Los scripts de proceso son nuevos en Firefox 38.</p> -</div> - -<div class="note"> -<p>Si esta utilizando el addon sdk, puede utilizar el <a href="/en-US/docs/Mozilla/Add-ons/SDK/Low-Level_APIs/remote_parent">remote/parent</a> módulo <code>remoteRequire</code> en su lugar.</p> -</div> - -<p><span id="result_box" lang="es"><span>Cuando necesite ejecutar código en el proceso de contenido para acceder al contenido web, debe utilizar secuencias de</span></span> frame scripts. <span id="result_box" lang="es"><span>Sin embargo, un problema con</span></span> los scripts <span id="result_box" lang="es"><span>es que se pueden cargar varias veces en el proceso de contenido, en varios ámbitos que están aislados unos de otros.</span> <span>Por ejemplo, si llama a la funcion </span></span><code>loadFrameScript()</code> del gestor de mensajes de script, <span id="result_box" lang="es"><span>entonces el script se cargará por separado en todas las pestañas abiertas.</span> <span>Esto puede causar un problema que las secuencias de scripts de trama están interactuando con un servicio global en el proceso de contenido.</span></span></p> - -<p><span id="result_box" lang="es"><span>Por ejemplo, en multiprocesos Firefox, si necesita usar</span></span> <code><a href="/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIContentPolicy">nsIContentPolicy</a></code> to register a content policy, <a href="/en-US/Firefox/Multiprocess_Firefox/Limitations_of_chrome_scripts#nsIContentPolicy">you must do this in the content process</a>. <span id="result_box" lang="es"><span>para registrar una política de contenido, debe hacerlo en el proceso de contenido.</span> <span>Pero si lo registra en una secuencia de frame script la secuencia de frame script se carga más de una vez, registrará la política de contenido más de una vez, lo que probablemente no es lo que pretende.</span></span></p> - -<p>De forma similar, algunas notificaciones de observadores deben registrarse en el frame script, pero si lo hace en una secuencia de frame scrip, se cargara más de una vez, recibirá varias notificaciones, para ese evento.</p> - -<p><span id="result_box" lang="es"><span>La solución en estos casos es usar un script de proceso en lugar de un frame script.</span></span></p> - -<p>You can load a process script by accessing a <a href="/en-US/Firefox/Multiprocess_Firefox/Message_Manager/Message_manager_overview#Parent_process">parent process message manager</a> and calling its <code><a href="/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIProcessScriptLoader#loadProcessScript()">loadProcessScript()</a></code> function. The following code uses the global parent process message manager, which will load the script into the the chrome process and any child processes:</p> - -<pre class="brush: js">// chrome code -let ppmm = Cc["@mozilla.org/parentprocessmessagemanager;1"] - .getService(Ci.nsIProcessScriptLoader); -ppmm.loadProcessScript("chrome://whatever/process-script.js", true); -ppmm.addMessageListener("Hello", function(msg) { ... });</pre> - -<p>The process script's global is a <a href="/en-US/Firefox/Multiprocess_Firefox/Message_Manager/Message_manager_overview#Child_process_message_manager">child process message manager</a>, which enables the process script to receive messages from the chrome side, and to send messages to the chrome side:</p> - -<pre class="brush: js">// process-script.js -if (Services.appinfo.processType == Services.appinfo.PROCESS_TYPE_CONTENT) { - dump("Welcome to the process script in a content process"); -} else { - dump("Welcome to the process script in the main process"); -} - -// Message is sent using <code>ContentProcessMessageManager</code> -sendAsyncMessage("Hello");</pre> - -<p>In this example, the <code>dump()</code> statement will run once in each content process as well as in the main process. This example also figures out whether it is running in the chrome or in a content process by looking at the <a href="/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIXULRuntime#Process_type_constants">process type</a> in <code><a href="/en-US/docs/Mozilla/JavaScript_code_modules/Services.jsm">Services.appinfo</a></code>.</p> - -<p>In just about every respect, using process scripts is like using frame scripts:</p> - -<ul> - <li>you can pass the allowDelayedLoad to <code><a href="https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIProcessScriptLoader#loadProcessScript()">loadProcessScript()</a></code>. If you do, you must call <code><a href="/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIProcessScriptLoader#removeDelayedProcessScript()">removeDelayedProcessScript()</a></code> when your extension is disabled or removed</li> - <li>the message-passing APIs are the same: <code><a href="https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIMessageSender#sendAsyncMessage()">sendAsyncMessage()</a></code> is available in both directions, while <code><a href="https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsISyncMessageSender#sendSyncMessage()">sendSyncMessage()</a></code> is available from content to chrome only</li> - <li>process scripts are system-privileged, and have access to the <code><a href="/en-US/docs/Components_object">Components</a></code> object. However, process scripts are subject to <a href="/en-US/Firefox/Multiprocess_Firefox/Limitations_of_frame_scripts">the same kinds of limitations as frame scripts</a> (for example, no file system access).</li> - <li>process scripts stay loaded until their host process is closed.</li> - <li>the environment for process scripts is similar to that for frame scripts. However, you don't get access to web content or DOM events from a process script.</li> -</ul> - -<h2 id="Retrieving_the_content_frame_message_manager_for_a_content_window">Retrieving the content frame message manager for a content window</h2> - -<p>When an observer notification in a process script contains a content document or window it can be useful to not use talk through the child/parent process message managers but through the window's content frame message manager, e.g. if responses should be processed by a frame script instead of the process script.</p> - -<p>This can be achieved by traversing the docshell tree up to the top window and then retrieving its content message manager, as follows:</p> - -<pre class="brush: js">function contentMMFromContentWindow(window) { - let tree = window.QueryInterface(Ci.nsIInterfaceRequestor).getInterface(Ci.<span class="pl-c1">nsIDocShellTreeItem</span>); - let top = tree.sameTypeRootTreeItem; - let iface = QueryInterface(Ci.nsIDocShell).QueryInterface(Ci.nsIInterfaceRequestor); - return iface.getInterface(Ci.nsIContentFrameMessageManager); -} -</pre> - -<div class="note"> -<p>This is intended for unprivileged pages running in a content process. Chrome-privileged pages or things running in the parent process may require special treatment.</p> -</div> - -<p>If the above doesn't work try this:</p> - -<pre class="brush: js">function contentMMFromContentWindow_Method2(aContentWindow) { - return aContentWindow.QueryInterface(Ci.nsIInterfaceRequestor) - .getInterface(Ci.nsIDocShell) - .QueryInterface(Ci.nsIInterfaceRequestor) - .getInterface(Ci.nsIContentFrameMessageManager); -}</pre> diff --git a/files/es/mozilla/firefox/multiprocess_firefox/motivation/index.html b/files/es/mozilla/firefox/multiprocess_firefox/motivation/index.html deleted file mode 100644 index 0a4f0cb3e6..0000000000 --- a/files/es/mozilla/firefox/multiprocess_firefox/motivation/index.html +++ /dev/null @@ -1,46 +0,0 @@ ---- -title: Motivation -slug: Mozilla/Firefox/Multiprocess_Firefox/Motivation -tags: - - Necesita traducción -translation_of: Mozilla/Firefox/Multiprocess_Firefox/Motivation ---- -<div>{{FirefoxSidebar}}</div><p>There are three main reasons for making Firefox run content in a separate process: performance, security, and stability.</p> - -<h2 id="Performance">Performance</h2> - -<p>Most performance work at Mozilla over the last two years has focused on responsiveness of the browser. The goal is to reduce “<a href="/en-US/docs/Glossary/Jank">jank</a>”—those times when the browser seems to briefly freeze when loading a big page, typing in a form, or scrolling. Responsiveness tends to matter a lot more than throughput on the web today. Much of this work has been done as part of the <a href="https://wiki.mozilla.org/Performance/Snappy">Snappy project</a>. The main focuses have been:</p> - -<ul> - <li>Moving long-running actions to a separate thread so that the main thread can continue to respond to the user.</li> - <li>Doing I/O asynchronously or on other threads so that the main thread isn’t blocked waiting for the disk.</li> - <li>Breaking long-running code into shorter pieces and running the event loop in between. Incremental garbage collection is an example of this.</li> -</ul> - -<p>Much of the low-hanging fruit in these areas has already been picked. The remaining issues are difficult to fix. For example, JavaScript execution and layout happen on the main thread, and they block the event loop. Running these components on a separate thread is difficult because they access data, like the DOM, that are not thread-safe. As an alternative, we’ve considered allowing the event loop to run in the middle of JavaScript execution, but doing so would break a lot of assumptions made by other parts of Firefox (not to mention add-ons).</p> - -<p>Running web content in a separate process is a nice alternative to these approaches. Like the threaded approach, Firefox is able to run its event loop while JavaScript and layout are running in a content process. But unlike threading, the UI code has no access to content DOM or or other content data structures, so there is no need for locking or thread-safety. The downside, of course, is that any code in the Firefox UI process that needs to access content data must do so explicitly through message passing.</p> - -<p>We feel this tradeoff makes sense for a few reasons:</p> - -<ul> - <li>It’s not all that common for Firefox code to access content DOM.</li> - <li>Code that is shared with Firefox OS already uses message passing.</li> - <li>In the multiprocess model, Firefox code that fails to use message passing to access content will fail in an obvious, consistent way. In the threaded model, code that accesses content without proper locking will fail in subtle ways that are difficult to debug.</li> -</ul> - -<h2 id="Security">Security</h2> - -<p>Right now, if someone discovers an exploitable bug in Firefox, they’re able to take over users’ computers. There are a lot of techniques to mitigate this problem, but one of the most powerful is <a href="http://en.wikipedia.org/wiki/Sandbox_%28computer_security%29">sandboxing</a>. Technically, sandboxing doesn’t require multiple processes. However, a sandbox that covered single-process Firefox wouldn’t be very useful. Sandboxes are only able to prevent processes from performing actions that a well-behaved process would never do. Unfortunately, a well-behaved Firefox process (especially one with add-ons installed) needs access to much of the network and file system. Consequently, a sandbox for single-process Firefox couldn’t restrict much.</p> - -<p>In multiprocess Firefox, content processes will be sandboxed. A well-behaved content process won’t access the filesystem directly; it will have to ask the main process to perform the request. At that time, the main process can verify that the request is safe and that it makes sense. Consequently, the sandbox for content processes can be quite restrictive. Our hope is that this arrangement will make it much harder to craft exploitable security holes for Firefox.</p> - -<h2 id="Stability">Stability</h2> - -<p>Currently, a crash in the code running a web page will take down the entire browser. With multiprocess Firefox, only the content process that crashed will be killed.</p> - -<div class="note"> -<p>This page incorporates a lot of content from Bill McCloskey's blog post on multiprocess Firefox: <a href="http://billmccloskey.wordpress.com/2013/12/05/multiprocess-firefox/">http://billmccloskey.wordpress.com/2013/12/05/multiprocess-firefox/</a></p> -</div> - -<p> </p> diff --git a/files/es/mozilla/firefox/multiprocess_firefox/pitfalls_for_add-on_developers/index.html b/files/es/mozilla/firefox/multiprocess_firefox/pitfalls_for_add-on_developers/index.html deleted file mode 100644 index 4f109bf795..0000000000 --- a/files/es/mozilla/firefox/multiprocess_firefox/pitfalls_for_add-on_developers/index.html +++ /dev/null @@ -1,212 +0,0 @@ ---- -title: Pitfalls for add-on developers -slug: Mozilla/Firefox/Multiprocess_Firefox/Pitfalls_for_add-on_developers -tags: - - Necesita traducción -translation_of: Mozilla/Firefox/Multiprocess_Firefox/Pitfalls_for_add-on_developers ---- -<div>{{FirefoxSidebar}}</div><h2 id="Overview">Overview</h2> - -<p>This page lists patterns that add-on authors might be using that won't work, or will work differently, in multiprocess Firefox.</p> - -<p>It's split into two sections: chrome process and content process.</p> - -<h3 id="Chrome_process">Chrome process</h3> - -<p>The first section, <em>chrome process</em>, covers things that used to work in the chrome process that will no longer work in multiprocess Firefox. These are the sorts of things that will break an old add-on in multiprocess Firefox. The fix is generally some variant of "do that in a frame script loaded into the content process".</p> - -<h4 id="Compatibility_shims">Compatibility shims</h4> - -<p>For many of the patterns described here we've implemented compatibility shims so the patterns still work. For example: whenever extensions try to access web content from the chrome process, the browser will return a <a href="https://developer.mozilla.org/en-US/docs/Cross_Process_Object_Wrappers">Cross Process Object Wrapper</a> that gives the chrome code synchronous access to the content.</p> - -<p>You'll get the shims for your add-on by default, unless you set the <a href="/en-US/Add-ons/Install_Manifests#multiprocessCompatible"><code>multiprocessCompatible</code> flag in your add-on's install manifest</a>.</p> - -<p>However, these shims are not a substitute for migrating extensions:</p> - -<ul> - <li>they are only a temporary measure, and will be removed eventually</li> - <li>they can have a bad effect on responsiveness</li> - <li>there are likely to be edge cases in which they don't work properly</li> -</ul> - -<p>For each pattern we've noted:</p> - -<ul> - <li>whether a shim exists and what kind of behavior it provides</li> - <li>how to update your add-on so you don't need the shim</li> -</ul> - -<h3 id="Content_process">Content process</h3> - -<p>However, some things that used to work in a chrome process will not work in the content process. The second section, <em>content process</em>, lists these sorts of things along with their mitigation.</p> - -<h2 id="Chrome_process_pitfalls">Chrome process pitfalls</h2> - -<h3 id="gBrowser.contentWindow_window.content...">gBrowser.contentWindow, window.content...</h3> - -<h4 id="Without_the_shim">Without the shim</h4> - -<p>All APIs in the chrome process that provide direct access to content objects will no longer work. For example:</p> - -<pre class="brush: js">// chrome code - -gBrowser.contentWindow; // null - -gBrowser.contentDocument; // null - -gBrowser.selectedBrowser.contentWindow; // null - -window.content; // null - -content; // null -</pre> - -<h4 id="With_the_shim">With the shim</h4> - -<p>The shim will give you a <a href="/en-US/Firefox/Multiprocess_Firefox/Cross_Process_Object_Wrappers">CPOW</a> for the content object in these situations.</p> - -<p>To make the shim unnecessary: factor the code that needs to access content into a separate script, load that script into the content process as a frame script, and communicate between the chrome script and the frame script using the message-passing APIs. See the article on <a href="/en-US/Firefox/Multiprocess_Firefox/The_message_manager">using the message manager</a>.</p> - -<h3 id="nsIContentPolicy">nsIContentPolicy</h3> - -<h4 id="Without_the_shim_2">Without the shim</h4> - -<p>Under multiprocess Firefox you can't use <a href="http://dxr.mozilla.org/mozilla-central/source/dom/base/nsIContentPolicy.idl"><code>nsIContentPolicy</code></a> in the chrome process, because it needs to touch web content.</p> - -<h4 id="With_the_shim_2">With the shim</h4> - -<p>The shim enables you to add content policies in the chrome process. It transparently registers an <code>nsIContentPolicy</code> in the content process, whose <code>shouldLoad</code> just forwards to the chrome process. The content to check is forwarded as a <a href="/en-US/Firefox/Multiprocess_Firefox/Cross_Process_Object_Wrappers">CPOW</a>. The chrome process then checks the content against the policy supplied by the add-on, and forwards the response back to the child to be enforced.</p> - -<p>To make the shim unnecessary: define and register <code>nsIContentPolicy</code> inside a <a href="/en-US/Firefox/Multiprocess_Firefox/The_message_manager">frame script</a>.</p> - -<h3 id="Observers_in_the_chrome_process">Observers in the chrome process</h3> - -<p>Depending on the topic, you need to register observers in either the chrome process or in a frame script.</p> - -<p>For most topics you need to register observers in the chrome process.</p> - -<p>However, you must listen to <a href="/en/docs/Observer_Notifications#Documents"><code>content-document-global-created</code> and <code>document-element-inserted</code></a> in a frame script. <a href="http://dxr.mozilla.org/mozilla-central/source/xpcom/ds/nsIObserver.idl">Observers</a> for these topics get content objects as the <code>aSubject</code> argument to <code>observe()</code>, so notifications are not sent to the chrome process.</p> - -<p>There is a shim that will forward these two topics to the chrome process, sending <a href="/en-US/Firefox/Multiprocess_Firefox/Cross_Process_Object_Wrappers">CPOWs</a> as the <code>aSubject</code> argument.</p> - -<h4 id="HTTP_requests">HTTP requests</h4> - -<p>You can't observe <a href="https://developer.mozilla.org/en/docs/Observer_Notifications#HTTP_requests">HTTP requests</a> in the content process. If you do, you'll get an error.<br> - <br> - If you do so in the chrome process, it will mostly work. The subject for the observer notification will be an <code><a href="http://dxr.mozilla.org/mozilla-central/source/netwerk/protocol/http/nsIHttpChannel.idl">nsIHttpChannel</a></code> as you would expect. A common pattern here is to use the <code>notificationCallbacks</code> property of the <code>nsIHttpChannel</code> to get the DOM window that initiated the load, like this:</p> - -<pre class="brush: js">observe: function (subject, topic, data) { - if (topic == "http-on-modify-request") { - var httpChannel = subject.QueryInterface(Ci.nsIHttpChannel); - var domWindow = httpChannel.notificationCallbacks.getInterface(Ci.nsIDOMWindow); - } -}</pre> - -<p>Or this:</p> - -<pre class="brush: js">observe: function (subject, topic, data) { - if (topic == "http-on-modify-request") { - var httpChannel = subject.QueryInterface(Ci.nsIHttpChannel); - var domWindow = httpChannel.notificationCallbacks.getInterface(Ci.nsILoadContext).associatedWindow; - } -}</pre> - -<p>In multiprocess Firefox these patterns will no longer work: the <code>getInterface</code> call will fail.</p> - -<p>In multiprocess Firefox, <code>notificationCallbacks</code> is a special object that tries to emulate the single-process <code>notificationsCallbacks</code> object as best it can. It will return a dummy <code>nsILoadContext</code> when asked, but any attempt to get a window out of it will fail.<br> - <br> - There is an outstanding bug (<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1108827">bug 1108827</a>) to implement a shim here, that will make <code>notificationCallbacks</code> a <a href="/en-US/Firefox/Multiprocess_Firefox/Cross_Process_Object_Wrappers">CPOW</a> for the objects in the content process.</p> - -<h3 id="DOM_Events">DOM Events</h3> - -<h4 id="Without_the_shim_3">Without the shim</h4> - -<p>In multiprocess Firefox, if you want to register an event listener on some content DOM node, that needs to happen in the content process.</p> - -<p>It used to be that if you registered a listener on the <a href="/en-US/docs/XUL/browser">XUL <code><browser></code></a> or <a href="/en-US/docs/XUL/tab"><code><tab></code></a> element that hosted some DOM content, then events in the content would bubble up to the XUL and you could handle them there. This no longer happens in multiprocess Firefox.</p> - -<h4 id="With_the_shim_3">With the shim</h4> - -<p>The shim intercepts chrome process code that adds listeners to XUL elements and sets up listeners in the content process, relaying the result back to the chrome process. The <a href="/en-US/docs/Web/API/Event"><code>Event</code></a> object itself is relayed to the chrome process as a <a href="/en-US/Firefox/Multiprocess_Firefox/Cross_Process_Object_Wrappers">CPOW</a>.</p> - -<p>To make the shim unnecessary: register event listeners on the global object inside a <a href="/en-US/Firefox/Multiprocess_Firefox/The_message_manager">frame script</a>. For example:</p> - -<pre class="brush: js">addEventListener("load", handler, true) // for example</pre> - -<div>If you need to contact the chrome process when that happens, send it a message.</div> - -<div> </div> - -<h2 id="Content_process_pitfalls">Content process pitfalls</h2> - -<p>Many privileged APIs will just work in a content process. Anything that just manipulates data structures will just work. XHR and Workers will work.</p> - -<h3 id="File_IO">File I/O</h3> - -<p>You should not write to or read from the disk from a frame script, in particular the profile directory. Even if this is possible, you should not do it and may expect that it could stop working at any time. File I/O should all be done in the chrome process. For example:</p> - -<ul> - <li><a href="http://dxr.mozilla.org/mozilla-central/source/netwerk/base/public/nsIFileStreams.idl"><code>nsIFileInputStream</code></a></li> - <li><a href="http://dxr.mozilla.org/mozilla-central/source/netwerk/base/public/nsIFileStreams.idl"><code>nsIFileOutputStream</code></a></li> -</ul> - -<h3 id="XUL_and_browser_UI">XUL and browser UI</h3> - -<p>Anything that tries to touch the browser UI or anything to do with XUL is likely to not work in the content process. For example:</p> - -<ul> - <li><code><a href="http://dxr.mozilla.org/mozilla-central/source/embedding/components/windowwatcher/nsIPromptService.idl">nsIPromptService</a></code></li> - <li><a href="http://dxr.mozilla.org/mozilla-central/source/widget/nsIFilePicker.idl"><code>nsIFilePicker</code></a></li> - <li><code>nsIXUL*</code></li> - <li><need more examples></li> -</ul> - -<h3 id="Chrome_windows">Chrome windows</h3> - -<p>Anything that needs to use chrome windows will not work in the content process. For example:</p> - -<ul> - <li><a href="http://dxr.mozilla.org/mozilla-central/source/mobile/android/components/SessionStore.idl"><code>nsISessionStore</code></a></li> - <li><a href="http://dxr.mozilla.org/mozilla-central/source/xpfe/appshell/nsIWindowMediator.idl"><code>nsIWindowMediator</code></a></li> - <li><need more examples></li> -</ul> - -<h3 id="Places_API">Places API</h3> - -<p>The <a href="/en-US/docs/Mozilla/Tech/Places">Places API</a> can't be used inside a frame script. For example:</p> - -<ul> - <li><a href="http://dxr.mozilla.org/mozilla-central/source/toolkit/components/places/nsINavHistoryService.idl"><code>nsINavHistoryService</code></a></li> - <li><a href="http://dxr.mozilla.org/mozilla-central/source/toolkit/components/places/nsINavBookmarksService.idl"><code>nsINavBookmarksService</code></a></li> -</ul> - -<h3 id="Observers_in_the_content_process">Observers in the content process</h3> - -<p>As noted in <a href="https://developer.mozilla.org/en-US/Firefox/Multiprocess_Firefox/Problem_areas_for_add-on_developers#Observers_in_the_chrome_process">Observers in the chrome process</a>, most <a href="http://dxr.mozilla.org/mozilla-central/source/xpcom/ds/nsIObserver.idl">observers</a> should be registered in the chrome process and will not work in the content process. The exceptions are <a class="new" href="https://developer.mozilla.org/en/docs/Observer_Notifications#Documents"><code>content-document-global-created</code> and <code>document-element-inserted</code></a> , which must be registered in a frame script.</p> - -<h3 id="QI_from_content_window_to_chrome_window">QI from content window to chrome window</h3> - -<div>There's a particular pattern often used to get from a content window to the associated chrome window. It looks something like this:</div> - -<div> </div> - -<pre class="brush: js">window.QueryInterface(Ci.nsIInterfaceRequestor) - .getInterface(Ci.nsIWebNavigation) - .QueryInterface(Ci.nsIDocShellTreeItem) - .rootTreeItem - .QueryInterface(Ci.nsIInterfaceRequestor) - .getInterface(Ci.nsIDOMWindow);</pre> - -<div>This will no longer work. In the content process the root tree item is an <a href="http://dxr.mozilla.org/mozilla-central/source/dom/interfaces/base/nsITabChild.idl"><code>nsITabChild</code></a>, that cannot be converted to an <code>nsIDOMWindow</code>, so the second <code>getInterface</code> call here will fail.</div> - -<div> </div> - -<p>If you want a chrome window: send a message from the content process using the <a href="/en-US/Firefox/Multiprocess_Firefox/The_message_manager">message manager</a>. The <a href="/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIMessageListener#receiveMessage()"><code>target</code></a> property of the object passed into the message handler in the chrome process is the XUL <a href="/en-US/docs/XUL/browser"><code><browser></code></a> receiving the message, and you can get the chrome window from that (Note: I'm not really sure how...).</p> - -<h3 id="nsIAboutModule">nsIAboutModule</h3> - -<p>By default, custom <code>about:</code> pages registered using <a href="http://dxr.mozilla.org/mozilla-central/source/netwerk/protocol/about/nsIAboutModule.idl"><code>nsIAboutModule</code></a> are loaded in the chrome process. This means that you can't access their content from the content process (via XHR, for example).</p> - -<p>There is a shim for this, that makes the content of <code>about:</code> pages registered by the add-on transparently available in the content process.</p> - -<p>To avoid the shim: if you need to access the content of your about page from the content process, you need to register the <code>nsIAboutModule</code> in the content process as well as the chrome process. By default, <code>about:</code> pages (except for a small whitelist) are loaded in the chrome process when browsed to from the AwesomeBar.</p> diff --git a/files/es/mozilla/firefox/multiprocess_firefox/remotepagemanager/index.html b/files/es/mozilla/firefox/multiprocess_firefox/remotepagemanager/index.html deleted file mode 100644 index 083b13f1e0..0000000000 --- a/files/es/mozilla/firefox/multiprocess_firefox/remotepagemanager/index.html +++ /dev/null @@ -1,127 +0,0 @@ ---- -title: RemotePageManager -slug: Mozilla/Firefox/Multiprocess_Firefox/RemotePageManager -tags: - - Necesita traducción -translation_of: Mozilla/Firefox/Multiprocess_Firefox/RemotePageManager ---- -<div>{{FirefoxSidebar}}</div><p>{{ gecko_minversion_header('39') }}</p> - -<p>One of the challenges of converting Firefox features and add-ons to <a href="/en-US/Firefox/Multiprocess_Firefox">multiprocess Firefox</a> involves in-content pages. These pages (like about:addons) display in a tab but for now still render in the main process. There can be many reasons for wanting to move these into the content process, particularly if the page interacts with web content in any way but more generally just to keep the main UI as responsive as possible.</p> - -<p>This raises the problem of how the page communicates back to the main process to get information and trigger actions. Commonly this is done with a frame script listening for DOM events from inside the page, performing the necessary message passing and then passing results back to the page. However, this middleman approach has problems. The frame code is maintained separately from the page code leading to three different pieces of code handling behavior for the page. Add-ons also have to be careful to choose unique names for messages to avoid conflicting with other add-ons and Firefox code.</p> - -<p><code>RemotePageManager</code> is an API designed to simplify this. It acts as the middleman between code in the main process and code in the page without needing to write custom code in a frame script. Code in the main process registers URLs that it is interested in. Whenever a frame loads a page with that URL, a pseudo message manager is created to allow message passing between just that page and the code in the main process. Code running in the page itself can access the message manager directly without needing to use a frame script at all.</p> - -<h2 id="RemotePageManager">RemotePageManager</h2> - -<p><code>RemotePageManager</code> is the low-level way to interact with in-content pages. It includes the following methods:</p> - -<dl> - <dt><code>addRemotePageListener(url, callback)</code></dt> - <dd>Registers interest in a URL. Whenever a new page loads at that URL callback is called and passed the message channel to use to communicate with the page. Only one callback can be registered per URL.</dd> - <dt><code>removeRemotePageListener(url)</code></dt> - <dd>Unregisters interest in a URL. The callback passed above will not be called again.</dd> -</dl> - -<h2 id="RemotePages">RemotePages</h2> - -<p><code>RemotePages</code> is a higher-level option. As well as the methods listed here it also has the <a href="/en-US/Firefox/Multiprocess_Firefox/RemotePageManager#Message_channel_methods">message channel methods</a> which will send messages to, and receive messages from, every page currently loaded at the URL.</p> - -<dl> - <dt><code>RemotePages(url)</code></dt> - <dd>Creates a new <code>RemotePages</code> instance for a URL.</dd> - <dt><code>destroy()</code></dt> - <dd>Destroys the instance.</dd> -</dl> - -<h2 id="Message_channel_methods">Message channel methods</h2> - -<p>All of these methods are available directly in the page, on <code>RemotePages</code> instances, or on the channel passed to callbacks registered with <code>RemotePageManager.addRemotePageListener</code>.</p> - -<dl> - <dt><code>sendAsyncMessage(name, data)</code></dt> - <dd>Sends a named message to the other side of the channel. <code>data</code> is copied as a structured clone.</dd> - <dt><code>addMessageListener(name, listener)</code></dt> - <dd>Adds a listener for a named message. <code>listener</code> will be called when the other side of the channel sends a message for <code>name</code>. <code>listener</code> will be passed an object with the properties <code>target</code>, <code>name</code>, and <code>data</code>.</dd> - <dt><code>removeMessageListener(name, listener)</code></dt> - <dd>Removed a listener for a named message.</dd> -</dl> - -<h2 id="Special_messages">Special messages</h2> - -<p>As well as any messages that Firefox or add-on code sends through the message channels, some special messages will be sent. Generally any message name starting with "RemotePage:" should be considered reserved for future use.</p> - -<dl> - <dt>RemotePage:Init</dt> - <dd>Sent to a <code>RemotePages</code> instance when a new page is loaded with the matching URL. The <code>target</code> property of the object passed to any listener is a message channel for just that page.</dd> - <dt>RemotePage:Load</dt> - <dd>Sent when the load event for a matching page in the content process is fired.</dd> - <dt>RemotePage.Unload</dt> - <dd>Sent when a matching page in the content process is unloaded.</dd> -</dl> - -<h2 id="Low_level_example">Low level example</h2> - -<p>This example waits for a page to load and then passes it some information.</p> - -<pre class="brush: js">// code running in the main process somewhere -Components.utils.import("resource://gre/modules/RemotePageManager.jsm"); - -RemotePageManager.addRemotePageListener("about:foo", (channel) => { - // Wait for page load here to be sure the page has had chance to register for this message - channel.addMessageListener("RemotePage:Load", function() { - channel.sendAsyncMessage("MyMessage", { somedata: 42 }); - }); -}); -</pre> - -<p>Here is the code that runs in the page. Note that it has direct access to <code>addMessageListener</code> (as well as the other message channel methods).</p> - -<pre class="brush: js">// code running in the content webpage -addMessageListener("MyMessage", function(msg) { - alert(msg.data.somedata); -}); -</pre> - -<h2 id="High_level_example">High level example</h2> - -<p>The code above uses a callback that is called every time a page is loaded. In reality it is going to be more common for code in the main process to simply respond to requests from the page and want to update all pages at once. <code>RemotePages</code> is more suited to this:</p> - -<pre class="brush: js">// code running in the main process somewhere -Components.utils.import("resource://gre/modules/Preferences.jsm"); -Components.utils.import("resource://gre/modules/RemotePageManager.jsm"); - -let listener = new RemotePages("about:bar"); - -// Listens to messages from all current and future pages -listener.addMessageListener("GetLabel", ({ target }) => { - // target is the channel for just the page that sent this message - target.sendAsyncMessage("SetLabel", Preferences.get("extensions.label.text")); -}); - -Preferences.observe("extensions.label.text", (newLabel) => { - // Sends messages to all currently open pages - listener.sendAsyncMessage("SetLabel", newLabel); -}); - -listener.addMessageListener("ButtonClicked", () => { - // Do something here -}); -</pre> - -<pre class="brush: js">// code running in the content webpage -var button = document.getElementById("button"); -var label = document.getElementById("label"); - -sendAsyncMessage("GetLabel"); -addMessageListener("SetLabel", function(msg) { - label.textContent = msg.data; -}); - -function buttonClicked() { - sendAsyncMessage("ButtonClicked"); -} - -button.addEventListener("click", buttonClicked, false); -</pre> diff --git a/files/es/mozilla/firefox/multiprocess_firefox/tab_selection_in_multiprocess_firefox/index.html b/files/es/mozilla/firefox/multiprocess_firefox/tab_selection_in_multiprocess_firefox/index.html deleted file mode 100644 index 255fe18315..0000000000 --- a/files/es/mozilla/firefox/multiprocess_firefox/tab_selection_in_multiprocess_firefox/index.html +++ /dev/null @@ -1,23 +0,0 @@ ---- -title: Tab selection in multiprocess Firefox -slug: Mozilla/Firefox/Multiprocess_Firefox/Tab_selection_in_multiprocess_Firefox -tags: - - Necesita traducción -translation_of: Mozilla/Firefox/Multiprocess_Firefox/Tab_selection_in_multiprocess_Firefox ---- -<div>{{FirefoxSidebar}}</div><p>In single-process Firefox, when the user switches tabs, this is a synchronous operation. The browser blocks while it loads content into the newly selected tab, then switches to that tab. It indicates that the tab is selected by setting the <code><a href="https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/Attribute/selected">selected</a></code> attribute on the XUL <code>tab</code> object. Code (including browser code, extensions, or themes) that wants to change the appearance of the selected tab can use the <code>selected</code> attribute to apply CSS for that tab.</p> - -<p>In multiprocess Firefox, tab switching is asynchronous. When the user switches tabs, the chrome process sends a request to the content process to load the page into the newly selected tab. The function in the chrome process then returns immediately, so other code can run. Once the content process is ready, it sends a message back to the chrome process, which then switches tabs in the user interface.</p> - -<p>There's also a timer in the chrome process: if the content process has not responded before the timer expires, then the browser switches tabs anyway, and just displays an empty tab containing a spinner, until the content process has finished loading the page. Currently the timer is set to 300 milliseconds.</p> - -<p>There are, correspondingly, two attributes used to signal tab selection:</p> - -<ul> - <li>The old <code><a href="/en-US/docs/XUL/Attribute/selected">selected</a></code> attribute is set synchronously, at the start of the process. It signals that tab selection has started, but at this point the user interface has not yet been updated.</li> - <li>A new attribute <code><a href="/en-US/docs/Mozilla/Tech/XUL/Attribute/visuallyselected">visuallyselected</a></code> is now used once the browser has actually updated the user interface, either because the content process is ready or because the timer has expired.</li> -</ul> - -<p>This means that code which wants to style the currently selected tab needs to use the <code>visuallyselected</code> attribute to do so. If it uses the <code>selected</code> attribute, then there will be a momentary disconnect in which the newly selected tab's style is updated, but the browser is still displaying the old tab's content.</p> - -<footer class="entry-meta"> </footer> diff --git a/files/es/mozilla/firefox/multiprocess_firefox/technical_overview/index.html b/files/es/mozilla/firefox/multiprocess_firefox/technical_overview/index.html deleted file mode 100644 index bc743d1dfb..0000000000 --- a/files/es/mozilla/firefox/multiprocess_firefox/technical_overview/index.html +++ /dev/null @@ -1,166 +0,0 @@ ---- -title: Technical overview -slug: Mozilla/Firefox/Multiprocess_Firefox/Technical_overview -tags: - - Necesita traducción -translation_of: Mozilla/Firefox/Multiprocess_Firefox/Technical_overview ---- -<div>{{FirefoxSidebar}}</div><div class="note"> -<p>This page is an edited extract from Bill McCloskey's blog post on multiprocess Firefox: <a class="external external-icon" href="http://billmccloskey.wordpress.com/2013/12/05/multiprocess-firefox/">http://billmccloskey.wordpress.com/2013/12/05/multiprocess-firefox/</a></p> -</div> - -<p>At a very high level, multiprocess Firefox works as follows. The process that starts up when Firefox launches is called the <em>parent process</em>. Initially, this process works similarly to single-process Firefox: it opens a window displaying <a href="http://mxr.mozilla.org/mozilla-central/source/browser/base/content/browser.xul"><code>browser.xul</code></a>, which contains all the principal UI elements for Firefox. Firefox has a flexible GUI toolkit called XUL that allows GUI elements to be declared and laid out declaratively, similar to web content. Just like web content, the Firefox UI has a <code>window</code> object, which has a <code>document</code> property, and this document contains all the XML elements from <code>browser.xul</code>. All the Firefox menus, toolbars, sidebars, and tabs are XML elements in this document. Each tab element contains a <code><browser></code> element to display web content.</p> - -<p>The first place where multiprocess Firefox diverges from single-process Firefox is that each <code><browser></code> element has a <code>remote="true"</code> attribute. When such a browser element is added to the document, a new content process is started. This process is called a <em>child process</em>. An IPC channel is created that links the parent and child processes. Initially, the child displays <code>about:blank</code>, but the parent can send the child a command to navigate elsewhere.</p> - -<h2 id="Drawing"><strong id="drawing">Drawing</strong></h2> - -<p>Somehow, displayed web content needs to get from the child process to the parent and then to the screen. Multiprocess Firefox depends on a new Firefox feature called <a href="http://benoitgirard.wordpress.com/2012/05/15/off-main-thread-compositing-omtc-and-why-it-matters/"><em>off main thread compositing</em></a> (OMTC). In brief, each Firefox window is broken into a series of <em>layers</em>, somewhat similar to layers in Photoshop. Each time Firefox draws, these layers are submitted to a compositor thread that clips and translates the layers and combines them together into a single image that is then drawn.</p> - -<p>Layers are structured as a tree. The root layer of the tree is responsible for the entire Firefox window. This layer contains other layers, some of which are responsible for drawing the menus and tabs. One subtree displays all the web content. Web content itself may be broken into multiple layers, but they’re all rooted at a single “content” layer.</p> - -<p>In multiprocess Firefox, the content layer subtree is actually a shim. Most of the time, it contains a placeholder node that simply keeps a reference to the IPC link with the child process. The content process retains the actual layer tree for web content. It builds and draws to this layer tree. When it’s done, it sends the structure of its layer tree to the parent process via IPC. Backing buffers are shared with the parent either through shared memory or GPU memory. References to this memory are sent as part of the layer tree. When the parent receives the layer tree, it removes its placeholder content node and replaces it with the actual tree from content. Then it composites and draws as normal. When it’s done, it puts the placeholder back.</p> - -<p>The basic architecture of how OMTC works with multiple processes has existed for some time, since it is needed for Firefox OS. However, Matt Woodrow and David Anderson have done a lot of work to get everything working properly on Windows, Mac, and Linux. One of the big challenges for multiprocess Firefox will be getting OMTC enabled on all platforms. Right now, only Macs use it by default.</p> - -<h2 id="User_input"><strong id="input">User input</strong></h2> - -<p>Events in Firefox work the same way as they do on the web. Namely, there is a DOM tree for the entire window, and events are threaded through this tree in capture and bubbling phases. Imagine that the user clicks on a button on a web page. In single-process Firefox, the root DOM node of the Firefox window gets the first chance to process the event. Then, nodes lower down in the DOM tree get a chance. The event handling proceeds down through to the XUL <code><browser></code> element. At this point, nodes in the web page’s DOM tree are given a chance to handle the event, all the way down to the button. The bubble phase follows, running in the opposite order, all the way back up to the root node of the Firefox window.</p> - -<p>With multiple processes, event handling works the same way until the <code><browser></code> element is hit. At that point, if the event hasn’t been handled yet, it gets sent to the child process by IPC, where handling starts at the root of the content DOM tree. The parent process then waits to run its bubbling phase until the content process has finished handling the event.</p> - -<h2 id="Inter-process_communication"><strong id="ipc">Inter-process communication</strong></h2> - -<p>All IPC happens using the Chromium IPC libraries. Each child process has its own separate IPC link with the parent. Children cannot communicate directly with each other. To prevent deadlocks and to ensure responsiveness, the parent process is not allowed to sit around waiting for messages from the child. However, the child is allowed to block on messages from the parent.</p> - -<p>Rather than directly sending packets of data over IPC as one might expect, we use code generation to make the process much nicer. The IPC protocol is defined in <a href="https://wiki.mozilla.org/IPDL">IPDL</a>, which sort of stands for “inter-* protocol definition language”. A typical IPDL file is <code><a href="http://mxr.mozilla.org/mozilla-central/source/netwerk/ipc/PNecko.ipdl">PNecko.ipdl</a></code>. It defines a set messages and their parameters. Parameters are serialized and included in the message. To send a message <code>M</code>, C++ code just needs to call the method <code>SendM</code>. To receive the message, it implements the method <code>RecvM</code>.</p> - -<p>IPDL is used in all the low-level C++ parts of Gecko where IPC is required. In many cases, IPC is just used to forward actions from the child to the parent. This is a common pattern in Gecko:</p> - -<pre class="brush: cpp">void AddHistoryEntry(param) { - if (XRE_GetProcessType() == GeckoProcessType_Content) { - // If we're in the child, ask the parent to do this for us. - SendAddHistoryEntry(param); - return; - } - - // Actually add the history entry... -} - -bool RecvAddHistoryEntry(param) { - // Got a message from the child. Do the work for it. - AddHistoryEntry(param); - return true; -} -</pre> - -<p>When <code>AddHistoryEntry</code> is called in the child, we detect that we’re inside the child process and send an IPC message to the parent. When the parent receives that message, it calls <code>AddHistoryEntry</code> on its side.</p> - -<p>For a more realistic illustration, consider the Places database, which stores visited URLs for populating the awesome bar. Whenever the user visits a URL in the content process, we call <a href="http://mxr.mozilla.org/mozilla-central/source/toolkit/components/places/History.cpp?rev=8b9687f6c602#2326">this code</a>. Notice the content process check followed by the <code>SendVisitURI</code> call and an immediate return. The message is received <a href="http://mxr.mozilla.org/mozilla-central/source/dom/ipc/ContentParent.cpp?rev=fecda5f4a0df#2666">here</a>; this code just calls <code>VisitURI</code> in the parent.</p> - -<p>The code for IndexedDB, the places database, and HTTP connections all runs in the parent process, and they all use roughly the same proxying mechanism in the child.</p> - -<h2 id="Frame_scripts"><strong id="contentscripts">Frame scripts</strong></h2> - -<p>IPDL takes care of passing messages in C++, but much of Firefox is actually written in JavaScript. Instead of using IPDL directly, JavaScript code relies on <a href="/en-US/Firefox/Multiprocess_Firefox/The_message_manager">the message manager</a> to communicate between processes. To use the message manager in JS, you need to get hold of a message manager object. There is a global message manager, message managers for each Firefox window, and message managers for each <code><browser></code> element. A message manager can be used to load JS code into the child process and to exchange messages with it.</p> - -<p>As a simple example, imagine that we want to be informed every time a <code>load</code> event triggers in web content. We’re not interested in any particular browser or window, so we use the global message manager. The basic process is as follows:</p> - -<pre class="brush: js">// Get the global message manager. -let mm = Cc["@<span class="skimlinks-unlinked">mozilla.org/globalmessagemanager;1</span>"]. - getService(Ci.nsIMessageListenerManager); - -// Wait for load event. -mm.addMessageListener("GotLoadEvent", function (msg) { - dump("Received load event: " + <span class="skimlinks-unlinked">msg.data.url</span> + "\n"); -}); - -// Load code into the child process to listen for the event. -mm.loadFrameScript("chrome://content/<span class="skimlinks-unlinked">content-script.js</span>", true); -</pre> - -<p>For this to work, we also need to have a file <code>content-script.js</code>:</p> - -<pre class="brush: js">// Listen for the load event. -addEventListener("load", function (e) { - // Inform the parent process. - let docURL = content.document.documentURI; - sendAsyncMessage("GotLoadEvent", {url: docURL}); -}, false); -</pre> - -<p>This file is called a <em>frame script</em>. When the <code>loadFrameScript</code> function call runs, the code for the script is run once for each <code><browser></code> element. This includes both remote browsers and regular ones. If we had used a per-window message manager, the code would only be run for the browser elements in that window. Any time a new browser element is added, the script is run automatically (this is the purpose of the <code>true</code> parameter to <code>loadFrameScript</code>). Since the script is run once per browser, it can access the browser’s window object and docshell via the <code>content</code> and <code>docShell</code> globals.</p> - -<p>The great thing about frame scripts is that they work in both single-process and multiprocess Firefox. To learn more about the message manager, see the <a href="/en-US/Firefox/Multiprocess_Firefox/The_message_manager">message manager guide</a>.</p> - -<h2 id="Cross-process_APIs"><strong id="shims">Cross-process APIs</strong></h2> - -<p>There are a lot of APIs in Firefox that cross between the parent and child processes. An example is the <code>webNavigation</code> property of XUL <code><browser></code> elements. The <code>webNavigation</code> property is an object that provides methods like <code>loadURI</code>, <code>goBack</code>, and <code>goForward</code>. These methods are called in the parent process, but the actions need to happen in the child. First I’ll cover how these methods work in single-process Firefox, and then I’ll describe how we adapted them for multiple processes.</p> - -<p>The <code>webNavigation</code> property is defined using the XML Binding Language (XBL). XBL is a declarative language for customizing how XML elements work. Its syntax is a combination of XML and JavaScript. Firefox uses XBL extensively to customize XUL elements like <code><browser></code> and <code><tabbrowser></code>. The <code><browser></code> customizations reside in <code><a href="http://mxr.mozilla.org/mozilla-central/source/toolkit/content/widgets/browser.xml?rev=754cf7fc84cd">browser.xml</a></code>. <a href="http://mxr.mozilla.org/mozilla-central/source/toolkit/content/widgets/browser.xml?rev=754cf7fc84cd#262">Here</a> is how <code>browser.webNavigation</code> is defined:</p> - -<pre class="brush: xml"><field name="_webNavigation">null</field> - -<property name="webNavigation" readonly="true"> - <getter> - <![CDATA[ - if (!this._webNavigation) - this._webNavigation = this.docShell.QueryInterface(Components.interfaces.nsIWebNavigation); - return this._webNavigation; - ]]> - </getter> -</property> -</pre> - -<p>This code is invoked whenever JavaScript code in Firefox accesses <code>browser.webNavigation</code>, where <code>browser</code> is some <code><browser></code> element. It checks if the result has already been cached in the <code>browser._webNavigation</code> field. If it hasn’t been cached, then it fetches the navigation object based off the browser’s <em>docshell</em>. The docshell is a Firefox-specific object that encapsulates a lot of functionality for loading new pages, navigating back and forth, and saving page history. In multiprocess Firefox, the docshell lives in the child process. Since the <code>webNavigation</code> accessor runs in the parent process, <code>this.docShell</code> above will just return null. As a consequence, this code will fail completely.</p> - -<p>One way to fix this problem would be to create a fake docshell in C++ that could be returned. It would operate by sending IPDL messages to the real docshell in the child to get work done. We may eventually take this route in the future. We decided to do the message passing in JavaScript instead, since it’s easier and faster to prototype things there. Rather than change every docshell-using accessor to test if we’re using multiprocess browsing, we decided to create a new XBL binding that applies only to remote <code><browser></code> elements. It is called <a href="http://mxr.mozilla.org/mozilla-central/source/toolkit/content/widgets/remote-browser.xml?rev=9583bd3099ae"><code>remote-browser.xml</code></a>, and it extends the existing <code>browser.xml</code> binding.</p> - -<p>The <code>remote-browser.xml</code> binding returns a JavaScript <em>shim object</em> whenever anyone uses <code>browser.webNavigation</code> or other similar objects. The shim object is implemented <a href="http://mxr.mozilla.org/mozilla-central/source/toolkit/modules/RemoteWebNavigation.jsm">in its own JavaScript module</a>. It uses the message manager to send messages like <code>"WebNavigation:LoadURI"</code> to <a href="http://mxr.mozilla.org/mozilla-central/source/toolkit/content/browser-child.js?rev=9583bd3099ae#107">a content script loaded by <code>remote-browser.xml</code></a>. The content script performs the actual action.</p> - -<p>The shims we provide emulate their real counterparts imperfectly. They offer enough functionality to make Firefox work, but add-ons that use them may find them insufficient. I’ll discuss strategies for making add-ons work in more detail later.</p> - -<h2 id="Cross-process_object_wrappers"><strong id="cpows">Cross-process object wrappers</strong></h2> - -<p>The message manager API does not allow the parent process to call <code>sendSyncMessage</code>; that is, the parent is not allowed to wait for a response from the child. It’s detrimental for the parent to wait on the child, since we don’t want the browser UI to be unresponsive because of slow content. However, converting Firefox code to be asynchronous (i.e., to use <code>sendAsyncMessage</code> instead) can sometimes be onerous. As an expedient, we’ve introduced a new primitive that allows code in the parent process to access objects in the child process synchronously.</p> - -<p>These objects are called cross-process object wrappers, frequently abbreviated to CPOWs. They’re created using the message manager. Consider this example content script:</p> - -<pre class="brush: js">addEventListener("load", function (e) { - let doc = content.document; - sendAsyncMessage("GotLoadEvent", <strong>{}, {document: doc}</strong>); -}, false); -</pre> - -<p>In this code, we want to be able to send a reference to the document to the parent process. We can’t use the second parameter to <code>sendAsyncMessage</code> to do this: that argument is converted to JSON before it is sent up. The optional third parameter allows us to send object references. Each property of this argument becomes accessible in the parent process as a CPOW. Here’s what the parent code might look like:</p> - -<pre class="brush: js">let mm = Cc["@<span class="skimlinks-unlinked">mozilla.org/globalmessagemanager;1</span>"]. - getService(Ci.nsIMessageListenerManager); - -mm.addMessageListener("GotLoadEvent", function (msg) { - let uri = <strong>msg.objects.document.documentURI</strong>; - dump("Received load event: " + uri + "\n"); -}); -mm.loadFrameScript("chrome://content/<span class="skimlinks-unlinked">content-script.js</span>", true); -</pre> - -<p>It’s important to realize that we’re send object <em>references</em>. The <code>msg.objects.document</code> object is only a wrapper. The access to its <code>documentURI</code> property sends a synchronous message down to the child asking for the value. The dump statement only happens after a reply has come back from the child.</p> - -<p>Because every property access sends a message, CPOWs can be slow to use. There is no caching, so 1,000 accesses to the same property will send 1,000 messages.</p> - -<p>Another problem with CPOWs is that they violate some assumptions people might have about message ordering. Consider this code:</p> - -<pre class="brush: js">mm.addMessageListener("GotLoadEvent", function (msg) { - mm.sendAsyncMessage("ChangeDocumentURI", {newURI: "<span class="skimlinks-unlinked">hello.com</span>"}); - let uri = <strong>msg.objects.document.documentURI</strong>; - dump("Received load event: " + uri + "\n"); -}); -</pre> - -<p>This code sends a message asking the child to change the current document URI. Then it accesses the current document URI via a CPOW. You might expect the value of <code>uri</code> to come back as <code>"hello.com"</code>. But it might not. In order to avoid deadlocks, CPOW messages can bypass normal messages and be processed first. It’s possible that the request for the <code>documentURI</code> property will be processed before the <code>"ChangeDocumentURI"</code> message, in which case <code>uri</code> will have some other value.</p> - -<p>For this reason, it’s best not to mix CPOWs with normal message manager messages. It’s also a bad idea to use CPOWs for anything security-related, since you may not get results that are consistent with surrounding code that might use the message manager.</p> - -<p>Despite these problems, we’ve found CPOWs to be useful for converting certain parts of Firefox to be multiprocess-compatible. It’s best to use them in cases where users are less likely to notice poor responsiveness. As an example, we use CPOWs to implement the context menu that pops up when users right-click on content elements. Whether this code is asynchronous or synchronous, the menu cannot be displayed until content has responded with data about the element that has been clicked. The user is unlikely to notice if, for example, tab animations don’t run while waiting for the menu to pop up. Their only concern is for the menu to come up as quickly as possible, which is entirely gated on the response time of the content process. For this reason, we chose to use CPOWs, since they’re easier than converting the code to be asynchronous.</p> - -<p>It’s possible that CPOWs will be phased out in the future. Asynchronous messaging using the message manager gives a user experience that is at least as good as, and often strictly better than, CPOWs. We strongly recommend that people use the message manager over CPOWs when possible. Nevertheless, CPOWs are sometimes useful.</p> diff --git a/files/es/mozilla/firefox/multiprocess_firefox/types_of_message_manager/index.html b/files/es/mozilla/firefox/multiprocess_firefox/types_of_message_manager/index.html deleted file mode 100644 index fe2917686b..0000000000 --- a/files/es/mozilla/firefox/multiprocess_firefox/types_of_message_manager/index.html +++ /dev/null @@ -1,179 +0,0 @@ ---- -title: Message manager overview -slug: Mozilla/Firefox/Multiprocess_Firefox/Types_of_message_manager -tags: - - Necesita traducción -translation_of: Mozilla/Firefox/Multiprocess_Firefox/Types_of_message_manager ---- -<div>{{FirefoxSidebar}}</div><p>In the initial version of multiprocess Firefox there are two processes:</p> - -<ul> - <li>the chrome process, also called the parent process, runs the browser UI (chrome) code and code inserted by extensions</li> - <li>the content process, also called the child process, runs all web content. In future versions of multiprocess Firefox different tabs may run in different processes, but for now, all content tabs share a single content process.</li> -</ul> - -<p>Message managers are designed to enable code in one process to communicate with code in a different process. At the top level, there are two different sorts of message managers:</p> - -<ul> - <li><em>Frame message managers</em>: these enable chrome process code to load a script into a browser frame (essentially, a single browser tab) in the content process. These scripts are called <em>frame scripts</em>, and as the name suggests, they are scoped to a specific browser frame. If chrome code wants to run code in the content process so it can access web content, this is usually the sort of message manager to use.</li> - <li><em>Process message managers</em>: these correspond to process boundaries, and enable code running in the parent (chrome) process to communicate with code running in the child (content) process. From Firefox 38 onwards, they also enable code running in the parent process to load <em>process scripts</em> into the child process. These are like frame scripts, except they are global to the child process. Process scripts are most likely to be useful when chrome code wants to run some code only once in the content process, to access some global service: for example, to register an observer or a content policy.</li> -</ul> - -<h2 id="Frame_message_managers">Frame message managers</h2> - -<p>In multiprocess Firefox, when chrome code needs to interact with web content, it needs to:</p> - -<ul> - <li>factor the code that needs direct access to content into separate scripts, which are called "frame scripts"</li> - <li>use a frame message manager to load these frame scripts into the content process</li> - <li>use the frame message manager API to communicate with the frame script</li> -</ul> - -<div class="note"> -<p>Some older articles on multiprocess Firefox and the message manager might refer to "content scripts" instead of "frame scripts", but this usage is deprecated because the Add-on SDK uses "content script" to refer to a <a href="https://developer.mozilla.org/en-US/Add-ons/SDK/Guides/Content_Scripts">similar but different kind of script</a>.</p> -</div> - -<p>There are three different subtypes of frame message manager: the global message manager, the window message manager, and the browser message manager. All three enable chrome code to:</p> - -<ul> - <li>load a script into a frame in the content the content process using a <code>loadFrameScript()</code> function. These scripts are called "frame scripts".</li> - <li>communicate with frame scripts using <code>addMessageListener()</code> and <code>broadcastAsyncMessage() </code>or <code>sendAsyncMessage() </code>functions.</li> -</ul> - -<div class="note"> -<p>Note that in this context, "browser" refers to the <a href="https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/browser">XUL <browser> object</a>, which is a frame that hosts a single Web document. It does not refer to the more general sense of a Web browser.</p> -</div> - -<h3 id="Global_message_manager">Global message manager</h3> - -<p>The <strong>global message manager</strong> operates on every <code><browser></code> (that is, every open content tab).<code> </code></p> - -<ul> - <li><code>loadFrameScript()</code> loads the given script into every <code><browser></code> in every browser window.</li> - <li><code>broadcastAsyncMessage()</code> sends the message to every <code><browser></code> in every browser window.</li> -</ul> - -<p>It's a <code>ChromeMessageBroadcaster</code> object, which implements the following interfaces:</p> - -<ul> - <li><code><a href="https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIFrameScriptLoader" title="">nsIFrameScriptLoader</a></code></li> - <li><code><a href="https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIMessageListenerManager" title="">nsIMessageListenerManager</a></code></li> - <li><code><a href="https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIMessageBroadcaster" title="">nsIMessageBroadcaster</a></code></li> -</ul> - -<p>You can access the global message manager like this:</p> - -<pre class="brush: js language-js"><code class="language-js"><span class="comment token">// chrome script -</span><span class="keyword token">let</span> globalMM <span class="operator token">=</span> Cc<span class="punctuation token">[</span><span class="string token">"@mozilla.org/globalmessagemanager;1"</span><span class="punctuation token">]</span> - <span class="punctuation token">.</span><span class="function token">getService<span class="punctuation token">(</span></span>Ci<span class="punctuation token">.</span>nsIMessageListenerManager<span class="punctuation token">)</span><span class="punctuation token">;</span></code></pre> - -<h3 id="Window_message_manager">Window message manager</h3> - -<p>The <strong>window message manager</strong> is associated with a specific browser window, and operates on every <code><browser></code> (that is, every content tab) loaded into that window:</p> - -<ul> - <li><code>loadFrameScript()</code> loads the given script into every <code><browser></code> in that browser window</li> - <li><code>broadcastAsyncMessage()</code> sends the message to every <code><browser></code> in that browser window.</li> -</ul> - -<p>It's a <code>ChromeMessageBroadcaster</code> object, which implements the following interfaces:</p> - -<ul> - <li><code><a href="https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIFrameScriptLoader" title="">nsIFrameScriptLoader</a></code></li> - <li><code><a href="https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIMessageListenerManager" title="">nsIMessageListenerManager</a></code></li> - <li><code><a href="https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIMessageBroadcaster" title="">nsIMessageBroadcaster</a></code></li> -</ul> - -<p>The window message manager can be accessed as a property of the browser window:</p> - -<pre class="brush: js language-js"><code class="language-js"><span class="comment token">// chrome script -</span><span class="keyword token">let</span> windowMM <span class="operator token">=</span> window<span class="punctuation token">.</span>messageManager<span class="punctuation token">;</span></code></pre> - -<h3 id="Browser_message_manager">Browser message manager</h3> - -<p>The <strong>browser message manager</strong> is specific to a single XUL <code><browser></code> element (which essentially corresponds to a single tab):</p> - -<ul> - <li><code>loadFrameScript()</code> loads the given script only into its <code><browser></code></li> - <li><code>sendAsyncMessage()</code> sends the message only to that <code><browser></code>.</li> -</ul> - -<p>You can mix and match: so for example, you could load a script into every <code><browser></code> using the global message manager, but then send a message to the script instance loaded into a specific <code><browser></code> using the browser message manager.</p> - -<p>It's a <code>ChromeMessageSender</code> object, which implements the following interfaces:</p> - -<ul> - <li><code><a class="new" href="https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIProcessChecker" title="">nsIProcessChecker</a></code></li> - <li><code><a href="https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIFrameScriptLoader" title="">nsIFrameScriptLoader</a></code></li> - <li><code><a href="https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIMessageListenerManager" title="">nsIMessageListenerManager</a></code></li> - <li><code><a href="https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIMessageSender" title="">nsIMessageSender</a></code></li> -</ul> - -<p>The browser message manager can be accessed as a property of the XUL <code><browser></code> element:</p> - -<pre class="brush: js language-js"><code class="language-js"><span class="comment token">// chrome script -</span><span class="keyword token">let</span> browserMM <span class="operator token">=</span> gBrowser<span class="punctuation token">.</span>selectedBrowser<span class="punctuation token">.</span>messageManager<span class="punctuation token">;</span></code></pre> - -<h2 id="Process_message_managers">Process message managers</h2> - -<p>Process message managers correspond to process boundaries, and enable code running in different processes to communicate. Multiprocess Firefox has the concept of:</p> - -<ul> - <li>a "parent process"</li> - <li>"child processes" which are processes spawned by the parent process.</li> -</ul> - -<p>For practical purposes, in multiprocess Firefox the parent process is the chrome process, and child processes are content processes. </p> - -<p>In each child process, there's a single <em>child process message manager</em> (CPMM). For each child process message manager, there's a <em>parent process message manager</em> (PPMM) in the parent process. There's also a single <em>global parent process message manager</em> (GPPMM) in the parent process, that provides access to all the parent process message managers:</p> - -<p><img alt="" src="https://mdn.mozillademos.org/files/10791/process-message-managers.png" style="display: block; height: 477px; margin-left: auto; margin-right: auto; width: 524px;"></p> - -<p> </p> - -<p>With the GPPMM, you can broadcast messages to all CPMMs. With a PPMM, you can send a message to its corresponding CPMM. With a CPMM, you can send messages to the parent process: these messages are received first by the corresponding PPMM, then by the GPPMM.</p> - -<p>From Firefox 38 onwards, you can also use a parent process message manager to load a script into a child process. This is the recommended way to load a script that executes just once per child process, which is something you might want to do if you are interacting with some global service (for example, adding listeners to observer notifications or registering components).</p> - -<h3 id="Accessing_process_message_managers">Accessing process message managers</h3> - -<p>You can access the global parent process manager with code like this:</p> - -<pre class="brush: js">// parent process -let parentProcessMessageManager = Cc["@mozilla.org/parentprocessmessagemanager;1"] - .getService(Ci.nsIMessageBroadcaster);</pre> - -<p>You can also access it as the <code>ppmm</code> property of <a href="/en-US/docs/Mozilla/JavaScript_code_modules/Services.jsm">Services.jsm</a>.</p> - -<pre class="brush: js">// child process script -let childProcessMessageManager = Cc["@mozilla.org/childprocessmessagemanager;1"] - .getService(Ci.nsISyncMessageSender);</pre> - -<h3 id="Parent_process_message_manager">Parent process message manager</h3> - -<p>The parent process message manager lives in the</p> - -<p>implements</p> - -<ul> - <li><code><a href="https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIMessageListenerManager" title="">nsIMessageListenerManager</a></code></li> - <li><code><a href="https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIMessageBroadcaster" title="">nsIMessageBroadcaster</a></code></li> -</ul> - -<p> </p> - -<h3 id="Child_process_message_manager">Child process message manager</h3> - -<p>implements</p> - -<ul> - <li><code><a href="https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIMessageListenerManager" title="">nsIMessageListenerManager</a></code></li> - <li><code><a href="https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIMessageSender" title="">nsIMessageSender</a></code></li> -</ul> - -<h4 id="Loading_scripts_per_child_process">Loading scripts per child process</h4> - -<p>Since the process message managers do not support script loading the only way to implement per-child process code is to use a <a href="https://developer.mozilla.org/en-US/Firefox/Multiprocess_Firefox/The_message_manager#frame-scripts">frame script</a> which imports a custom <a href="https://developer.mozilla.org/en-US/docs/JavaScript_code_modules/Using">javascript module (JSM)</a>. Since javascript modules are singletons they will only be executed once per process even when they are loaded in multiple frame scripts.<br> - The JSM can then use the child process message manager to exchange messages with the parent process message manager.</p> - -<p>This can be useful for addons to register categories, observers and components in child processes.</p> diff --git a/files/es/mozilla/firefox/multiprocess_firefox/web_content_compatibility/index.html b/files/es/mozilla/firefox/multiprocess_firefox/web_content_compatibility/index.html deleted file mode 100644 index 3089e24000..0000000000 --- a/files/es/mozilla/firefox/multiprocess_firefox/web_content_compatibility/index.html +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: Web content compatibility -slug: Mozilla/Firefox/Multiprocess_Firefox/Web_content_compatibility -tags: - - Necesita traducción -translation_of: Mozilla/Firefox/Multiprocess_Firefox/Web_content_compatibility ---- -<div>{{FirefoxSidebar}}</div><p><span class="seoSummary">While the introduction of multi-process capabilities to Firefox should be seamless and invisible to Web content, there are some exceptions and subtle changes from past behavior. This article discusses the known differences you may encounter.</span></p> - -<h2 id="Events">Events</h2> - -<p>Here you'll find information about events whose behaviors have changed due to multiprocess Firefox's implementation.</p> - -<h3 id="No_bubbling_of_events_from_<option>_to_<select>">No bubbling of events from <code><option></code> to <code><select></code></h3> - -<p>Historically, Firefox has allowed keyboard and mouse events to bubble up from the <code><option></code> element to the parent {{HTMLElement("select")}} element. This doesn't happen in Chrome, however, although this behavior is inconsistent across many browsers. For better Web compatibility (and for technical reasons), when Firefox is in multi-process mode and the <code><select></code> element is displayed as a drop-down list. This behavior is unchanged if the <code><select></code> is presented inline and it has either the <code>multiple</code> attribute defined or a <code>size</code> attribute set to more than 1.</p> - -<p>Rather than watching <code><option></code> elements for events, you should watch for {event("change")}} events on {{HTMLElement("select")}}. See {{bug(1090602)}} for details.</p> - -<h2 id="See_also">See also</h2> - -<ul> - <li>Multiprocess Firefox</li> - <li>{{HTMLElement("option")}}</li> - <li>{{HTMLElement("select")}}</li> - <li>{{domxref("HTMLOptionElement")}}</li> - <li>{{domxref("HTMLSelectElement")}}</li> -</ul> diff --git a/files/es/mozilla/firefox/multiprocess_firefox/which_uris_load_where/index.html b/files/es/mozilla/firefox/multiprocess_firefox/which_uris_load_where/index.html deleted file mode 100644 index 7f9ee69755..0000000000 --- a/files/es/mozilla/firefox/multiprocess_firefox/which_uris_load_where/index.html +++ /dev/null @@ -1,61 +0,0 @@ ---- -title: Which URIs load where -slug: Mozilla/Firefox/Multiprocess_Firefox/Which_URIs_load_where -tags: - - Necesita traducción -translation_of: Mozilla/Firefox/Multiprocess_Firefox/Which_URIs_load_where ---- -<div>{{FirefoxSidebar}}</div><p>Based initially on the page's URI scheme, the browser can decide whether to load a page in the chrome process or a content process. For some schemes, you can change the default behavior.</p> - -<table class="standard-table"> - <thead> - <tr> - <th scope="col">Scheme</th> - <th scope="col">Behavior</th> - </tr> - </thead> - <tbody> - <tr> - <td><code>about:</code></td> - <td> - <p>By default, <code>about:</code> pages are always loaded in the chrome process. However, when you register a new <code>about:</code> page, you can change this default.</p> - - <p>Two new flags are defined in <code><a href="https://dxr.mozilla.org/mozilla-central/source/netwerk/protocol/about/nsIAboutModule.idl">nsIAboutModule</a></code>:</p> - - <ul> - <li><code>URI_CAN_LOAD_IN_CHILD</code>: the page will be loaded in the same process as the <code><a href="/en-US/docs/XUL/browser">browser</a></code> that has loaded it.</li> - <li><code>URI_MUST_LOAD_IN_CHILD</code>: the page will always be loaded in a child process.</li> - </ul> - - <p>To use one of these flags, return it from your implementation of <code>getURIFlags</code> in the <a href="/en-US/docs/Custom_about:_URLs">code that registers the <code>about:</code> URI</a>.</p> - - <p>If you use these flags, you must register the about page in the framescript for each tab. If you do not set multiprocessCompatible to true in your install.rdf then shims will be used. But the e10s shims will be deprecated soon. Read more here - <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1257201">Bug 1257201</a>.</p> - </td> - </tr> - <tr> - <td><code>chrome:</code></td> - <td> - <p>By default, <code>chrome:</code> pages are always loaded in the chrome process. However, when you register a new <code>chrome:</code> page, you can change this default.</p> - - <p>Two new flags are defined in the <a href="/en-US/docs/Chrome_Registration">chrome.manifest file</a>:</p> - - <ul> - <li>remoteenabled: the page will be loaded in the same process as the <code><a href="/en-US/docs/XUL/browser">browser</a></code> that has loaded it.</li> - <li>remoterequired: the page will always be loaded in a child process.</li> - </ul> - </td> - </tr> - <tr> - <td><code>file:</code></td> - <td> - <p>Always loaded in a content process.</p> - - <p><strong>Note:</strong> This does not mean <code>file:</code> URIs can be used freely by code in content processes. Sandboxing may blacklist particular directories and future changes may restrict <code>file:</code> URIs to a separate content process, isolated from regular web content. See <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1187099">bug 1187099</a> how this can affect addons attempting to load files from the profile directory.</p> - </td> - </tr> - <tr> - <td><code>resource:</code></td> - <td>Always loaded in a content process.</td> - </tr> - </tbody> -</table> diff --git a/files/es/mozilla/firefox/privacy/index.html b/files/es/mozilla/firefox/privacy/index.html deleted file mode 100644 index c6a9e69b09..0000000000 --- a/files/es/mozilla/firefox/privacy/index.html +++ /dev/null @@ -1,9 +0,0 @@ ---- -title: Privacy -slug: Mozilla/Firefox/Privacy -tags: - - NeedsTranslation - - TopicStub -translation_of: Mozilla/Firefox/Privacy ---- -<div>{{FirefoxSidebar}}</div><p>{{ ListSubpages () }}</p> diff --git a/files/es/mozilla/firefox/privacy/storage_access_policy/errors/cookieblockedtracker/index.html b/files/es/mozilla/firefox/privacy/storage_access_policy/errors/cookieblockedtracker/index.html deleted file mode 100644 index a66c128f8f..0000000000 --- a/files/es/mozilla/firefox/privacy/storage_access_policy/errors/cookieblockedtracker/index.html +++ /dev/null @@ -1,97 +0,0 @@ ---- -title: 'Blocked: Storage access requests from trackers' -slug: Mozilla/Firefox/Privacy/Storage_access_policy/Errors/CookieBlockedTracker -translation_of: Mozilla/Firefox/Privacy/Storage_access_policy/Errors/CookieBlockedTracker ---- -<h2 id="Mensaje">Mensaje</h2> - -<p>Firefox:</p> - -<pre class="syntaxbox"> <span class="tlid-translation translation" lang="es"><span title="">CookieBlockedTracker = La solicitud de acceso a cookies o almacenamiento en "X" se bloqueó porque provenía de un rastreador y el bloqueo de contenido está habilitado.</span></span> -</pre> - -<h2 id="¿Qué_salió_mal"><span class="tlid-translation translation" lang="es"><span title="">¿Qué salió mal</span></span>?</h2> - -<p><span class="tlid-translation translation" lang="es"><span title="">Se bloqueó una solicitud de acceso a cookies o almacenamiento porque el navegador la identificó como proveniente de un rastreador y el bloqueo de contenido está habilitado</span></span> .</p> - -<p><span class="tlid-translation translation" lang="es"><span title="">El permiso puede ser cambiado o eliminado por</span></span>:</p> - -<ul> - <li>Going to <em>Preferences > Content Blocking </em>and either - - <ul> - <li>adding an exception with the <em>Manage Exceptions</em>… button</li> - <li>choosing the <em>Custom</em> Content Blocking and unchecking the <em>Tracker</em> checkbox</li> - </ul> - </li> -</ul> - -<p>If the blocked resource doesn't need authentication, you can fix the warning message by adding a <code>crossorigin="anonymous"</code> attribute to the relevant element.</p> - -<h2 id="See_also">See also</h2> - -<ul> - <li><a href="https://support.mozilla.org/en-US/kb/content-blocking">Content blocking</a> on <a href="https://support.mozilla.org">support.mozilla.org</a></li> - <li><a href="/en-US/docs/Web/HTML/CORS_settings_attributes">The <code>crossorigin</code> attribute</a></li> -</ul> - -<div class="boxed translate-source hidden"><textarea><div>{{FirefoxSidebar}}</div> - -<h2 id="Message">Message</h2> - -<p>Firefox:</p> - -<pre class="syntaxbox">CookieBlockedTracker=Request to access cookies or storage on “X” was blocked because it came from a tracker and content blocking is enabled. -</pre> - -<h2 id="What_went_wrong">What went wrong?</h2> - -<p>A request to access cookies or storage was blocked because the browser identified it as coming from a tracker and content blocking is enabled.</p> - -<p>The permission can be changed or removed by:</p> - -<ul> - <li>Going to <em>Preferences &gt; Content Blocking </em>and either - - <ul> - <li>adding an exception with the <em>Manage Exceptions</em>… button</li> - <li>choosing the <em>Custom</em> Content Blocking and unchecking the <em>Tracker</em> checkbox</li> - </ul> - </li> -</ul> - -<p>If the blocked resource doesn't need authentication, you can fix the warning message by adding a <code>crossorigin="anonymous"</code> attribute to the relevant element.</p> - -<h2 id="See_also">See also</h2> - -<ul> - <li><a href="https://support.mozilla.org/en-US/kb/content-blocking">Content blocking</a> on <a href="https://support.mozilla.org">support.mozilla.org</a></li> - <li><a href="/en-US/docs/Web/HTML/CORS_settings_attributes">The <code>crossorigin</code> attribute</a></li> -</ul></textarea></div> - -<article class="localized"> -<header> -<h3 id="Traducción_en_Español">Traducción en Español:</h3> -</header> - -<div class="guide-links"><a href="/es/docs/MDN/Community" rel="noopener">¿Necesitas ayuda?</a> • <a href="/es/docs/MDN/Contribute/Editor" rel="noopener">Guía editorial</a> • <a href="/es/docs/MDN/Contribute/Content/Style_guide" rel="noopener">Guía de estilo</a></div> - -<div class="editor-wrapper" id="editor-wrapper"> -<div class="draft-container"> -<div class="draft-old"></div> - -<div class="draft-status">Autoguardado activado.</div> -</div> - -<div class="ckeditor-container editor-container dirty"> -<div class="editor"> -<div class="editor-tools"></div> -<textarea><p>La solicitud para acceder a la cookie o al almacenamiento en "https://www.dominio.com/" se bloqueó porque provenía de un rastreador y el bloqueador de contenido está habilitado.</p></textarea> - -<div style="height: 172px;"> -<div style="border: 1px solid rgb(182, 182, 182); width: 617px; position: fixed; top: 0px;"></div> -</div> -</div> -</div> -</div> -</article> diff --git a/files/es/mozilla/firefox/privacy/storage_access_policy/errors/index.html b/files/es/mozilla/firefox/privacy/storage_access_policy/errors/index.html deleted file mode 100644 index e34540eb06..0000000000 --- a/files/es/mozilla/firefox/privacy/storage_access_policy/errors/index.html +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: Errors -slug: Mozilla/Firefox/Privacy/Storage_access_policy/Errors -tags: - - Cookies - - Errors - - NeedsTranslation - - Storage - - TopicStub - - storage access policy -translation_of: Mozilla/Firefox/Privacy/Storage_access_policy/Errors ---- -<div>{{FirefoxSidebar}}</div> - -<p>This page lists the errors that can be raised due to Firefox's anti-tracking functionality, governed by the <a href="/en-US/docs/Mozilla/Firefox/Privacy/Storage_access_policy">Storage access policy</a>. You can find further information about them by clicking on the links below:</p> - -<p>A request to access cookies or storage was blocked because</p> - -<ul> - <li><a href="/en-US/docs/Mozilla/Firefox/Privacy/Storage_access_policy/Errors/CookieBlockedByPermission">of custom cookie permission</a>.</li> - <li><a href="/en-US/docs/Mozilla/Firefox/Privacy/Storage_access_policy/Errors/CookieBlockedTracker">it came from a tracker and content blocking is enabled</a>.</li> - <li><a href="/en-US/docs/Mozilla/Firefox/Privacy/Storage_access_policy/Errors/CookieBlockedAll">we are blocking all storage access requests</a>.</li> - <li><a href="/en-US/docs/Mozilla/Firefox/Privacy/Storage_access_policy/Errors/CookieBlockedForeign">we are blocking all third-party storage access requests and content blocking is enabled</a>.</li> -</ul> diff --git a/files/es/mozilla/firefox/privacy/storage_access_policy/index.html b/files/es/mozilla/firefox/privacy/storage_access_policy/index.html deleted file mode 100644 index 14d79a009c..0000000000 --- a/files/es/mozilla/firefox/privacy/storage_access_policy/index.html +++ /dev/null @@ -1,267 +0,0 @@ ---- -title: 'Storage access policy: Block cookies from trackers' -slug: Mozilla/Firefox/Privacy/Storage_access_policy -tags: - - NeedsTranslation - - Privacy - - TopicStub - - storage access policy - - tracking protection -translation_of: Mozilla/Firefox/Privacy/Storage_access_policy ---- -<div>{{FirefoxSidebar}}</div> - -<p class="summary">Firefox includes a new storage access policy that blocks cookies and other site data from third-party tracking resources. This new policy is designed as an alternative to the <a href="/en-US/docs/Mozilla/Cookies_Preferences">current policies</a>, which have been available in Firefox for many years. The new policy protects against cross-site tracking while minimizing the site breakage associated with traditional cookie blocking. This article explains how the new policy works and how you can test it.</p> - -<h2 id="Testing_in_Firefox">Testing in Firefox</h2> - -<p>You can test how your website works under the new policy in Firefox version 63+. Those who want to test the absolute newest version of the policy can download <a href="https://www.mozilla.org/en-US/firefox/channel/desktop/#nightly">Firefox Nightly</a>, but note that Nightly may include versions of the policy that end up changing before they reach our Release users. You can enable it through the “Content Blocking” menu in the <a href="https://support.mozilla.org/en-US/kb/control-center-site-privacy-and-security-firefox">Control Center</a> in Firefox:</p> - -<ul> - <li>Open up any version of Firefox version 63 or above. (for those who want to test the newest policy revision: download, install, and open up <a href="https://www.mozilla.org/en-US/firefox/channel/desktop/#nightly">Firefox Nightly</a>.)</li> - <li>Open the Content Blocking menu in the Control Center.</li> - <li>Click "Add Blocking…" next to "Third-party Cookies".</li> - <li>On the page that follows check "Third-party Cookies" and set the radio button to "Trackers".</li> -</ul> - -<p>As this is an experimental policy, it will likely change as we discover site breakage and fix bugs. We’ll keep this page updated with the newest information.</p> - -<h3 id="Report_Broken_Sites">Report Broken Sites</h3> - -<p>If you find a website broken as a result of this change, file a bug under the Tracking Protection component within the Firefox product on <a href="https://bugzilla.mozilla.org/enter_bug.cgi?assigned_to=nobody%40mozilla.org&blocked=1480137&bug_file_loc=http%3A%2F%2F&bug_ignored=0&bug_severity=normal&bug_status=NEW&cf_fx_iteration=---&cf_fx_points=---&cf_platform_rel=---&cf_status_firefox62=---&cf_status_firefox63=---&cf_status_firefox64=---&cf_status_firefox_esr60=---&cf_status_geckoview62=---&cf_tracking_firefox62=---&cf_tracking_firefox63=---&cf_tracking_firefox64=---&cf_tracking_firefox_esr60=---&cf_tracking_firefox_relnote=---&cf_tracking_geckoview62=---&component=Tracking%20Protection&contenttypemethod=list&contenttypeselection=text%2Fplain&defined_groups=1&flag_type-203=X&flag_type-37=X&flag_type-41=X&flag_type-5=X&flag_type-607=X&flag_type-721=X&flag_type-737=X&flag_type-748=X&flag_type-787=X&flag_type-799=X&flag_type-800=X&flag_type-803=X&flag_type-835=X&flag_type-846=X&flag_type-855=X&flag_type-864=X&flag_type-914=X&flag_type-916=X&flag_type-929=X&flag_type-930=X&flag_type-933=X&form_name=enter_bug&maketemplate=Remember%20values%20as%20bookmarkable%20template&op_sys=Unspecified&priority=--&product=Firefox&rep_platform=Unspecified&target_milestone=---&version=unspecified">Bugzilla</a>. Alternatively you can report a broken sites directly in Firefox by clicking "Report a Problem" in the Content Blocking section of the Control Center.</p> - -<p><img alt="diagram showing the report a problem button within the Content Blocking section of the Control Center" src="https://mdn.mozillademos.org/files/16249/control_center_report_problem.png" style="height: 475px; width: 509px;"></p> - -<h2 id="Tracking_protection_explained">Tracking protection explained</h2> - -<p>How does Firefox determine which resources are tracking resources?</p> - -<p>Firefox uses the Tracking Protection list to determine which resources are tracking resources. The Tracking Protection list is <a href="https://github.com/disconnectme/disconnect-tracking-protection/issues">maintained by Disconnect</a>. When the list is applied in Firefox, we make two important changes:</p> - -<ul> - <li>First, we only use the "Basic Protection" version of the list, which <a href="https://github.com/mozilla-services/shavar-prod-lists#blacklist">excludes some categories of trackers</a>. In the future, we may expand our protections to use the "Strict Protection" version of the list.</li> - <li>Second, Firefox uses an additional "<a href="https://github.com/mozilla-services/shavar-prod-lists/blob/master/disconnect-entitylist.json">entity list</a>", which prevents <a href="https://github.com/mozilla-services/shavar-prod-lists#entity-list">domains from being classified as trackers when they are loaded on a top-level site owned by the same organization</a>.</li> -</ul> - -<p>Firefox uses the built-in <a href="https://support.mozilla.org/en-US/kb/tracking-protection">Tracking Protection</a> URL classifier to determine which resources match the tracking protection list. Domains are matched against the list in accordance with the <a href="https://developers.google.com/safe-browsing/v4/urls-hashing#suffixprefix-expressions">SafeBrowsing v4 specification</a>. Specifically, we check the exact hostname of the resource against the list, as well as the last four hostnames formed by starting with the last five components and successively removing the leading component. Consider the following examples:</p> - -<table class="standard-table"> - <thead> - <tr> - <th scope="col">Hostname on the list</th> - <th scope="col">Hostname of resource</th> - <th scope="col">Matched</th> - </tr> - </thead> - <tbody> - <tr> - <td><code>example.com</code></td> - <td><code>example.com</code></td> - <td>Yes</td> - </tr> - <tr> - <td><code>example.com</code></td> - <td><code>a.b.example.com</code></td> - <td>Yes</td> - </tr> - <tr> - <td><code>blah.example.com</code></td> - <td><code>example.com</code></td> - <td>No</td> - </tr> - <tr> - <td><code>a.b.example.com</code></td> - <td><code>c.d.example.com</code></td> - <td>No</td> - </tr> - <tr> - <td><code>blah.example.com</code></td> - <td><code>foo.blah.example.com</code></td> - <td>Yes</td> - </tr> - </tbody> -</table> - -<h2 id="What_does_the_storage_access_policy_block">What does the storage access policy block?</h2> - -<p>The storage access policy blocks resources identified as trackers from accessing their cookies and other site storage when they are loaded in a third-party context. This prevents those resources from retrieving tracking identifiers stored in cookies or site storage and using them to identify users across visits to multiple first parties. Specifically, Firefox does this by imposing the following restrictions:</p> - -<p>Cookies:</p> - -<ul> - <li>Block {{httpheader("Cookie")}} request headers and ignore {{httpheader("Set-Cookie")}} response headers.</li> - <li>Return an empty string for calls to {{domxref("Document.cookie")}} and ignore requests to set cookies via <code>Document.cookie</code>.</li> -</ul> - -<p>DOM Storage:</p> - -<ul> - <li><a href="/en-US/docs/Web/API/Web_Storage_API">localStorage</a>: window.localStorage is null. Thus, attempts to read and write using this object will throw a <code>TypeError</code> exception</li> - <li><a href="/en-US/docs/Web/API/Web_Storage_API">sessionStorage</a>: read and write attempts are permitted.</li> - <li><a href="/en-US/docs/Web/API/IndexedDB_API">IndexedDB</a>: read and write attempts throw a <code>SecurityError</code> exception.</li> -</ul> - -<p>Messaging and Workers:</p> - -<ul> - <li><a href="/en-US/docs/Web/API/Broadcast_Channel_API">Broadcast Channel</a>: attempts to create a new {{domxref("BroadcastChannel")}} will throw a <code>SecurityError</code> exception.</li> - <li><a href="/en-US/docs/Web/API/Web_Workers_API">Shared Worker</a>: attempts to create a new {{domxref("SharedWorker")}} will throw a <code>SecurityError</code> exception.</li> - <li><a href="/en-US/docs/Web/API/Service_Worker_API">Service Worker</a>: attempts to create a new {{domxref("ServiceWorker")}} will throw a <code>SecurityError</code> exception.</li> -</ul> - -<p>DOM Cache:</p> - -<ul> - <li>Calls to {{domxref("CacheStorage")}} will always reject with a <code>SecurityError</code>.</li> -</ul> - -<p>Browser caches:</p> - -<ul> - <li>The <a href="/en-US/docs/Mozilla/HTTP_cache">HTTP cache</a> and the Image cache are partitioned for tracking resources, such that each top-level origin will have a separate partition and tracking resources on different top-level origins will be cached separate from each other.</li> -</ul> - -<h3 id="What_is_not_blocked_by_the_policy">What is not blocked by the policy?</h3> - -<ol> - <li>This policy does not currently restrict third-party storage access for resources that are not classified as tracking resources. We may choose to apply additional restrictions to third-party storage access in the future.</li> - <li>The restrictions applied by the policy will not prevent third-party scripts classified as tracking resources from accessing storage in the main context of the page. These scripts can continue to use storage scoped to the top-level origin.</li> - <li>Origins classified as trackers will have access to their own storage when they are loaded in a first-party context.</li> - <li>Cross-origin resources loaded from the same eTLD+1 as the top-level context will still have access to their storage.</li> - <li>Origins normally classified as trackers will <a href="https://github.com/mozilla-services/shavar-prod-lists#entity-list">not be blocked if the top-level page origin is determined to be from the same organization as them</a>.</li> -</ol> - -<h2 id="Storage_access_grants">Storage access grants</h2> - -<p>In order to improve web compatibility and permit third-party integrations that require storage access, Firefox will grant storage access scoped to the first party for a particular third-party origin as described in this section. Currently, Firefox includes some web compatibility heuristics that grant storage access to third-party resources classified as trackers when a user interacts with those third parties. We do this when we expect that not granting access would cause the web page to break. We also support an initial implementation of the <a href="https://developer.mozilla.org/en-US/docs/Web/API/Storage_Access_API">Storage Access API</a>, through which embedded {{htmlelement("iframe")}}s can request storage access by calling {{domxref("Document.requestStorageAccess()")}}. Although both of these approaches provide the same level of storage access, we recommend third parties switch to using the Storage Access API in order to guarantee their access to storage.</p> - -<h3 id="Automatic_storage_access_upon_interaction">Automatic storage access upon interaction</h3> - -<p>In order to improve web compatibility, Firefox currently includes some heuristics to grant storage access automatically to third parties that receive user interaction. These heuristics are intended to allow some third-party integrations that are common on the web to continue to function. They are intended to be temporary and will be removed in a future version of Firefox. They should not be relied upon for current and future web development.</p> - -<p>Third-party storage access may be granted to resources that have been classified as tracking resources when a user gesture triggers a pop-up window that has <a href="/en-US/docs/Web/API/Window/opener">opener access</a> to the originating document. When that occurs, there are two possible ways a third-party origin can be granted access:</p> - -<ul> - <li>The origin of the resource that is initially loaded in the pop-up window is granted storage access on the opener document if that origin has received user interaction as a first party within the past 30 days.</li> - <li>After the initial resource is loaded in the pop-up window, the window may go through a series of redirects to other hosts. If a user interacts with the pop-up window following a redirect, the origin of the content loaded in the pop-up window is given storage access on the opener document.</li> -</ul> - -<h3 id="Scope_of_storage_access">Scope of storage access</h3> - -<p>When storage access is granted, it is scoped to the origin of the opener document or subdomains of that origin. Access that is granted on the subdomain of an origin does not extend to the top-level origin. As an example, if a resource from <code>tracker.example</code> is granted storage access on <code>foo.example.com</code>, then <code>tracker.example</code> will be able to access its cookies on <code>bar.foo.example.com</code> but not <code>example.com</code>. Instead, if <code>tracker.example</code> were granted access on <code>example.com</code> it would be able to access its storage on <code>bar.foo.example.com</code>, <code>foo.example.com</code>, and <code>example.com</code>.</p> - -<p>When storage access is granted to <code>tracker.example</code> on <code>example.com</code>, all resources loaded from <code>tracker.example</code> on any top-level document loaded from <code>example.com</code> are immediately given storage access. This includes all resources loaded in the main context of the page, embedded <code><iframe></code>s, and resources loaded within embedded <code><iframe></code>s. Storage access is not extended to other resources loaded on <code>example.com</code> (e.g. <code>other-tracker.example</code>), nor to other first parties on which <code>tracker.example</code> is embedded (e.g. <code>example.org</code>).</p> - -<p>Storage access grants extend into the first level of nested contexts, but no further. This means that <code><iframe></code>s embedded in the main context of the page and loaded from a domain classified as a tracker will have full access to all storage locations accessible through JavaScript. Similarly, requests for resources loaded in <code><iframe></code>s embedded in the main context of the page will have access to HTTP cookies. However, further nested contexts, including but not limited to those from the origin classified as a tracker, will not be granted storage access.</p> - -<p>Consider the following embedding scenarios on a top-level page loaded from <code>example.com</code> on which <code>tracker.example</code> has been granted storage access.</p> - -<table class="standard-table"> - <thead> - <tr> - <th scope="col">Embedding</th> - <th scope="col">tracker.example resource storage access</th> - </tr> - </thead> - <tbody> - <tr> - <td>An image is loaded from <code>tracker.example</code> and embedded in the main context of <code>example.com</code>.</td> - <td>HTTP: Yes<br> - JS: N/A</td> - </tr> - <tr> - <td><code>example.com</code> embeds an <code><iframe></code> from <code>example.org</code>. That <code><iframe></code> goes on to load an image from <code>tracker.example</code>.</td> - <td>HTTP: Yes<br> - JS: N/A</td> - </tr> - <tr> - <td><code>example.com</code> embeds an <code><iframe></code> from <code>example.org</code>. That <code><iframe></code> goes on to embed an <code><iframe></code> from <code>tracker.example</code>.</td> - <td>HTTP: Yes<br> - JS: No</td> - </tr> - <tr> - <td><code>example.com</code> embeds an <code><iframe></code> from <code>tracker.example</code>.</td> - <td>HTTP: Yes<br> - JS: Yes</td> - </tr> - <tr> - <td><code>example.com</code> embeds an <code><iframe></code> from <code>example.com</code> (same origin). The nested <code><iframe></code> embeds an <code><iframe></code> from <code>tracker.example</code>.</td> - <td>HTTP: Yes<br> - JS: No</td> - </tr> - </tbody> -</table> - -<h3 id="Storage_access_expiration">Storage access expiration</h3> - -<p>The storage access grant expires after 30 days. Domains classified as tracking resources may be granted third-party storage access on multiple first parties, and the storage permission for each party expires independently. The above heuristics will also serve to extend the lifetime of a third-party storage permission on origins that have already been granted access. Each time the heuristic is activated, or a success call to the Storage Access API is made, the pre-existing storage access expiration will be extended by 30 days, counting from the time the previous access was granted.</p> - -<p>Please note that in the future we expect to make changes to how long storage access will remain valid for. As mentioned before, the way to know that you will be able to use storage as a third-party going forward will be using the Storage Access API.</p> - -<h2 id="Debugging">Debugging</h2> - -<p>We encourage site owners to test their sites, particularly those that rely on third-party content integrations. We’ve added several new features to Firefox to make testing easier.</p> - -<h3 id="Developer_Tools_notifications">Developer Tools notifications</h3> - -<p>The <a href="/en-US/docs/Tools/Network_Monitor">Network Monitor</a> in Firefox Developer Tools now includes an indicator for all resource requests that have been classified as tracking resources. This indicator is shown as a shield icon in the domain column. In the sample image below, <code>trackertest.org</code> is classified as a tracking resource, while the request to example.com is not.</p> - -<p><img alt="network requests in Firefox devtools indicating which ones are tracking resources with a small shield icon" src="https://mdn.mozillademos.org/files/16181/Screen_Shot_2018-09-21_at_10.34.22_AM.png" style="border-style: solid; border-width: 1px; display: block; height: 57px; margin: 0px auto; width: 600px;"></p> - -<h3 id="Adding_custom_domains_to_the_Tracking_Protection_list">Adding custom domains to the Tracking Protection list</h3> - -<p>Curious how things will work if a third-party domain on your site were classified as a tracker? We’ve added a preference that allows you to add custom domains to the Tracking Protection URL classifier. To do so:</p> - -<ol> - <li>Type <code>about:config</code> in your address bar. If you are presented with a page that warns you "This may void your warranty!", click "I accept the risk!"</li> - <li>Right click on the next page and click "New" > "String".</li> - <li>For the preference name enter "urlclassifier.trackingAnnotationTable.testEntries".</li> - <li>For the preference value enter comma separated origins that you’d like to have classified as trackers. E.g. "example.net,example.org".</li> -</ol> - -<div class="warning"> -<p><strong>Warning</strong>: Be sure to remove these entries after you have finished testing.</p> -</div> - -<h2 id="FAQ">FAQ</h2> - -<p>This cookie policy has the potential to lead to site breakage, but has been designed to allow common third-party integrations to continue to work while preventing cross-site tracking. In this section we describe the functionality you can expect in different integration scenarios.</p> - -<h3 id="Will_this_storage_access_policy_block_ads_from_displaying_on_my_website">Will this storage access policy block ads from displaying on my website?</h3> - -<p>No — this feature only restricts access to cookies and site data that can be used to track users across websites. Blocking tracking identifiers does not prevent the display of advertisements.</p> - -<h3 id="I_use_a_third-party_analytics_service_that_is_classified_as_a_tracker._Will_I_still_receive_analytics_data">I use a third-party analytics service that is classified as a tracker. Will I still receive analytics data?</h3> - -<p>This depends on how the third-party analytics service is implemented. Third-party analytics providers will no longer be able to user their third-party storage to collect data. This means that providers using cookies which are scoped to their third-party domain, or local storage and other site data stored under their origin, will no longer have access to those identifiers across other websites.</p> - -<p>If these services are embedded into the main context of the page, they can continue to use first-party cookies and site storage to track users across page visits on that specific first-party domain.</p> - -<h3 id="I_use_third-party_services_for_social_login_like_and_share_button_integration._Will_my_users_still_be_able_to_make_use_of_these_services">I use third-party services for social login, like, and share button integration. Will my users still be able to make use of these services?</h3> - -<p>This depends on how the social integration is implemented. We expect that many of the popular social integrations will continue to function as they do under Firefox’s current cookie policy with some minor differences in the user experience.</p> - -<p>A social content provider that is classified as a tracker will not have access to their third-party cookies when the user first visits a new first party. Thus, the user may appear logged out to the service despite being logged in when they visit the provider’s website directly. Depending on the type of integration, the user may have to take some action to interact with the social content provider before the provider is given access to their cookies. For example:</p> - -<ul> - <li>For social login, the user may have to click a login button on the first party.</li> - <li>For social like or share buttons, the user will have to first interact with the button in a logged-out state. Once they do, many social content providers will prompt them to log in.</li> -</ul> - -<p>After these interactions, the provider will receive third-party storage access if they prompt the user in a way that is captured by the storage access activation heuristics described above. These providers should consider switching to explicitly request storage access through the Storage Access API as soon as possible. An <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1469714">initial implementation of this API</a> is currently available in Nightly.</p> - -<p> </p> - -<h3 id="I_use_third-party_pixels_and_other_tools_to_measure_the_effectiveness_of_my_ad_campaigns._Will_I_still_be_able_to_measure_the_conversion_rate_of_my_ads">I use third-party pixels and other tools to measure the effectiveness of my ad campaigns. Will I still be able to measure the conversion rate of my ads?</h3> - -<p>This depends on how the third party has implemented the measurement tool, but generally ad conversion measurement will be more difficult. Consider the following examples:</p> - -<ol> - <li>You run an ad on a social media website that is seen several times by a user, but never clicked. That user later visits your website, which includes a conversion tracking tag from the same social media website. This type of conversion is often referred to as a “view-through conversion.” Since the social media website does not have access to their third-party storage, they will not recognize the user as the same user that saw the advertisements on their website and the conversion will not be tracked. We expect that most view-through conversion tracking techniques will no longer work, including those offered by display networks.</li> - <li>You run an ad on a display network or social media website that is clicked by a user. That user lands on your website, which includes a conversion tracking tag from the same website that displayed your ad. This type of conversion is often referred to as a “click-through conversion.” Since the social media site or display network will not have access to their third-party storage, they will not recognize the user as the same user that saw the advertisements on their website and the conversion will not be tracked. We expect that this version of click-through conversion will no longer work.</li> - <li>You run an ad that appears on a social media website. A user clicks on your advertisement and is taken to a landing page that contains a conversion tracking tag from the third-party network. On the social media website, the network annotates the advertisement landing page URL with a query parameter that signals that the visit was the result of a click on an advertisement. On your website, the display network’s tag checks the URL query parameters and saves any ad tracking parameters to first-party storage. If a user later completes a conversion event, the network’s tag checks first-party storage to determine which click (or clicks) was responsible for the visit. We expect that click-through conversion implemented in this way will continue to work.</li> -</ol> - -<p> </p> - -<p> </p> diff --git a/files/es/mozilla/firefox/privacy/tracking_protection/index.html b/files/es/mozilla/firefox/privacy/tracking_protection/index.html deleted file mode 100644 index 50dfda6984..0000000000 --- a/files/es/mozilla/firefox/privacy/tracking_protection/index.html +++ /dev/null @@ -1,80 +0,0 @@ ---- -title: Protección contra el rastreo -slug: Mozilla/Firefox/Privacy/Tracking_Protection -tags: - - bloqueo - - navegación privada - - privacidad - - rastreo - - seguimiento -translation_of: Mozilla/Firefox/Privacy/Tracking_Protection ---- -<div>{{FirefoxSidebar}}</div><h2 id="¿Qué_es_la_protección_contra_el_rastreo">¿Qué es la protección contra el rastreo?</h2> - -<p>A partir de la versión 42, Firefox para PC y Firefox para Android cuentan con protección contra el rastreo integrada. En las ventanas de Navegación Privada (o pestañas privadas, en Firefox para Android), Firefox bloqueará el contenido de dominios que rastrean la navegación de los usuarios entre diferentes sitios.</p> - -<p>A veces, algunos contenidos bloqueados son parte de la estructura de la página, y los usuarios notarán problemas de disposición de elementos cuando Firefox realice estos bloqueos. Otras veces los usuarios no notarán nada, si la estructura de la página está diseñada de tal manera que los espacios vacíos dejados por los elementos bloqueados los ocupen otros contenidos.</p> - -<p>Cuando Firefox bloquee contenido, registrará un mensaje como el siguiente en la consola web:</p> - -<pre>The resource at "http://some/url" was blocked because tracking protection is enabled.</pre> - -<p>Nótese que en Firefox para Android uno puede acceder a la salida de la consola usando el depurador remoto.</p> - -<p>La interfaz de usuario de Firefox indica a los usuarios cuándo se ha producido un bloqueo de contenido y les permite desbloquearlo en esa sesión. Si lo desean, también pueden desactivar completamente la protección contra el rastreo. Descubre más en <a href="https://support.mozilla.org/es/kb/navegacion-privada-con-proteccion-contra-el-rastreo">este artículo.</a></p> - -<h2 id="¿Cómo_elige_Firefox_qué_bloquear">¿Cómo elige Firefox qué bloquear?</h2> - -<p>El contenido se bloquea en base al dominio desde el que se carga.</p> - -<p>Firefox se lanza junto con una lista de sitios en los que se ha detectado actividades de rastreo entre diferentes sitios web. Cuando la protección está activada, Firefox bloqueará el contenido de todos los sitios que se encuentran en esa lista.</p> - -<p>Por norma general,, los sitios que hacen este tipo de rastreo son analíticos y de publicidad de terceras partes.</p> - -<h2 id="¿Qué_significa_esto_para_tu_sitio">¿Qué significa esto para tu sitio?</h2> - -<p>Lo más común es que cuando la protección contra rastreo esté activada:</p> - -<ul> - <li>el contenido servido por rastreadores de terceros no será visible para los usuarios;</li> - <li>tu sitio no podrá usar publicidad de terceros o servicios de analíticas cuando estén haciendo seguimiento de tus usuarios.</li> -</ul> - -<p>Lo menos común es que si otras partes de tu sitio dependen de la carga de estos rastreadores, entonces estas partes no funcionarán cuando la protección esté habilitada. Por ejemplo, si tu sitio incluye una llamada (<em>callback</em>) que se ejecuta cuando se carga el contenido de un sitio que rastrea, entonces no se ejecutará esa llamada.</p> - -<p>Por ejemplo, no deberías usar Google Analytics de la siguiente forma:</p> - -<pre class="brush:html example-bad"><a href="http://www.example.com" onclick="trackLink('http://www.example.com', event);">Visit example.com</a> -<script> -function trackLink(url,event) { - event.preventDefault(); - ga('send', 'event', 'outbound', 'click', url, { - 'transport': 'beacon', - 'hitCallback': function() { - document.location = url; - } - }); -} -</script></pre> - -<p>En cambio, deberías tener cuenta la posibilidad de que no se cargue Google Analytics. Para ello, comprueba si se ha iniciado el objeto <code>ga</code>:</p> - -<pre class="brush:html example-good"><a href="http://www.example.com" onclick="trackLink('http://www.example.com', event);">Visit example.com</a> -<script> -function trackLink(url,event) { - event.preventDefault(); - if (window.ga && <span class="pl-smi">ga</span>.loaded) { - ga('send', 'event', 'outbound', 'click', url, { - 'transport': 'beacon', - 'hitCallback': function() { document.location = url; } - }); - } else { - document.location = url; - } -} -</script> -</pre> - -<p>Encontrarás más información sobre esta técnica en <a href="https://hacks.mozilla.org/2016/01/google-analytics-privacy-and-event-tracking/">este artículo (en inglés).</a></p> - -<p>Nótese que, de cualquier manera, la dependencia de terceras partes no es una buena práctica, ya que implica que tu sitio no funcione si la tercera parte va lenta o es inaccesible, o si un complemento bloquea ese elemento rastreador.</p> |