https://wiki.mozilla.org/api.php?action=feedcontributions&user=Sicking&feedformat=atomMozillaWiki - User contributions [en]2024-03-28T14:06:49ZUser contributionsMediaWiki 1.27.4https://wiki.mozilla.org/index.php?title=Modules/Core&diff=1145370Modules/Core2016-08-25T11:29:59Z<p>Sicking: Demoting myself from XBL owner to XBL peer</p>
<hr />
<div><noinclude><br />
'''Only module owners may edit this page.''' <br />
<br />
They may:<br />
<br />
* update any information about their module except the name of the owner<br />
* add or remove sub-modules<br />
* change the owner of a sub-module <br />
* add emeritus owners or peers<br />
<br />
Other changes, including changes of module owner or addition/removal of modules, must be agreed with the Module Ownership Module group, probably via a discussion in [https://www.mozilla.org/about/forums/#governance mozilla.governance].<br />
</noinclude><br />
{{Module<br />
|name=Accessibility<br />
|description=Support for platform accessibility APIs. Accessibility APIs are used by 3rd party software like screen readers, screen magnifiers, and voice dictation software, which need information about document content and UI controls, as well as important events like changes of focus.<br />
|owner=[mailto:surkov.alexander@gmail.com Alexander Surkov]<br />
|peers=[mailto:bolterbugz@gmail.com David Bolter], [mailto:trev.saunders@gmail.com Trevor Saunders], [mailto:marco.zehe@googlemail.com Marco Zehe]<br />
|ownersemeritus=[mailto:aaron@moonset.net. Aaron Leventhal]<br />
|peersemeritus=[mailto:ginn.chen@oracle.com Ginn Chen], Evan Yan<br />
|group=dev-accessibility<br />
|source_dirs=accessible/<br />
|url=http://www.mozilla.org/access/<br />
|components=Core::Disability Access APIs<br />
}}<br />
<br />
{{Module<br />
|name=Browser WebAPI<br />
|description=Web API for rendering apps, browser windows and widgets.<br />
|owner=[mailto:kchen@mozilla.com Kan-Ru Chen]<br />
|peers=[mailto:Olli.Pettay@helsinki.fi Olli Pettay], [mailto:fabrice@mozilla.com Fabrice Desré]<br />
|group=dev-webapi<br />
|source_dirs=dom/browser-element/<br />
|url=<br />
|components=Core::DOM<br />
}}<br />
<br />
{{Module<br />
|name=Build and Release Tools<br />
|description=Tools related to build and release automation and configuration of release builds.<br />
|owner=[mailto:nthomas@mozilla.com Nick Thomas]<br />
|peers=[mailto:bhearsum@mozilla.com Ben Hearsum], [mailto:coop@mozilla.com Chris Cooper]<br />
|group=release-engineering<br />
|source_dirs=browser/config/mozconfigs/, mobile/android/config/mozconfigs/, xulrunner/config/mozconfigs/, b2g/config/, tools/update-packaging/<br />
|url=https://wiki.mozilla.org/ReleaseEngineering<br />
|components=Release Engineering::*<br />
}}<br />
<br />
{{Module<br />
|name=Build Config<br />
|description=The build system for Gecko and several mozilla.org hosted Gecko-based applications.<br />
|owner=[mailto:gps@mozilla.com Gregory Szorc] (:gps)<br />
|peers=[mailto:mh@glandium.org Mike Hommey] (:glandium), [mailto:mshal@mozilla.com Mike Shal] (:mshal), [mailto:ted@mielczarek.org Ted Mielczarek] (:ted), [mailto:cmanchester@mozilla.com Chris Manchester](:chmanchester)<br />
|ownersemeritus=Ted Mielczarek (2008-[https://blog.mozilla.org/ted/2013/03/07/gregory-szorc-is-now-the-build-config-module-owner/ 2013]), Benjamin Smedberg (???-[http://benjamin.smedbergs.us/blog/2008-04-30/more-changing-of-the-guard-ted-mielczarek/ 2008]), <br />
|group=dev-builds<br />
|source_dirs=build/, config/, python/mozbuild, tools/cross-commit, tools/cvs2hg-import.py, tools/cvsmgmt/, tools/elf-dynstr-gc/, tools/trees.pl, browser/config/mozconfigs/, mobile/config/mozconfigs/, xulrunner/config/mozconfigs/<br />
|url=http://www.mozilla.org/build/<br />
|components=Core::Build Config<br />
}}<br />
<br />
{{Module<br />
|name=Code Analysis and Debugging Tools<br />
|description=Tools for debugging Mozilla code or for analyzing speed, memory use, and other characteristics of it.<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|peers=<br />
|group=dev-performance<br />
|source_dirs=tools/codesighs/, tools/debug/, tools/dreftool/, tools/dumpdeps/, tools/footprint/, tools/jprof/, tools/leaky/, tools/memory/, tools/module-deps/, tools/performance/, tools/post_compile/, tools/preloader/, tools/rb/, tools/reorder/, tools/trace-malloc/, tools/uuiddeps/, <br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Content HTTP Headers<br />
|description=HTTP headers related to content, e.g. User-Agent, Content-Type, Accept. (Transport-related headers are the responsibility of the Necko module owner.)<br />
|owner=[mailto:gerv@mozilla.org Gervase Markham]<br />
|peers=[mailto:lmandel@mozilla.com Lawrence Mandel]<br />
|group=dev-platform<br />
|source_dirs= <br />
|url=https://developer.mozilla.org/en/Gecko_user_agent_string_reference<br />
|components=Core::Networking: HTTP<br />
}}<br />
<br />
{{Module<br />
|name=Content Security<br />
|description=Native content-based security features, including: Content Security Policy (CSP), Mixed Content Blocker (MCB), Subresource Integrity (SRI) and CORS.<br />
|owner=[mailto:ckerschbaumer@mozilla.com Christoph Kerschbaumer]<br />
|peers=[mailto:francois@mozilla.com François Marier], [mailto:jonas@sicking.cc Jonas Sicking], [mailto:tvyas@mozilla.com Tanvi Vyas], [mailto:dveditz@mozilla.com Dan Veditz], [mailto:mozilla@sidstamm.com Sid Stamm] <br />
|group=dev-security<br />
|source_dirs=dom/security<br />
|components=Core::DOM: Security<br />
}}<br />
<br />
{{Module<br />
|name=Cookies and Permissions<br />
|description=<br />
|owner=Monica Chew<br />
|peers=[mailto:josh@joshmatthews.com Josh Matthews], [mailto:ehsan@mozilla.com Ehsan Akhgari], [mailto:mconnor@steelgryphon.com Mike Connor], [mailto:dwitte@gmail.com Dan Witte], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:sdwilsh@shawnwilsher.com Shawn Wilsher (ping on irc)]<br />
|group=dev-tech-network<br />
|source_dirs=extensions/cookie/, netwerk/cookie/<br />
|url=<br />
|components=Core::Networking: Cookies<br />
}}<br />
{{Module<br />
|name=Cycle Collector<br />
|description=Code to break and collect objects within reference cycles<br />
|owner=[https://mozillians.org/en-US/u/mccr8/ Andrew McCreight]<br />
|peers=Peter Van der Beken, Olli Pettay, David Baron<br />
|source_dirs=xpcom/base/nsCycleCollector.* and some support headers<br />
|components=Core::XPCOM<br />
|group=dev-platform<br />
}}<br />
{{Module<br />
|name=docshell<br />
|description=<br />
|owner=[mailto:bzbarsky@mit.edu Boris Zbarsky]<br />
|peers=[mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:jst@mozilla.org Johnny Stenback], [mailto:Olli.Pettay@helsinki.fi Olli Pettay], [mailto:justin.lebar@gmail.com Justin Lebar]<br />
|group=dev-tech-layout<br />
|source_dirs=docshell/, uriloader/<br />
|url=<br />
|components=Core::Document Navigation<br />
}}<br />
<br />
{{Module<br />
|name=Device Storage<br />
|description=Support for the device storage API<br />
|owner=[https://mozillians.org/u/dhylands/ Dave Hylands] (:dhylands), [mailto:jvarga@mozilla.com Jan Varga] (:janv)<br />
|peers=<br />
|ownersemeritus=[mailto:doug.turner@gmail.com Doug Turner] (:dougt)<br />
|group=dev-tech-dom<br />
|source_dirs=dom/devicestorage/, dom/interfaces/devicestorage/<br />
|url=https://developer.mozilla.org/en-US/docs/WebAPI/Device_Storage<br />
|components=Core::DOM: Device Interfaces<br />
}}<br />
<br />
{{Module<br />
|name=Document Object Model<br />
|description=<br />
|owner=[mailto:jst@mozilla.org Johnny Stenback], [mailto:peterv@propagandism.org Peter Van der Beken]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:jonas@sicking.cc Jonas Sicking], [mailto:Olli.Pettay@helsinki.fi Olli Pettay], [mailto:bent@mozilla.com Ben Turner], [mailto:mounir@lamouri.fr Mounir Lamouri (still active, but slower to respond than previously)], [mailto:me@kylehuey.com Kyle Huey], [mailto:justin.lebar@gmail.com Justin Lebar], [mailto:hsivonen@iki.fi Henri Sivonen], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:bobbyholley@gmail.com Bobby Holley], [mailto:baku@mozilla.com Andrea Marchesini],<br />
[mailto:ehsan@mozilla.com Ehsan Akhgari], [mailto:bkelly@mozilla.com Ben Kelly]<br />
|group=dev-tech-dom<br />
|source_dirs=dom/*, except directories covered by other modules<br />
|url=http://developer.mozilla.org/en/docs/DOM<br />
|components=Core::DOM, Core::DOM: CSS Object Model, Core::DOM: Core & HTML<br />
}}<br />
<br />
{{Module<br />
|name=Event Handling<br />
|description=DOM Events and Event Handling <br />
|owner=[mailto:olli@pettay.fi Olli Pettay], [mailto:masayuki@d-toybox.com Masayuki Nakano]<br />
|group=dev-platform<br />
|source_dirs=dom/events and event handling related code elsewhere <br />
|url=http://developer.mozilla.org/en/docs/DOM<br />
|components=Core::DOM: Events, Core::Event Handling<br />
}}<br />
<br />
{{Module<br />
|name=Web Workers<br />
|description=<br />
|owner=[mailto:bent@mozilla.com Ben Turner]<br />
|peers=[mailto:mrbkap@mozilla.com Blake Kaplan], [mailto:jonas@sicking.cc Jonas Sicking], [mailto:me@kylehuey.com Kyle Huey]<br />
|group=dev-platform<br />
|source_dirs=dom/workers/<br />
|url=https://developer.mozilla.org/En/Using_web_workers<br />
|components=Core::DOM: Workers<br />
}}<br />
<br />
{{Module<br />
|name=IndexedDB<br />
|description=<br />
|owner=[mailto:bent@mozilla.com Ben Turner]<br />
|peers=[mailto:jonas@sicking.cc Jonas Sicking], [mailto:me@kylehuey.com Kyle Huey], [mailto:jvarga@mozilla.com Jan Varga]<br />
|group=dev-platform<br />
|source_dirs=dom/indexedDB/<br />
|url=https://developer.mozilla.org/en/IndexedDB<br />
|components=Core::DOM: IndexedDB<br />
}}<br />
<br />
{{Module<br />
|name=Editor<br />
|description=<br />
|owner=[mailto:masayuki@d-toybox.com Masayuki Nakano]<br />
|peers=[mailto:ayg@aryeh.name Aryeh Gregor]<br />
|ownersemeritus=[mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|group=dev-platform<br />
|source_dirs=editor/<br />
|url=http://www.mozilla.org/editor/<br />
|components=Core::Editor<br />
}}<br />
<br />
{{Module<br />
|name=Embedding<br />
|description=<br />
|owner=[mailto:benjamin@smedbergs.us Benjamin Smedberg]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:jst@mozilla.org Johnny Stenback]<br />
|group=dev-embedding<br />
|source_dirs=embedding/<br />
|url=<br />
|components=Core::Embedding: APIs, Core::Embedding: ActiveX Wrapper, Core::Embedding: GRE Core, Core::Embedding: GTK Widget, Core::Embedding: MFC Embed, Core::Embedding: Mac, Core::Embedding: Packaging<br />
}}<br />
<br />
{{Module<br />
|name=Find As You Type<br />
|description=Find As You Type (formerly called Type Ahead Find) is a feature that allows quick web page navigation when you type a succession of characters in the body of the displayed page (not in an edit box of or drop down list). Currently seeks new owner.<br />
|owner=<br />
|peers=<br />
|group=dev-accessibility<br />
|source_dirs=extensions/typeaheadfind/<br />
|url=http://www.mozilla.org/access/type-ahead/<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Geolocation<br />
|description=Implementation of the Geolocation W3C Spec, location provider apis, and wifi scanning code.<br />
|owner=[mailto:doug.turner@gmail.com Doug Turner]<br />
|peers=[mailto:josh@joshmatthews.net Josh Matthews], [mailto:kchen@mozilla.com Kan-Ru Chen], Garvan Keeley<br />
|group=dev-tech-dom<br />
|source_dirs=dom/geolocation, dom/system/, netwerk/wifi<br />
|url=https://developer.mozilla.org/En/Using_geolocation<br />
|components=Core::Geolocation<br />
}}<br />
<br />
{{Module<br />
|name=Global Key Bindings<br />
|description=Global hot keys in Mozilla for the browser, editor, mail-news and widgets. Does not include underlined menu accelerators and the like, as those are part of i18n.<br />
|owner=Aaron Leventhal<br />
|peers=[mailto:neil@parkwaycc.co.uk Neil Rashbrook]<br />
|group=dev-accessibility<br />
|source_dirs=dom/xbl/builtin/<br />
|url=http://www.mozilla.org/projects/ui/accessibility/mozkeyintro.html<br />
|components=Core::Keyboard: Navigation<br />
}}<br />
<br />
{{Module<br />
|name=Graphics<br />
|description=Mozilla graphics API<br />
|owner=[mailto:jrmuizel@mozilla.com Jeff Muizelaar](Thebes, QCMS, YCbCr, Cairo/Pixman, Regions, OS X, Other)<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|peers=[mailto:jdrew@mozilla.com Joe Drew], [mailto:vladimir@pobox.com Vladimir Vukicevic], [mailto:bas.schouten@live.nl Bas Schouten](Layers, Windows), [mailto:bjacob@mozilla.com Benoit Jacob](gfx/gl), [mailto:bgirard@mozilla.com Benoit Girard](Compositor, Performance), [mailto:ajuma.bugzilla@alijuma.com Ali Juma], [mailto:jgilbert@mozilla.com Jeff Gilbert](WebGL, ANGLE), [mailto:george@mozilla.com George Wright](Canvas2D, Skia), [mailto:mwoodrow@mozilla.com Matt Woodrow](Layers API), [mailto:jdaggett@mozilla.com John Daggett](text/fonts), [mailto:jfkthame@googlemail.com Jonathan Kew](text/fonts), [mailto:nsilva@mozilla.com Nicolas Silva](MozSurface), [mailto:ncameron@mozilla.com Nick Cameron], [mailto:sikeda@mozilla.com Sotaro Ikeda](B2G), [mailto:snorp@mozilla.com James Willcox](Android), [mailto:clord@mozilla.com Christopher Lord], [mailto:mstange@themasta.com Markus Stange](OS X)<br />
|group=dev-platform<br />
|source_dirs=gfx/, dom/canvas/<br />
|url=https://wiki.mozilla.org/Platform/GFX https://wiki.mozilla.org/Gecko:Layers https://wiki.mozilla.org/Gecko:2DGraphicsSketch<br />
|components=Core::Graphics, Core::Graphics: Layers, Core::Graphics: Text, Core::GFX: Color Management, Core::Canvas: 2D, Core::Canvas: WebGL<br />
}}<br />
<br />
{{Module<br />
|name=APZ (Graphics submodule)<br />
|description=Asynchronous panning and zooming<br />
|owner=[mailto:kgupta@mozilla.com Kartikaya Gupta]<br />
|peers=[mailto:bballo@mozilla.com Botond Ballo], [mailto:tnikkel@mozilla.com Timothy Nikkel], [mailto:dvander@mozilla.com David Anderson], [mailto:mstange@mozilla.com Markus Stange]<br />
|group=dev-platform<br />
|source=gfx/layers/apz<br />
|url=https://wiki.mozilla.org/Platform/GFX/APZ<br />
|components=Core::Panning and Zooming<br />
}}<br />
<br />
{{Module<br />
|name=Moz2D (Graphics submodule)<br />
|description=Platform independent 2D graphics API<br />
|owner=[mailto:bschouten@mozilla.com Bas Schouten]<br />
|peers=[mailto:jmuizelaar@mozilla.com Jeff Muizelaar], [mailto:gwright@mozilla.com George Wright], [mailto:jwatt@mozilla.com Jonathan Watt]<br />
|group=dev-platform<br />
|source=gfx/2d<br />
|url=https://wiki.mozilla.org/Platform/GFX/Moz2D<br />
|components=Core::Graphics<br />
}}<br />
<br />
<br />
{{Module<br />
|name=GTK Embedding Widget<br />
|description=Gtk Widget for embedding Mozilla into Gtk applications<br />
|owner=Marco Pesenti Gritti<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:doug.turner@gmail.com Doug Turner]<br />
|group=dev-embedding<br />
|source_dirs=<br />
|url=<br />
|components=Core::Embedding: GTK Widget<br />
}}<br />
<br />
{{Module<br />
|name=Legacy HTML Parser<br />
|description=<br />
|owner=[mailto:mrbkap@gmail.com Blake Kaplan]<br />
|peers=[mailto:dbaron@dbaron.org David Baron], [mailto:jst@mozilla.org Johnny Stenback], [mailto:peterv@propagandism.org Peter Van der Beken], [mailto:rbs@maths.uq.edu.au rbs@maths.uq.edu.au]<br />
|group=dev-tech-dom<br />
|source_dirs=parser/htmlparser<br />
|url=http://www.mozilla.org/newlayout/doc/parser.html<br />
|components=Core::HTML: Parser<br />
}}<br />
<br />
{{Module<br />
|name=HAL<br />
|description=Hardware Abstraction Layer<br />
|owner=[https://mozillians.org/u/dhylands/ Dave Hylands]<br />
|peers=[mailto:gsvelto@mozilla.com Gabriele Svelto]<br />
|group=dev-platform<br />
|source_dirs=hal/<br />
|components=Core::Hardware Abstraction Layer (HAL)<br />
}}<br />
<br />
{{Module<br />
|name=HTML Parser<br />
|description=The HTML Parser transforms HTML source code into a DOM. It conforms to the HTML specification, and is mostly translated automatically from Java to C++.<br />
|owner=[mailto:hsivonen@iki.fi Henri Sivonen]<br />
|peers=<br />
|group=dev-tech-dom<br />
|source_dirs=parser/html<br />
|url=http://about.validator.nu/<br />
|components=Core::HTML: Parser<br />
}}<br />
<br />
{{Module<br />
|name=I18N Library<br />
|description=<br />
|owner=[mailto:jshin1987@gmail.com Jungshik Shin], [mailto:smontagu@smontagu.org Simon Montagu]<br />
|peers=[mailto:VYV03354@nifty.ne.jp Masatoshi Kimura]<br />
|group=dev-i18n<br />
|source_dirs=intl/<br />
|url=http://mozilla.org/projects/intl/index.html<br />
|components=Core::Internationalization<br />
}}<br />
<br />
{{Module<br />
|name=ImageLib<br />
|description=<br />
|owner=[mailto:seth@mozilla.com Seth Fowler]<br />
|peers=[mailto:netzen@gmail.com Brian Bondy], [mailto:jmuizelaar@mozilla.com Jeff Muizelaar], [mailto:jlebar@mozilla.com Justin Lebar], [mailto:tnikkel@gmail.com Timothy Nikkel]<br />
|group=dev-platform<br />
|source_dirs=media/libjpeg/, media/libpng/, image/, modules/zlib/<br />
|url=<br />
|components=Core::ImageLib<br />
}}<br />
<br />
{{Module<br />
|name=IPC<br />
|description=Message-passing between threads and processes<br />
|owner=[mailto:wmccloskey@mozilla.com Bill McCloskey]<br />
|peers=[mailto:danderson@mozilla.com David Anderson], [mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:bent.mozilla@gmail.com Ben Turner], [mailto:jld@mozilla.com Jed Davis]<br />
|group=dev-platform<br />
|source_dirs=ipc/glue/, ipc/ipdl/, ipc/chromium/<br />
|url=<br />
|components=Core::IPC}}<br />
<br />
{{Module<br />
|name=JavaScript<br />
|description=JavaScript engine (SpiderMonkey)<br />
|owner=[mailto:jorendorff@mozilla.com Jason Orendorff]<br />
|peers=[mailto:jdemooij@mozilla.com Jan de Mooij], [mailto:wmccloskey@mozilla.com Bill McCloskey], [mailto:nnethercote@mozilla.com Nick Nethercote], [mailto:jwalden@mit.edu Jeff Walden], [mailto:hv1989@gmail.com Hannes Verschore], [mailto:kvijayan@mozilla.com Kannan Vijayan], [mailto:shu@mozilla.com Shu-yu Guo], [mailto:evilpies@gmail.com Tom Schuster], [mailto:bhackett1024@gmail.com Brian Hackett], [mailto:till@tillschneidereit.net Till Schneidereit], [mailto:efaust@mozilla.com Eric Faust], [mailto:nfitzgerald@mozilla.com Nick Fitzgerald], [mailto:luke@mozilla.com Luke Wagner], [mailto:arai.unmht@gmail.com Tooru Fujisawa], [mailto:sunfish@mozilla.com Dan Gohman], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:bobbyholley@gmail.com Bobby Holley], [mailto:nmatsakis@mozilla.com Niko Matsakis], [mailto:ejpbruel@mozilla.com Eddy Bruel], [mailto:danderson@mozilla.com David Anderson], [mailto:igor@mir2.org Igor Bukanov], [mailto:brendan@mozilla.org Brendan Eich], Andreas Gal<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/src<br />
|url=http://www.mozilla.org/js/spidermonkey,<br />
http://developer.mozilla.org/en/docs/About_JavaScript<br />
|components=Core::JavaScript Engine<br />
}}<br />
<br />
{{Module<br />
|name=JavaScript JIT<br />
|description=JavaScript engine's JIT compilers (IonMonkey, Baseline)<br />
|owner=[mailto:jdemooij@mozilla.com Jan de Mooij]<br />
|peers=[mailto:danderson@mozilla.com David Anderson], [mailto:bbouvier@mozilla.com Benjamin Bouvier], [mailto:shu@mozilla.com Shu-yu Guo], [mailto:bhackett1024@gmail.com Brian Hackett], [mailto:nicolas.b.pierron@mozilla.com Nicolas Pierron], [mailto:evilpies@gmail.com Tom Schuster], [mailto:sstangl@mozilla.com Sean Stangl], [mailto:hv1989@gmail.com Hannes Verschore], [mailto:kvijayan@mozilla.com Kannan Vijayan], [mailto:luke@mozilla.com Luke Wagner]<br />
|group=dev-tech-js-engine-internals<br />
|source_dirs=js/src/jit<br />
|url=http://www.mozilla.org/js/spidermonkey<br />
|components=Core::JavaScript Engine: JIT<br />
}}<br />
<br />
{{Module<br />
|name=JavaScript Debugger Backend<br />
|description=JavaScript debugging hooks<br />
|owner=[mailto:timeless@mozdev.org Josh 'timeless' Soref]<br />
|peers=[mailto:brendan@mozilla.org Brendan Eich], [mailto:rginda@hacksrus.com Rob Ginda]<br />
|group=dev-apps-js-debugger<br />
|source_dirs=js/jsd/<br />
|url=http://www.mozilla.org/js/jsd<br />
|components=Other Applications::Venkman JS Debugger<br />
}}<br />
<br />
{{Module<br />
|name=jsat<br />
|description=Javascript screen reader that is used in Android and B2G<br />
|owner=[mailto:eitan@monotonous.org Eitan Isaacson]<br />
|peers=[mailto:yzenevich@mozilla.com Yura Zenevich]<br />
|group=dev-accessibility<br />
|source_dirs=accessible/jsat/<br />
|url=http://www.mozilla.org/access/<br />
|components=Core::Disability Access APIs<br />
}}<br />
<br />
{{Module<br />
|name=js-ctypes<br />
|description=A foreign function interface which allows privileged JS code to interact with binary code without using XPCOM/XPConnect.<br />
|owner=[mailto:jorendorff@mozilla.com Jason Orendorff]<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:bobbyholley@gmail.com Bobby Holley]<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/src/ctypes/<br />
|url=https://wiki.mozilla.org/JSctypes<br />
|components=Core::js-ctypes<br />
}}<br />
<br />
{{Module<br />
|name=js-tests<br />
|description=JavaScript test suite<br />
|owner=[mailto:bclary@bclary.com Bob Clary]<br />
|peers=<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/tests/<br />
|url=http://www.mozilla.org/js/tests/library.html<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Layout Engine<br />
|description=rendering tree construction, layout (reflow), painting, etc.<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|peers=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:dholbert@mozilla.com Daniel Holbert], [mailto:jfkthame@gmail.com Jonathan Kew], [mailto:tnikkel@gmail.com Timothy Nikkel], [mailto:matt.woodrow@gmail.com Matt Woodrow], [mailto:xidorn+moz@upsuper.org Xidorn Quan]<br />
|group=dev-tech-layout<br />
|source_dirs=layout/%, layout/base/, layout/build/, layout/doc/, layout/forms/, layout/generic/, layout/html/, layout/macbuild/, layout/printing/, layout/tables/, layout/tools/<br />
|url=http://mozilla.org/newlayout/doc/ ,<br />
http://lxr.mozilla.org/mozilla/source/layout/doc/<br />
|components=Core::Layout, Core::Layout: Block and Inline, Core::Layout: Floats, Core::Layout: Form Controls, Core::Layout: HTML Frames, Core::Layout: Images, Core::Layout: Misc Code, Core::Layout: R & A Pos, Core::Layout: Tables, Core::Layout: Text, Core::Layout: View Rendering, Core::Print Preview, Core::Printing: Output<br />
}}<br />
<br />
{{Module<br />
|name=libjar<br />
|description=The JAR handling code (protocol handler, stream implementation, and zipreader/zipwriter).<br />
|owner=[mailto:mwu@mozilla.com Michael Wu]<br />
|peers=[mailto:aklotz@mozilla.com Aaron Klotz]<br />
|group=dev-platform<br />
|source_dirs=modules/libjar<br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=MathML<br />
|description=MathML is a low-level specification for describing mathematics which provides a foundation for the inclusion of mathematical expressions in Web pages.<br />
|owner=[mailto:karlt+@karlt.net Karl Tomlinson]<br />
|peers=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|group=dev-tech-mathml<br />
|source_dirs=layout/mathml/<br />
|url=http://www.mozilla.org/projects/mathml/<br />
|components=Core::MathML<br />
}}<br />
<br />
{{Module<br />
|name=Media Playback<br />
|description=HTML Media APIs, including Media Source Extensions and non-MSE video/audio element playback, and Encrypted Media Extensions. (WebRTC and WebAudio not included).<br />
|owner=[mailto:cpearce@mozilla.com Chris Pearce]<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|peers=[mailto:ajones@mozilla.com Anthony Jones], [mailto:kinetik@flim.org Matthew Gregan], [mailto:eflores@mozilla.com Edwin Flores], [mailto:jyavenard@mozilla.com Jean-Yves Avenard], [mailto:gsquelart@mozilla.com Gerald Squelart], [mailto:rgiles@mozilla.com Ralph Giles], [mailto:jwwang@mozilla.com JW Wang]<br />
|group=dev-media<br />
|source_dirs=dom/media, media/gmp-clearkey/, media/libcubeb/, media/libnestegg/, media/libogg/, media/libopus/, media/libstagefright/, media/libtheora/, media/libtremor/, media/libvorbis/, media/libvpx/, media/omx-plugin/, media/rlz/<br />
|url=<br />
|components=Core::Audio/Video<br />
}}<br />
<br />
{{Module<br />
|name=Media Transport<br />
|description=Pluggable transport for real-time media<br />
|owner=[mailto:ekr@rtfm.com Eric Rescorla]<br />
|peers=[mailto:bcampen@mozilla.com Byron Campen], [mailto:abr@mozilla.com Adam Roach]<br />
|group=dev-media<br />
|source_dirs=media/mtransport<br />
|url=<br />
|components=Core::WebRTC::Networking<br />
}}<br />
<br />
{{Module<br />
|name=Memory Allocator<br />
|description=Most things related to memory allocation in Gecko, including jemalloc, replace-malloc, DMD (dark matter detector), logalloc, etc.<br />
|owner=[mailto:mh+mozilla@glandium.org Mike Hommey]<br />
|peers=[mailto:n.nethercote@gmail.com Nicholas Nethercote]<br />
|group=dev-platform<br />
|source_dirs=memory/<br />
|components=Core::DMD, Core::jemalloc<br />
}}<br />
<br />
{{Module<br />
|name=mfbt<br />
|description=mfbt is a collection of headers, macros, data structures, methods, and other functionality available for use and reuse throughout all Mozilla code (including SpiderMonkey and Gecko more broadly).<br />
|owner=[mailto:jwalden@mit.edu Jeff Walden]<br />
|peers=[mailto:froydnj@mozilla.com Nathan Froyd], [mailto:Ms2ger@gmail.com Ms2ger], [mailto:mh+mozilla@glandium.org Mike Hommey]<br />
|group=dev-platform<br />
|source_dirs=mfbt/<br />
|url=<br />
|components=Core::MFBT<br />
}}<br />
<br />
{{Module<br />
|name=mozApps API & UI<br />
|description=Implementation of the navigator.mozApps API<br />
|owner=[mailto:fabrice@mozilla.com Fabrice Desré], [mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|peers=[mailto:myk@mozilla.org Myk Melez], [mailto:mar.castelluccio@studenti.unina.it Marco Castelluccio], [mailto:ferjmoreno@gmail.com Fernando Jiménez]<br />
|group=dev-webapi<br />
|source_dirs=dom/apps/, dom/interfaces/apps, product specific files implementing UI hooks.<br />
|url=<br />
|components=Core::DOM: Apps<br />
}}<br />
<br />
{{Module<br />
|name=Mozglue<br />
|description=Glue library containing various low-level functionality, including a dynamic linker for Android, a DLL block list for Windows, etc.<br />
|owner=[mailto:mh+mozilla@glandium.org Mike Hommey]<br />
|peers=[mailto:froydnj@mozilla.com Nathan Froyd] (mozglue/linker), [mailto:kgupta@mozilla.com Kartikaya Gupta] (mozglue/android), [mailto:nchen@mozilla.com Jim Chen] (mozglue/android)<br />
|group=dev-platform<br />
|source_dirs=mozglue/<br />
|components=Core::mozglue<br />
}}<br />
<br />
{{Module<br />
|name=mozilla-toplevel<br />
|description=The top level directory for the mozilla tree.<br />
|owner=[mailto:brendan@mozilla.org Brendan Eich]<br />
|peers=<br />
|group=<br />
|source_dirs=tools/README<br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Necko<br />
|description=The Mozilla Networking Library<br />
|owner=[mailto:mcmanus@ducksong.com Patrick McManus]<br />
|peers= [mailto:jduell.mcbugs@gmail.com Jason Duell], [mailto:honzab.moz@firemni.cz Honza Bambas], [mailto:mnovotny@mozilla.com Michal Novotny], [mailto:hurley@mozilla.com Nick Hurley], [mailto:dd.mozilla@gmail.com Dragana Damjanovic ],[mailto:valentin.gosu@gmail.com Valentin Gosu],[mailto:daniel@haxx.se Daniel Stenberg ]<br />
|peersemeritus= [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:sworkman@mozilla.com Steve Workman]<br />
|group=dev-tech-network<br />
|source_dirs=netwerk/%, netwerk/base/, netwerk/build/, netwerk/cache/, netwerk/dns/, netwerk/locales/, netwerk/mime/, netwerk/protocol/, netwerk/resources/, netwerk/socket/, netwerk/streamconv/, netwerk/system/, netwerk/test/, netwerk/testserver/<br />
|url=http://www.mozilla.org/projects/netlib/, https://developer.mozilla.org/en/Necko<br />
|components=Core::Networking, Core::Networking: Cache, Core::Networking: Cookies, Core::Networking: FTP, Core::Networking: File, Core::Networking: HTTP, Core::Networking: JAR, Core::Networking: Websockets<br />
}}<br />
<br />
{{Module<br />
|name=NSPR<br />
|description=Netscape Portable Runtime<br />
|owner=[mailto:ted@mielczarek.org Ted Mielczarek]<br />
|peers=[mailto:wtc@google.com Wan-Teh Chang], [mailto:mh@glandium.org Mike Hommey], [mailto:kaie@kuix.de Kai Engert]<br />
|group=dev-tech-nspr<br />
|source_dirs=nsprpub/<br />
|url=http://www.mozilla.org/projects/nspr/<br />
http://www.mozilla.org/projects/nspr/reference/html/<br />
http://www.mozilla.org/projects/nspr/release-notes/<br />
|components=NSPR<br />
}}<br />
<br />
{{Module<br />
|name=PDF<br />
|description=Rendering code to display documents encoded in the ISO 32000-1 `PDF' format.<br />
|owner=Chris Jones, Andreas Gal<br />
|peers=[mailto:aadib@mozilla.com Artur Adib], [mailto:bdahl@mozilla.com Brendan Dahl], [mailto:vnicolas@mozilla.com Vivien Nicolas]<br />
|group=dev-platform<br />
|source_dirs=media/pdf/<br />
|url=https://github.com/mozilla/pdf.js<br />
|components=Core::PDF<br />
}}<br />
<br />
{{Module<br />
|name=Plugins<br />
|description= NPAPI Plugin support.<br />
|owner=[mailto:jmathies@mozilla.com Jim Mathies]<br />
|peers=[mailto:jst@mozilla.org Johnny Stenback], [mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:joshmoz@gmail.com Josh Aas]<br />
|peersemeritus=[mailto:john@pointysoftware.net John Schoenick], [mailto:robert@ocallahan.org Robert O'Callahan]<br />
|group=<br />
|source_dirs=dom/plugins/, modules/plugin/<br />
|url=https://wiki.mozilla.org/Plugins<br />
|components=Core::Plug-ins<br />
}}<br />
<br />
{{Module<br />
|name=Preferences<br />
|description=Preference library<br />
|owner=<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg]<br />
|group=dev-platform<br />
|source_dirs=modules/libpref/<br />
|url=<br />
|components=Core::Preferences: Backend<br />
}}<br />
<br />
{{Module<br />
|name=Private Browsing<br />
|description=Implementation of the Private Browsing mode, and the integration of other modules with Private Browsing APIs.<br />
|owner=[mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|peers=[mailto:josh@joshmatthews.net Josh Matthews]<br />
|group=dev-platform<br />
|source_dirs=Implementation and consumers of Private Browsing APIs in nsILoadContext, nsIPrivateBrowsingChannel, PrivateBrowsingUtils.jsm and the related glue code. <br />
|url=https://wiki.mozilla.org/Private_Browsing<br />
|components=Firefox::Private Browsing<br />
}}<br />
<br />
{{Module<br />
|name=Privilege Manager<br />
|description="caps"<br />
|owner=[mailto:bobbyholley@gmail.com Bobby Holley]<br />
|peers=[mailto:brendan@mozilla.org Brendan Eich], [mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:dveditz@mozilla.com Dan Veditz], [mailto:jst@mozilla.org Johnny Stenback]<br />
|group=dev-tech-dom<br />
|source_dirs=caps/<br />
|url=http://www.mozilla.org/projects/security/components/index.html<br />
|components=Core::Security: CAPS<br />
}}<br />
<br />
{{Module<br />
|name=Push Notifications<br />
|description=Push is a way for application developers to send messages to their web applications.<br />
|owner=[mailto:doug.turner@gmail.com Doug Turner]<br />
|peers=[mailto:nsm.nikhil@gmail.com Nikhil Marathe], [mailto:kcambridge@mozilla.com Kit Cambridge], [mailto:martin.thomson@gmail.com Martin Thomson], [mailto:ddamjanovic@mozilla.com Dragana Damjanovic]<br />
|group=<br />
|source_dirs=dom/push, dom/simplepush<br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=PyXPCOM<br />
|description=The Python to XPCOM bridge.<br />
|owner=Todd Whiteman<br />
|peers=[mailto:mhammond@skippinet.com.au Mark Hammond]<br />
|group=<br />
|source_dirs=extension/python<br />
|url=https://developer.mozilla.org/en/PyXPCOM<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Qt-based gfx and widget<br />
|description=Qt-based rendering and widget code<br />
|owner=[mailto:romaxa@gmail.com Oleg Romashin]<br />
|peers=[mailto:mozilla@rosenauer.org Wolfgang Rosenauer], [mailto:doug.turner@gmail.com Doug Turner]<br />
|group=dev-tech-widget<br />
|source_dirs=widget/qt/<br />
|url=<br />
|components=Core::Widget: Qt<br />
}}<br />
<br />
{{Module<br />
|name=RDF<br />
|description=<br />
|owner=[mailto:axel@pike.org Axel Hecht]<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg]<br />
|group=dev-tech-rdf<br />
|source_dirs=rdf/<br />
|url=http://www.mozilla.org/rdf/doc/<br />
|components=Core::RDF<br />
}}<br />
<br />
{{Module<br />
|name=security<br />
|description=Crypto/PKI code, including NSS (Network Security Services) and JSS (NSS for Java)<br />
|owner=[mailto:rrelyea@redhat.com Bob Relyea], [mailto:wtc@google.com Wan-Teh Chang]<br />
|peers=[mailto:emaldona@redhat.com Elio Maldonado], [mailto:kaie@kuix.de Kai Engert], [mailto:ryan.sleevi@gmail.com Ryan Sleevi], [mailto:ekr@rtfm.com Eric Rescorla], [mailto:franziskuskiefer@gmail.com Franziskus Kiefer], [mailto:martin.thomson@gmail.com Martin Thomson], [mailto:ttaubert@mozilla.com Tim Taubert]<br />
|group=dev-tech-crypto<br />
|source_dirs=dbm/, security/coreconf/, security/dbm/, security/jss/, security/nss/, security/tinderbox/, security/tinderlight/<br />
|url=http://mozilla.org/projects/security/pki/<br />
|components=NSS, JSS, Core::Security, Core::Security: S/MIME<br />
}}<br />
<br />
{{Module<br />
|name=Security - Mozilla PSM Glue<br />
|description=Personal Security Manager<br />
|owner=[mailto:dkeeler@mozilla.com David Keeler]<br />
|peers=[mailto:honzab.moz@firemni.cz Honza Bambas], [mailto:cykesiopka.bmo@gmail.com Cykesiopka]<br />
|group=dev-tech-crypto<br />
|source_dirs=security/manager/<br />
|url=<br />
|components=Core::Security: PSM, Core::Security: UI<br />
}}<br />
<br />
{{Module<br />
|name=Static analysis & rewriting for C++<br />
|description=Tools for checking C++ code looking for problems at compile time, plus tools for automated rewriting of C++ code.<br />
|owner=[mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|peers=[mailto:sfink@mozilla.com Steve Fink], [mailto:michael@thelayzells.com Michael Layzell], [mailto:jrmuizel@mozilla.com Jeff Muizelaar], [mailto:birunthan@mohanathas.com Birunthan Mohanathas]<br />
|group=dev-platform<br />
|source_dirs=build/clang-plugin, tools/rewriting among other out of tree tools<br />
|url=<br />
|components=Core::Rewriting & Analysis<br />
}}<br />
{{Module<br />
|name=storage<br />
|description=Storage APIs with a SQLite backend<br />
|owner=[mailto:mak77@bonardo.net Marco Bonardo]<br />
|peers=[mailto:bugmail@asutherland.org Andrew Sutherland], [mailto:bent.mozillla@gmail.com Ben Turner]<br />
|group=dev-platform<br />
|source_dirs=db/sqlite3/, storage/<br />
|url=http://developer.mozilla.org/en/docs/Storage<br />
|components=Toolkit::Storage, Core::SQL<br />
}}<br />
<br />
{{Module<br />
|name=String<br />
|description=<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:jlebar@mozilla.com Justin Lebar]<br />
|group=dev-tech-xpcom<br />
|source_dirs=string/, xpcom/string/<br />
|url=https://developer.mozilla.org/En/Mozilla_internal_string_guide<br />
|components=Core::String<br />
}}<br />
<br />
{{Module<br />
|name=Style System<br />
|description=CSS style sheet handling; style data computation<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:cam@mcc.id.au Cameron McCormack]<br />
|group=dev-tech-layout<br />
|source_dirs=layout/style/<br />
|url=https://wiki.mozilla.org/Gecko:Overview#Style_System<br />
|components=Core::CSS Parsing and Computation<br />
}}<br />
<br />
{{Module<br />
|name=SVG<br />
|description=Scalable Vector Graphics<br />
|owner=[mailto:jwatt@jwatt.org Jonathan Watt]<br />
|peers=[mailto:longsonr@gmail.com Robert Longson], [mailto:robert@ocallahan.org Robert O'Callahan], [mailto:dholbert@mozilla.com Daniel Holbert], [mailto:birtles@gmail.com Brian Birtles]<br />
|group=dev-tech-svg<br />
|source_dirs=dom/svg/, layout/svg/, dom/smil/<br />
|url=https://developer.mozilla.org/en-US/docs/Web/SVG<br />
|components=Core::SVG<br />
}}<br />
<br />
{{Module<br />
|name=Tamarin<br />
|description=VM for ActionScript and JavaScript<br />
|owner=Edwin Smith, [mailto:jodyer@adobe.com Jeff Dyer]<br />
|peers=[mailto:brendan@mozilla.org Brendan Eich], [mailto:stejohns@adobe.com Steven Johnson], [mailto:tierney@adobe.com Erik Tierney], [mailto:treilly@adobe.com Tom Reilly]<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/tamarin<br />
|url=http://www.mozilla.org/projects/tamarin/<br />
http://wiki.mozilla.org/tamarin/<br />
http://hg.mozilla.org/tamarin-central/<br />
http://hg.mozilla.org/tamarin-tracing/<br />
|components=Tamarin<br />
}}<br />
<br />
{{Module<br />
|name=Test Harness<br />
|description=In-tree test infrastructure and tools. Harnesses include, XPCShell, Mochitest (& Chrome), Reftest, JsREftest, Compiled Code Tests, Robocop, Mozmill, Marionette, Firefox UI Tests. Requests for new harnesses should go to Testing::General.<br />
|owner=[mailto:ted@mielczarek.org Ted Mielczarek]<br />
|peers=[mailto:dbaron@dbaron.org David Baron] (reftest), [mailto:jwalden@mit.edu Jeff Walden] (httpd.js, jsreftest), Rob Campbell (mochitest, mochitest chrome, marionette), [mailto:jmaher@mozilla.com Joel Maher] (reftest, mochitest, jsreftest), [mailto:ctalbert@mozilla.com Clint Talbert] (reftest, compiled code, mozmill), [mailto:geoffbrown@mozilla.com Geoff Brown] (robocop), [mailto:hskupin@mozilla.com Henrik Skupin] (Marionette, Firefox UI tests), [mailto:ato@mozilla.com Andreas Tolfsen] (marionette), [mailto:jgriffin Jonathan Griffin] (marionette), [mailto:dburns@mozilla.com David Burns] (marionette) [mailto:dminor@mozilla.com Dan Minor], [mailto:mjzffr@gmail.com Maja Frydrychowicz] (Marionette, Firefox UI tests), <br />
<br />
|group=dev-quality<br />
|source_dirs=/testing<br />
|url=http://wiki.mozilla.org/SoftwareTesting<br />
|components=Testing::General, Testing::Mochitest, Testing::Mochitest Chrome, Testing::Marionette, Testing::Mozmill, Testing::Reftest, Testing::XPCShell Harness, Testing::httpd.js<br />
}}<br />
<br />
{{Module<br />
|name=Testing Infrastructure<br />
|description=Testing tools and infrastructure for Mozilla projects, harnesses for automated tests, stand-alone test tools. Talos, Graph Server, Mozbase, Pulse, WOO, Bughunter, SUTAgent, Eideticker<br />
|owner=[mailto:jmaher@mozilla.com Joel Maher]<br />
|peers=[mailto:bclary@bclary.com Bob Clary], [mailto:bhearsum@mozilla.com Ben Hearsum], [mailto:ccooper@deadsquid.com Chris Cooper], [mailto:ctalbert@mozilla.com Clint Talbert], [mailto:robert@roberthelmer.com Robert Helmer], [mailto:jmaher@mozilla.com Joel Maher], Rob Campbell, [mailto:wlach@mozilla.com William Lachance], [mailto:jeads@mozilla.com Jonathan Eads], [mailto:jgriffin Jonathan Griffin], [mailto:bmoss@mozilla.com Bob Moss], [mailto:mcote@mozilla.com Mark Côté]<br />
|group=dev-quality<br />
|source_dirs=testing/, tools/httptester/, tools/page-loader/, tools/test-harness/, tools/tests/, tools/testserver/, tools/testy/<br />
|url=http://wiki.mozilla.org/SoftwareTesting<br />
|components=Testing::Infrastructure<br />
}}<br />
<br />
{{Module<br />
|name=JS Marionette<br />
|description=NodeJS test harness, marionette client, and other utilities for running marionette tests (submodule of Test Infrastructure)<br />
|owner=[mailto:jlal@mozilla.com James Lal] <lightsofapollo>, [mailto:gaye@mozilla.com Gareth Aye] <gaye><br />
|peers=[mailto:aus@mozilla.com Ghislain "Aus" Lacroix] <auswerk><br />
|source_dirs=gaia/tests/jsmarionette<br />
|components=Testing::JSMarionette<br />
|group=dev-gaia<br />
}}<br />
<br />
{{Module<br />
|name=XPCShell Test Harness<br />
|description=The XPCShell Harness<br />
|owner=[mailto:ted@mielczarek.org Ted Mielczarek]<br />
|peers=[mailto:jmaher@mozilla.com Joel Maher]<br />
|source_dirs=testing/xpcshell<br />
|components=Testing::XPCShell Harness<br />
}}<br />
<br />
{{Module<br />
|name=Update Service<br />
|description=server code for Mozilla Update services (aus, addons, pfs)<br />
|owner=Mike Morgan<br />
|peers=[mailto:jscott@mozilla.com Justin Scott], [mailto:shaver@mozilla.org Mike Shaver], [mailto:wclouser@mozilla.com Will Clouser]<br />
|group=dev-amo<br />
|source_dirs=webtools/addons/, webtools/aus/, webtools/update/<br />
|url=http://wiki.mozilla.org/wiki/AMO<br />
|components=AUS::Administration, AUS::Systems<br />
}}<br />
<br />
{{Module<br />
|name=View System<br />
|description=The View Manager is responsible for handling "heavyweight" rendering (some clipping, compositing) and event handling tasks.<br />
|owner=[mailto:mstange@themasta.com Markus Stange]<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:dbaron@dbaron.org David Baron]<br />
|group=dev-tech-layout<br />
|source_dirs=view/<br />
|url=<br />
|components=Core::Layout: View Rendering<br />
}}<br />
<br />
{{Module<br />
|name=Web Audio<br />
|description=Support for the W3C Web Audio API specification.<br />
|owner=[mailto:padenot@mozilla.com Paul Adenot]<br />
|ownersemeritus=[mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|peers=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:karlt+@karlt.net Karl Tomlinson]<br />
|group=dev-platform<br />
|source_dirs=dom/media/webaudio<br />
|url=https://wiki.mozilla.org/Web_Audio_API<br />
|components=Core::Web Audio<br />
}}<br />
<br />
{{Module<br />
|name=WebRTC<br />
|description=WebRTC is responsible for realtime audio and video communication, as well as related issues like low-level camera and microphone access<br />
|owner=[mailto:rjesup@mozilla.com Randell Jesup]<br />
|peers=[mailto:ekr@mozilla.com Eric Rescorla], [mailto:bcampen@mozilla.com Byron Campen] [mailto:abr@mozilla.com Adam Roach]<br />
|peersemeritus=[mailto:ehugg@cisco.com Ethan Hugg]<br />
|group=dev-media<br />
|source_dirs=N/A (see submodules "WebRTC Media" and "WebRTC Signaling")<br />
|url=https://wiki.mozilla.org/Media/webrtc<br />
|components=Core::WebRTC<br />
}}<br />
<br />
{{Module<br />
|name=Widget<br />
|description=<br />
|owner=[mailto:vladimir@pobox.com Vladimir Vukicevic]<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|peersemeritus=[mailto:pavlov@pavlov.net Stuart Parmenter], <br />
|group=dev-platform<br />
|source_dirs=widget/, widget/xpwidgets/<br />
|url=<br />
|components=Core::Drag and Drop, Core::Widget, Core::Printing: Setup<br />
}}<br />
<br />
{{Module<br />
|name=Widget - Android<br />
|description=The Android Port<br />
|owner=[mailto:blassey.bugs@lassey.us Brad Lassey]<br />
|peers=[mailto:jwillcox@mozilla.com James Willcox]<br />
|group=dev-platforms-mobile<br />
|source_dirs=widget/android/, embedding/android<br />
|url=<br />
|components=Core::Widget: Android<br />
}}<br />
<br />
{{Module<br />
|name=Widget - GTK<br />
|description=supported X widgetry and gfx<br />
|owner=[mailto:karlt+@karlt.net Karl Tomlinson]<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|group=dev-platform<br />
|source_dirs=widget/gtk/, widget/gtk2/, widget/gtksuperwin/, widget/gtkxtbin/<br />
|url=http://www.mozilla.org/unix/, http://www.gtk.org, http://www.mozilla.org/ports/gtk/<br />
|components=Core::Widget: Gtk<br />
}}<br />
<br />
{{Module<br />
|name=Widget - OS X<br />
|description= Gecko's OS X compatibility layer.<br />
|owner=[mailto:mstange@themasta.com Markus Stange]<br />
|peers=[mailto:joshmoz@gmail.com Josh Aas], [mailto:bgirard@mozilla.com Benoit Girard], [mailto:spohl@mozilla.com Stephen Pohl], [mailto:smichaud@pobox.com Steven Michaud]<br />
|group=dev-platform<br />
|source_dirs=widget/cocoa/<br />
|url=<br />
|components=Core::Widget: Cocoa<br />
}}<br />
<br />
{{Module<br />
|name=Widget - Windows<br />
|description=Windows widgets and desktop integration<br />
|owner=[mailto:jmathies@mozilla.com Jim Mathies]<br />
|peers=[mailto:blassey@mozilla.com Brad Lassey], [mailto:netzen@gmail.com Brian Bondy], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:doug.turner@gmail.com Doug Turner], [mailto:neil@parkwaycc.co.uk Neil Rashbrook], [mailto:robarnold@cmu.edu Rob Arnold], [mailto:vladimir@pobox.com Vladimir Vukicevic]<br />
|peersemeritus=[mailto:timeless@mozdev.org Josh 'timeless' Soref]<br />
|group=dev-platform<br />
|source_dirs=widget/windows/<br />
|url=<br />
|components=Core::Widget: Win32<br />
}}<br />
<br />
{{Module<br />
|name=XBL<br />
|description=eXtensible Binding Language<br />
|owner=[mailto:bzbarsky@mit.edu Boris Zbarsky]<br />
|peers=[mailto:mrbkap@gmail.com Blake Kaplan], [mailto:bobbyholley@gmail.com Bobby Holley], [mailto:jonas@sicking.cc Jonas Sicking]<br />
|ownersemeritus=[mailto:jonas@sicking.cc Jonas Sicking]<br />
|group=dev-tech-xbl<br />
|source_dirs=dom/xbl/<br />
|url=http://www.mozilla.org/projects/xbl/<br />
|components=Core::XBL<br />
}}<br />
<br />
{{Module<br />
|name=XML<br />
|description=XML in Mozilla, including XML, XHTML, Namespaces in XML, Associating Style Sheets with XML Documents, XML Linking and XML Extras. XML-related things that are not covered by more specific projects.<br />
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:jonas@sicking.cc Jonas Sicking], [mailto:jst@mozilla.org Johnny Stenback]<br />
|group=dev-tech-xml<br />
|source_dirs=dom/xml/, extensions/xmlextras/, parser/expat/<br />
|url=http://www.mozilla.org/newlayout/xml/<br />
|components=Core::XML<br />
}}<br />
<br />
{{Module<br />
|name=XPApps<br />
|description=Cross-Platform Applications, mostly Navigator front end and application shell.<br />
|owner=[mailto:neil@parkwaycc.co.uk Neil Rashbrook]<br />
|peers=[mailto:dean_tessman@hotmail.com Dean Tessman], [mailto:timeless@mozdev.org Josh 'timeless' Soref]<br />
|group=dev-apps-seamonkey<br />
|source_dirs=xpfe/<br />
|url=http://www.mozilla.org/xpapps/<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=XPCOM<br />
|description=The cross-platform object model and core data structures.<br />
|owner=[https://mozillians.org/en-US/u/froydnj/ Nathan Froyd]<br />
|peers=[https://mozillians.org/en-US/u/dougt/ Doug Turner], [https://mozillians.org/en-US/u/bsmedberg/ Benjamin Smedberg]<br />
|group=dev-platform<br />
|source_dirs=startupcache/, xpcom/%, xpcom/base/, xpcom/build/, xpcom/components/, xpcom/ds/, xpcom/glue/, xpcom/proxy/, xpcom/sample/, xpcom/stub/, xpcom/tests/, xpcom/threads/, xpcom/tools/, xpcom/windbgdlg/<br />
|url=http://developer.mozilla.org/en/XPCOM<br />
|components=Core::XPCOM<br />
}}<br />
<br />
{{Module<br />
|name=XPConnect<br />
|description=Deep Magic<br />
|owner=[mailto:bobbyholley@gmail.com Bobby Holley]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:jst@mozilla.org Johnny Stenback], [mailto:peterv@propagandism.org Peter Van der Beken], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:gkrizsanits@mozilla.com Gabor Krizsanits]<br />
|peersemeritus=[mailto:gal@uci.edu Andreas Gal]<br />
|group=<br />
|source_dirs=js/xpconnect/<br />
|url=<br />
|components=Core::XPConnect<br />
}}<br />
<br />
{{Module<br />
|name=XPIDL<br />
|description=Cross-platform IDL compiler; produces .h C++ header files and .xpt runtime type description files from .idl interface description files.<br />
|owner=[mailto:me@kylehuey.com Kyle Huey]<br />
|peersemeritus=[mailto:shaver@mozilla.org Mike Shaver], [mailto:timeless@mozdev.org Josh 'timeless' Soref]<br />
|group=dev-tech-xpcom<br />
|source_dirs=xpcom/typelib/<br />
|url=http://www.mozilla.org/scriptable/xpidl<br />
http://www.mozilla.org/scriptable<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=XPInstall<br />
|description=<br />
|owner=[mailto:dveditz@mozilla.com Dan Veditz]<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg]<br />
|group=dev-tech-xpinstall<br />
|source_dirs=xpinstall/<br />
|url=<br />
|components=Core::Installer: XPInstall Engine<br />
}}<br />
<br />
{{Module<br />
|name=xptcall<br />
|description=XPTCall - platform-specific assembly for calling and implementing arbitrary XPCOM interfaces.<br />
|owner=<br />
|ownersemeritus=[mailto:timeless@mozdev.org Josh 'timeless' Soref]<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:shaver@mozilla.org Mike Shaver]<br />
|group=dev-xpcom<br />
|source_dirs=xpcom/reflect/xptcall/<br />
|url=http://www.mozilla.org/scriptable/xptcall-faq.html<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=XPToolkit<br />
|description=Cross-platform user interface toolkit<br />
|owner=<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:Jan.Varga@gmail.com Jan Varga]<br />
|group=dev-tech-xul<br />
|source_dirs=dom/xul/, layout/xul/<br />
|url=http://www.mozilla.org/xpfe/<br />
|components=Core::XP Toolkit/Widgets: Menus, Core::XP Toolkit/Widgets: XUL<br />
}}<br />
<br />
{{Module<br />
|name=XSLT Processor<br />
|description=XSLT transformations processor<br />
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]<br />
|peers=[mailto:axel@pike.org Axel Hecht], [mailto:jonas@sicking.cc Jonas Sicking]<br />
|group=dev-tech-xslt<br />
|source_dirs=dom/xslt/<br />
|url=http://www.mozilla.org/projects/xslt/, http://www.w3.org/TR/xslt.html<br />
|components=Core::XSLT<br />
}}<br />
<br />
{{Module<br />
|name=XTF<br />
|description=eXtensible Tag Framework<br />
|owner=<br />
|peers=[mailto:alex@croczilla.com alex@croczilla.com], [mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:jonas@sicking.cc Jonas Sicking]<br />
|group=dev-tech-xbl<br />
|source_dirs=content/xtf/, layout/xtf/<br />
|url=http://www.croczilla.com/bits_and_pieces/xtf/<br />
|components=Core::XTF<br />
}}<br />
<br />
{{Module<br />
|name=Sandboxing<br />
|description=Cross platform sandboxing<br />
|owner=[mailto:gcp@mozilla.com Gian-Carlo Pascutto]<br />
|peers=[mailto:bowen@mozilla.com Bob Owen], [mailto:aklotz@mozilla.com Aaron Klotz], [https://mozillians.org/en-US/u/TimAbraldes Tim Abraldes], [mailto:gDestuynder@mozilla.com Guillaume Destuynder], [mailto:bsmedberg@mozilla.com Benjamin Smedberg], [mailto:jld@mozilla.com Jed Davis]<br />
|group=dev-platform <br />
|source_dirs=security/sandbox<br />
|url=https://wiki.mozilla.org/Security/Sandbox <br />
|components=Core::Security: Process Sandboxing<br />
}}<br />
<br />
{{Module<br />
|name=Sandboxing - Windows <br />
|description=Sandboxing for the Windows platform <br />
|owner=[mailto:bowen@mozilla.com Bob Owen]<br />
|peers=[mailto:netzen@gmail.com Brian Bondy], [mailto:aklotz@mozilla.com Aaron Klotz], [https://mozillians.org/en-US/u/TimAbraldes Tim Abraldes], [mailto:jimm@mozilla.com Jim Mathies]<br />
|group=dev-platform<br />
|source_dirs=security/sandbox/win <br />
|url=https://wiki.mozilla.org/Security/Sandbox <br />
|components=Core::Security: Process Sandboxing<br />
}}<br />
<br />
{{Module<br />
|name=Sandboxing - OSX <br />
|description=Sandboxing for the OSX platform <br />
|owner=[mailto:haftandilian@mozilla.com Haik Aftandilian]<br />
|peers=<br />
|group=dev-platform <br />
|source_dirs=security/sandbox/mac <br />
|url=https://wiki.mozilla.org/Security/Sandbox <br />
|components=Core::Security: Process Sandboxing<br />
}}<br />
<br />
{{Module<br />
|name=Sandboxing - Linux & B2G<br />
|description=Sandboxing for the Linux & B2G platforms<br />
|owner=[mailto:jhector@mozilla.com Julian Hector]<br />
|peers=[mailto:jld@mozilla.com Jed Davis] [mailto:gcp@mozilla.com Gian-Carlo Pascutto]<br />
|group=dev-platform<br />
|source_dirs=security/sandbox/linux<br />
|url=https://wiki.mozilla.org/Security/Sandbox <br />
|components=Core::Security: Process Sandboxing<br />
}}<br />
<br />
===Submodules===<br />
{{Module<br />
|name=Build Config - Fennec<br />
|description=Submodule of the build config covering Fennec's build system in mobile/android.<br />
|owner=[mailto:gps@mozilla.com Gregory Szorc]<br />
|peers=Same as Build Config plus [mailto:nalexander@mozilla.com Nicholas Alexander].<br />
|group=dev-builds<br />
|components=Core::Build Config<br />
}}<br />
<br />
{{Module<br />
|name=WebRTC Media<br />
|description=Submodule of WebRTC responsible for access to media input devices (microphones, cameras, screen capture), as well as realtime audiovisual codecs and packetization.<br />
|owner=[mailto:rjesup@mozilla.com Randell Jesup]<br />
|peers=[mailto:pkerr@mozilla.com Paul Kerr], [mailto:jib@mozilla.com Jan-Ivar Bruaroey]<br />
|peersemeritus=[mailto:ehugg@cisco.com Ethan Hugg]<br />
|group=dev-media<br />
|source_dirs=/media/webrtc, /dom/media/webrtc<br />
|url=https://wiki.mozilla.org/Media/webrtc<br />
|components=Core::WebRTC (Audio/Video)<br />
}}<br />
<br />
{{Module<br />
|name=WebRTC Signaling<br />
|description=Submodule of WebRTC responsible for implementation of PeerConnection API, WebRTC identity, and SDP/JSEP handling<br />
|owner=[mailto:bcampen@mozilla.com Byron Campen]<br />
|peers=[mailto:ekr@mozilla.com Eric Rescorla], [mailto:abr@mozilla.com Adam Roach], [mailto:rjesup@mozilla.com Randell Jesup], [mailto:nohlmeier@mozilla.com Nils Ohlmeier]<br />
|peersemeritus=[mailto:ehugg@cisco.com Ethan Hugg]<br />
|group=dev-media<br />
|source_dirs=/media/webrtc/signaling/<br />
|url=https://wiki.mozilla.org/Media/webrtc<br />
|components=Core::WebRTC (Signaling)<br />
}}<br />
<br />
<br />
<noinclude><br />
<br />
===Unassigned Bugzilla Components===<br />
<br />
The following Bugzilla components in the Core project have not been assigned to a module (this list is not exhaustive):<br />
<br />
<pre><br />
Core::File Handling<br />
Core::Find Backend<br />
Core::Gecko Profiler<br />
Core::General<br />
Core::HTML: Form Submission<br />
Core::History: Global<br />
Core::Image Blocking<br />
Core::JavaScript Debugging APIs<br />
Core::Localization<br />
Core::Nanojit<br />
Core::Networking: Domain Lists<br />
Core::Print Preview<br />
Core::Printing: Output<br />
Core::Printing: Setup<br />
Core::Profile: BackEnd<br />
Core::Profile: Migration<br />
Core::Profile: Roaming<br />
Core::QuickLaunch (AKA turbo mode)<br />
Core::Rewriting and Analysis<br />
Core::Selection<br />
Core::Serializers<br />
Core::Spelling checker<br />
Core::Tracking<br />
Core::Web Services<br />
Core::WebDAV<br />
Core::Widget: OS/2<br />
Core::Widget: Photon<br />
Core::X-remote<br />
Core::XForms<br />
Core::XUL<br />
</pre><br />
</noinclude></div>Sickinghttps://wiki.mozilla.org/index.php?title=FlyWeb&diff=1111985FlyWeb2016-01-09T00:07:22Z<p>Sicking: /* Security */</p>
<hr />
<div>[[File:FlyWeb.png|150px|frameless|left|FlyWeb]]<br />
<br />
The web already powers the world's email, media, shopping, and more. Interacting with these things is a breeze because they all use the web. What if the electronics around us were the same?<br />
<br />
Meet <strong>FlyWeb</strong>. FlyWeb is a very simple idea at its core. Instead of phones interacting only with the cloud, they can discover and interact with electronics around them that are running empty web clients, such as TV's, projectors, game consoles, etc. The electronics come to life when connected to phones. The key here is that either the phones serve web apps to these electronics, or the electronics serve web apps to the phones.<br />
<br />
<br />
<br />
==Why?==<br />
<br />
The connected devices market is ready to explode. As the market grows, much like the early internet, these devices are being segregated into walled gardens of one-off proprietary initiatives, such as AirPlay, the Google Cast API, etc. These solutions not only lock their users into specific vendor ecosystems -- to the benefit of those vendors and detriment of their users -- but also require significant investment to solve each use case.<br />
<br />
Many of these connected devices initiatives have common underlying platform needs:<br />
* to discover and connect devices together,<br />
* enable bi-directional communication,<br />
* allow arbitrary, but secure code execution on each side,<br />
* and require knowledge of as few details of a device's peers as possible.<br />
<br />
The web is the best platform for serving all of these needs. Indeed, it has been designed for them for over a decade.<br />
<br />
=Demo Videos=<br />
* [https://blog.mozilla.org/blog/2015/11/09/mozfest-2015-demo-garage-showing-whats-possible-with-the-open-web/?fb_action_ids=10208274568127989&fb_action_types=og.likes Demo at Mozfest 11/5/15]<br />
* [https://youtu.be/j3E4dKNaQRM Early Trailer Video]<br />
** [https://youtu.be/kq1ygsQzuO0 Developer commentary over this video.]<br />
* [https://youtu.be/g-zHE33xKng Early-stage browser casting demo.]<br />
<br />
=Proposal=<br />
* [https://docs.google.com/document/d/12i_UjTvmhViXho-wIy4UWrghuFxLls_HYEk1F9-f_GM/edit?usp=sharing Draft Proposal Link]<br />
* [https://github.com/flyweb/spec Draft Specification Link]<br />
<br />
=Security=<br />
<br />
* [https://docs.google.com/document/d/1eqLb6cGjDL9XooSYEEo7mE-zKQ-o-AuDTcEyNhfBMBM/edit?usp=sharing A discussion about FlyWeb security by Ekr]<br />
* [[FlyWeb/Security scenarios|A list of example scenarios that are useful when discussing security]]<br />
<br />
=Team=<br />
* [mailto:kvijayan@mozilla.com Kannan Vijayan (:djvj)] - engineering<br />
* [mailto:jdarcangelo@mozilla.com Justin D'Arcangelo (:justindarc)] - engineering<br />
* [mailto:jonas@sicking.cc Jonas Sicking (:sicking)] - engineering / specifications<br />
* [mailto:nyee@mozilla.com Nicole Yee (:nicoleyee)] - project management<br />
<br />
=Bug Tracking=<br />
<bugzilla><br />
{<br />
"blocks":"1228662",<br />
"status":["NEW","REOPENED","UNCONFIRMED","ASSIGNED","RESOLVED","VERIFIED","CLOSED"],<br />
"include_fields": "id, summary, status, target_milestone, resolution, assigned_to, depends_on, blocks, whiteboard, cf_feature_b2g"<br />
}<br />
</bugzilla><br />
<br />
=Communication=<br />
<br />
==Video Conferencing - Vidyo Room==<br />
<big>[https://v.mozilla.com/flex.html?roomdirect.html&key=8uhXHJqVblWNGubS4x0he1qB810 Quick link to join with the Vidyo app (prompts install if needed)]</big><br />
<br />
We have our own Vidyo room for meetings. Contributors and non-employees are welcome to attend all meetings. Here are the full details for joining:<br />
<br />
{| class="wikitable collapsible collapsed" style="width: 100%"<br />
! "FlyWeb" Vidyo Room<br />
|-<br />
|<br />
Hello,<br><br />
<br><br />
You have been invited to attend a Mozilla Vidyo conference. Please click on the link below to attend:<br><br />
<br><br />
https://v.mozilla.com/flex.html?roomdirect.html&key=8uhXHJqVblWNGubS4x0he1qB810<br><br />
<br><br />
If you do not have a user account, please enter your name in the "Guest Name" field and then click "Join".<br><br />
<br><br />
To join from a telephone, dial one of the following numbers depending on your nearest location:<br><br />
<br><br />
US Toll Free +1 800 707 2533, pin 369, conf 98860<br><br />
US/CA/Mountain View +1 650 903 0800, extension 92, 98860<br><br />
US/CA/San Francisco: +1 415 762 5700, extension 92, 98860<br><br />
US/OR/Portland: +1 971 544 8000, extension 92, 98860<br><br />
CA/BC/Vancouver: +1 778 785 1540, extension 92, 98860<br><br />
CA/ON/Toronto: +1 416 848 3114, extension 92, 98860<br><br />
UK/London: +44 (0)207 855 3000, extension 92, 98860<br><br />
FR/Paris: +33 1 184 883 737, extension 3, extension 92, 98860<br><br />
DE/Berlin: +49 30 983 333 000, extension 92, 98860<br><br />
NZ/Auckland: +64 9 555 1100, extension 92, 98860<br />
|}<br />
<br />
=Project Management=<br />
<br />
<big>[https://trello.com/b/IlFy9m7y/flyweb Trello dashboard]</big><br />
<br />
We use Trello for project management. All ongoing tasks are listed there.<br />
<br />
=Meetings=<br />
<br />
==Calendar==<br />
<big>[https://www.google.com/calendar/embed?src=mozilla.com_g1v696sr9vu27f2tuvunmevna0%40group.calendar.google.com Calendar]</big><br />
<br />
The FlyWeb team has a public calendar with every team meeting.<br />
<br />
===Instructions for Adding to your Calendar===<br />
<br />
# Open the [https://www.google.com/calendar/embed?src=mozilla.com_g1v696sr9vu27f2tuvunmevna0%40group.calendar.google.com calendar].<br />
# Click on the "+ Google Calendar" button in the very bottom right of your screen.<br />
<br />
You can also use the [https://www.google.com/calendar/feeds/mozilla.com_g1v696sr9vu27f2tuvunmevna0%40group.calendar.google.com/public/basic XML] and [https://www.google.com/calendar/ical/mozilla.com_g1v696sr9vu27f2tuvunmevna0%40group.calendar.google.com/public/basic.ics ICS] methods, but these are not recommended.<br />
<br />
Note: The "Find a Time" feature will not work for other people if you import this calendar. As a consequence, others will not see that you are unavailable when attending a FlyWeb meeting. We suggest either accepting this, or adding the meetings to your main calendar as well.<br />
<br />
==Standups==<br />
<br />
We have two weekly standups, with both times available on the [[#Calendar|Public Calendar]]. These standups happen in the [[#Video Conferencing - Vidyo Room|FlyWeb Vidyo room]].<br />
<br />
==All meeting minutes==<br />
===2015-Q3===<br />
* [[FlyWeb/Meetings/2015-08-20 - FlyWeb+Presentation API|2015-08-20 - FlyWeb+Presentation API]]<br />
* [[FlyWeb/Meetings/2015-08-13 - Standup, late|2015-08-13 - Standup, late]]<br />
* [[FlyWeb/Meetings/2015-08-12 - Use case culling|2015-08-12 - Use case culling]]<br />
* [[FlyWeb/Meetings/2015-08-12 - Technical materials compilation|2015-08-12 - Technical materials compilation]]<br />
<br />
=See Also=<br />
* [https://docs.google.com/document/d/1MoyseigM7iYSoQZ0PsnIyU6yE1GzwE7-ETCZOS1hmFw/edit User and Market Research]: Due to the confidential nature of the interviews, and our respect for our interviewees' privacy, we are restricting access to this information.<br />
<br />
==Strategy Essays==<br />
* [https://docs.google.com/document/d/1o3pY73CBiFSx7fNDwDfzJ1TggUIIa-RWBL4-eqpy_nE/edit 2015-05 Operational Overview]<br />
* [https://docs.google.com/document/d/1948ryrtM2_zCQKy7ADcnwoxcviTC4sOvCeCtJGcwDVU/edit 2015-07 In-depth Strategy Document]<br />
<br />
==Related Initiatives==<br />
* [https://github.com/google/physical-web Google's "Physical Web" Initiative]<br />
* [http://coap.technology/impls.html Constrained Application Model - Internet of Things]<br />
<br />
==Related APIs==<br />
* [http://www.w3.org/TR/presentation-api/ W3C Presentation API]<br />
* [https://blog.mozilla.org/blog/2015/05/14/first-panasonic-smart-tvs-powered-by-firefox-os-debut-worldwide/ Mozilla Smart TV's]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1143996 KDDI Web-Cast]<br />
* [https://en.wikipedia.org/wiki/Discovery_and_Launch Discovery and Launch (DIAL)]</div>Sickinghttps://wiki.mozilla.org/index.php?title=FlyWeb&diff=1111984FlyWeb2016-01-09T00:06:49Z<p>Sicking: Link to Ekr's doc</p>
<hr />
<div>[[File:FlyWeb.png|150px|frameless|left|FlyWeb]]<br />
<br />
The web already powers the world's email, media, shopping, and more. Interacting with these things is a breeze because they all use the web. What if the electronics around us were the same?<br />
<br />
Meet <strong>FlyWeb</strong>. FlyWeb is a very simple idea at its core. Instead of phones interacting only with the cloud, they can discover and interact with electronics around them that are running empty web clients, such as TV's, projectors, game consoles, etc. The electronics come to life when connected to phones. The key here is that either the phones serve web apps to these electronics, or the electronics serve web apps to the phones.<br />
<br />
<br />
<br />
==Why?==<br />
<br />
The connected devices market is ready to explode. As the market grows, much like the early internet, these devices are being segregated into walled gardens of one-off proprietary initiatives, such as AirPlay, the Google Cast API, etc. These solutions not only lock their users into specific vendor ecosystems -- to the benefit of those vendors and detriment of their users -- but also require significant investment to solve each use case.<br />
<br />
Many of these connected devices initiatives have common underlying platform needs:<br />
* to discover and connect devices together,<br />
* enable bi-directional communication,<br />
* allow arbitrary, but secure code execution on each side,<br />
* and require knowledge of as few details of a device's peers as possible.<br />
<br />
The web is the best platform for serving all of these needs. Indeed, it has been designed for them for over a decade.<br />
<br />
=Demo Videos=<br />
* [https://blog.mozilla.org/blog/2015/11/09/mozfest-2015-demo-garage-showing-whats-possible-with-the-open-web/?fb_action_ids=10208274568127989&fb_action_types=og.likes Demo at Mozfest 11/5/15]<br />
* [https://youtu.be/j3E4dKNaQRM Early Trailer Video]<br />
** [https://youtu.be/kq1ygsQzuO0 Developer commentary over this video.]<br />
* [https://youtu.be/g-zHE33xKng Early-stage browser casting demo.]<br />
<br />
=Proposal=<br />
* [https://docs.google.com/document/d/12i_UjTvmhViXho-wIy4UWrghuFxLls_HYEk1F9-f_GM/edit?usp=sharing Draft Proposal Link]<br />
* [https://github.com/flyweb/spec Draft Specification Link]<br />
<br />
=Security=<br />
<br />
* [https://docs.google.com/document/d/1eqLb6cGjDL9XooSYEEo7mE-zKQ-o-AuDTcEyNhfBMBM/edit?usp=sharing A discussion about FlyWeb security by Ekr]<br />
* [[FlyWeb/Security scenarios|A list of example use cases that are useful when discussing security]]<br />
<br />
=Team=<br />
* [mailto:kvijayan@mozilla.com Kannan Vijayan (:djvj)] - engineering<br />
* [mailto:jdarcangelo@mozilla.com Justin D'Arcangelo (:justindarc)] - engineering<br />
* [mailto:jonas@sicking.cc Jonas Sicking (:sicking)] - engineering / specifications<br />
* [mailto:nyee@mozilla.com Nicole Yee (:nicoleyee)] - project management<br />
<br />
=Bug Tracking=<br />
<bugzilla><br />
{<br />
"blocks":"1228662",<br />
"status":["NEW","REOPENED","UNCONFIRMED","ASSIGNED","RESOLVED","VERIFIED","CLOSED"],<br />
"include_fields": "id, summary, status, target_milestone, resolution, assigned_to, depends_on, blocks, whiteboard, cf_feature_b2g"<br />
}<br />
</bugzilla><br />
<br />
=Communication=<br />
<br />
==Video Conferencing - Vidyo Room==<br />
<big>[https://v.mozilla.com/flex.html?roomdirect.html&key=8uhXHJqVblWNGubS4x0he1qB810 Quick link to join with the Vidyo app (prompts install if needed)]</big><br />
<br />
We have our own Vidyo room for meetings. Contributors and non-employees are welcome to attend all meetings. Here are the full details for joining:<br />
<br />
{| class="wikitable collapsible collapsed" style="width: 100%"<br />
! "FlyWeb" Vidyo Room<br />
|-<br />
|<br />
Hello,<br><br />
<br><br />
You have been invited to attend a Mozilla Vidyo conference. Please click on the link below to attend:<br><br />
<br><br />
https://v.mozilla.com/flex.html?roomdirect.html&key=8uhXHJqVblWNGubS4x0he1qB810<br><br />
<br><br />
If you do not have a user account, please enter your name in the "Guest Name" field and then click "Join".<br><br />
<br><br />
To join from a telephone, dial one of the following numbers depending on your nearest location:<br><br />
<br><br />
US Toll Free +1 800 707 2533, pin 369, conf 98860<br><br />
US/CA/Mountain View +1 650 903 0800, extension 92, 98860<br><br />
US/CA/San Francisco: +1 415 762 5700, extension 92, 98860<br><br />
US/OR/Portland: +1 971 544 8000, extension 92, 98860<br><br />
CA/BC/Vancouver: +1 778 785 1540, extension 92, 98860<br><br />
CA/ON/Toronto: +1 416 848 3114, extension 92, 98860<br><br />
UK/London: +44 (0)207 855 3000, extension 92, 98860<br><br />
FR/Paris: +33 1 184 883 737, extension 3, extension 92, 98860<br><br />
DE/Berlin: +49 30 983 333 000, extension 92, 98860<br><br />
NZ/Auckland: +64 9 555 1100, extension 92, 98860<br />
|}<br />
<br />
=Project Management=<br />
<br />
<big>[https://trello.com/b/IlFy9m7y/flyweb Trello dashboard]</big><br />
<br />
We use Trello for project management. All ongoing tasks are listed there.<br />
<br />
=Meetings=<br />
<br />
==Calendar==<br />
<big>[https://www.google.com/calendar/embed?src=mozilla.com_g1v696sr9vu27f2tuvunmevna0%40group.calendar.google.com Calendar]</big><br />
<br />
The FlyWeb team has a public calendar with every team meeting.<br />
<br />
===Instructions for Adding to your Calendar===<br />
<br />
# Open the [https://www.google.com/calendar/embed?src=mozilla.com_g1v696sr9vu27f2tuvunmevna0%40group.calendar.google.com calendar].<br />
# Click on the "+ Google Calendar" button in the very bottom right of your screen.<br />
<br />
You can also use the [https://www.google.com/calendar/feeds/mozilla.com_g1v696sr9vu27f2tuvunmevna0%40group.calendar.google.com/public/basic XML] and [https://www.google.com/calendar/ical/mozilla.com_g1v696sr9vu27f2tuvunmevna0%40group.calendar.google.com/public/basic.ics ICS] methods, but these are not recommended.<br />
<br />
Note: The "Find a Time" feature will not work for other people if you import this calendar. As a consequence, others will not see that you are unavailable when attending a FlyWeb meeting. We suggest either accepting this, or adding the meetings to your main calendar as well.<br />
<br />
==Standups==<br />
<br />
We have two weekly standups, with both times available on the [[#Calendar|Public Calendar]]. These standups happen in the [[#Video Conferencing - Vidyo Room|FlyWeb Vidyo room]].<br />
<br />
==All meeting minutes==<br />
===2015-Q3===<br />
* [[FlyWeb/Meetings/2015-08-20 - FlyWeb+Presentation API|2015-08-20 - FlyWeb+Presentation API]]<br />
* [[FlyWeb/Meetings/2015-08-13 - Standup, late|2015-08-13 - Standup, late]]<br />
* [[FlyWeb/Meetings/2015-08-12 - Use case culling|2015-08-12 - Use case culling]]<br />
* [[FlyWeb/Meetings/2015-08-12 - Technical materials compilation|2015-08-12 - Technical materials compilation]]<br />
<br />
=See Also=<br />
* [https://docs.google.com/document/d/1MoyseigM7iYSoQZ0PsnIyU6yE1GzwE7-ETCZOS1hmFw/edit User and Market Research]: Due to the confidential nature of the interviews, and our respect for our interviewees' privacy, we are restricting access to this information.<br />
<br />
==Strategy Essays==<br />
* [https://docs.google.com/document/d/1o3pY73CBiFSx7fNDwDfzJ1TggUIIa-RWBL4-eqpy_nE/edit 2015-05 Operational Overview]<br />
* [https://docs.google.com/document/d/1948ryrtM2_zCQKy7ADcnwoxcviTC4sOvCeCtJGcwDVU/edit 2015-07 In-depth Strategy Document]<br />
<br />
==Related Initiatives==<br />
* [https://github.com/google/physical-web Google's "Physical Web" Initiative]<br />
* [http://coap.technology/impls.html Constrained Application Model - Internet of Things]<br />
<br />
==Related APIs==<br />
* [http://www.w3.org/TR/presentation-api/ W3C Presentation API]<br />
* [https://blog.mozilla.org/blog/2015/05/14/first-panasonic-smart-tvs-powered-by-firefox-os-debut-worldwide/ Mozilla Smart TV's]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1143996 KDDI Web-Cast]<br />
* [https://en.wikipedia.org/wiki/Discovery_and_Launch Discovery and Launch (DIAL)]</div>Sickinghttps://wiki.mozilla.org/index.php?title=FlyWeb&diff=1111981FlyWeb2016-01-08T23:48:26Z<p>Sicking: Add security section</p>
<hr />
<div>[[File:FlyWeb.png|150px|frameless|left|FlyWeb]]<br />
<br />
The web already powers the world's email, media, shopping, and more. Interacting with these things is a breeze because they all use the web. What if the electronics around us were the same?<br />
<br />
Meet <strong>FlyWeb</strong>. FlyWeb is a very simple idea at its core. Instead of phones interacting only with the cloud, they can discover and interact with electronics around them that are running empty web clients, such as TV's, projectors, game consoles, etc. The electronics come to life when connected to phones. The key here is that either the phones serve web apps to these electronics, or the electronics serve web apps to the phones.<br />
<br />
<br />
<br />
==Why?==<br />
<br />
The connected devices market is ready to explode. As the market grows, much like the early internet, these devices are being segregated into walled gardens of one-off proprietary initiatives, such as AirPlay, the Google Cast API, etc. These solutions not only lock their users into specific vendor ecosystems -- to the benefit of those vendors and detriment of their users -- but also require significant investment to solve each use case.<br />
<br />
Many of these connected devices initiatives have common underlying platform needs:<br />
* to discover and connect devices together,<br />
* enable bi-directional communication,<br />
* allow arbitrary, but secure code execution on each side,<br />
* and require knowledge of as few details of a device's peers as possible.<br />
<br />
The web is the best platform for serving all of these needs. Indeed, it has been designed for them for over a decade.<br />
<br />
=Demo Videos=<br />
* [https://blog.mozilla.org/blog/2015/11/09/mozfest-2015-demo-garage-showing-whats-possible-with-the-open-web/?fb_action_ids=10208274568127989&fb_action_types=og.likes Demo at Mozfest 11/5/15]<br />
* [https://youtu.be/j3E4dKNaQRM Early Trailer Video]<br />
** [https://youtu.be/kq1ygsQzuO0 Developer commentary over this video.]<br />
* [https://youtu.be/g-zHE33xKng Early-stage browser casting demo.]<br />
<br />
=Proposal=<br />
* [https://docs.google.com/document/d/12i_UjTvmhViXho-wIy4UWrghuFxLls_HYEk1F9-f_GM/edit?usp=sharing Draft Proposal Link]<br />
* [https://github.com/flyweb/spec Draft Specification Link]<br />
<br />
=Security=<br />
<br />
* [[FlyWeb/Security scenarios|A list of example use cases that are useful when discussing security]]<br />
<br />
=Team=<br />
* [mailto:kvijayan@mozilla.com Kannan Vijayan (:djvj)] - engineering<br />
* [mailto:jdarcangelo@mozilla.com Justin D'Arcangelo (:justindarc)] - engineering<br />
* [mailto:jonas@sicking.cc Jonas Sicking (:sicking)] - engineering / specifications<br />
* [mailto:nyee@mozilla.com Nicole Yee (:nicoleyee)] - project management<br />
<br />
=Bug Tracking=<br />
<bugzilla><br />
{<br />
"blocks":"1228662",<br />
"status":["NEW","REOPENED","UNCONFIRMED","ASSIGNED","RESOLVED","VERIFIED","CLOSED"],<br />
"include_fields": "id, summary, status, target_milestone, resolution, assigned_to, depends_on, blocks, whiteboard, cf_feature_b2g"<br />
}<br />
</bugzilla><br />
<br />
=Communication=<br />
<br />
==Video Conferencing - Vidyo Room==<br />
<big>[https://v.mozilla.com/flex.html?roomdirect.html&key=8uhXHJqVblWNGubS4x0he1qB810 Quick link to join with the Vidyo app (prompts install if needed)]</big><br />
<br />
We have our own Vidyo room for meetings. Contributors and non-employees are welcome to attend all meetings. Here are the full details for joining:<br />
<br />
{| class="wikitable collapsible collapsed" style="width: 100%"<br />
! "FlyWeb" Vidyo Room<br />
|-<br />
|<br />
Hello,<br><br />
<br><br />
You have been invited to attend a Mozilla Vidyo conference. Please click on the link below to attend:<br><br />
<br><br />
https://v.mozilla.com/flex.html?roomdirect.html&key=8uhXHJqVblWNGubS4x0he1qB810<br><br />
<br><br />
If you do not have a user account, please enter your name in the "Guest Name" field and then click "Join".<br><br />
<br><br />
To join from a telephone, dial one of the following numbers depending on your nearest location:<br><br />
<br><br />
US Toll Free +1 800 707 2533, pin 369, conf 98860<br><br />
US/CA/Mountain View +1 650 903 0800, extension 92, 98860<br><br />
US/CA/San Francisco: +1 415 762 5700, extension 92, 98860<br><br />
US/OR/Portland: +1 971 544 8000, extension 92, 98860<br><br />
CA/BC/Vancouver: +1 778 785 1540, extension 92, 98860<br><br />
CA/ON/Toronto: +1 416 848 3114, extension 92, 98860<br><br />
UK/London: +44 (0)207 855 3000, extension 92, 98860<br><br />
FR/Paris: +33 1 184 883 737, extension 3, extension 92, 98860<br><br />
DE/Berlin: +49 30 983 333 000, extension 92, 98860<br><br />
NZ/Auckland: +64 9 555 1100, extension 92, 98860<br />
|}<br />
<br />
=Project Management=<br />
<br />
<big>[https://trello.com/b/IlFy9m7y/flyweb Trello dashboard]</big><br />
<br />
We use Trello for project management. All ongoing tasks are listed there.<br />
<br />
=Meetings=<br />
<br />
==Calendar==<br />
<big>[https://www.google.com/calendar/embed?src=mozilla.com_g1v696sr9vu27f2tuvunmevna0%40group.calendar.google.com Calendar]</big><br />
<br />
The FlyWeb team has a public calendar with every team meeting.<br />
<br />
===Instructions for Adding to your Calendar===<br />
<br />
# Open the [https://www.google.com/calendar/embed?src=mozilla.com_g1v696sr9vu27f2tuvunmevna0%40group.calendar.google.com calendar].<br />
# Click on the "+ Google Calendar" button in the very bottom right of your screen.<br />
<br />
You can also use the [https://www.google.com/calendar/feeds/mozilla.com_g1v696sr9vu27f2tuvunmevna0%40group.calendar.google.com/public/basic XML] and [https://www.google.com/calendar/ical/mozilla.com_g1v696sr9vu27f2tuvunmevna0%40group.calendar.google.com/public/basic.ics ICS] methods, but these are not recommended.<br />
<br />
Note: The "Find a Time" feature will not work for other people if you import this calendar. As a consequence, others will not see that you are unavailable when attending a FlyWeb meeting. We suggest either accepting this, or adding the meetings to your main calendar as well.<br />
<br />
==Standups==<br />
<br />
We have two weekly standups, with both times available on the [[#Calendar|Public Calendar]]. These standups happen in the [[#Video Conferencing - Vidyo Room|FlyWeb Vidyo room]].<br />
<br />
==All meeting minutes==<br />
===2015-Q3===<br />
* [[FlyWeb/Meetings/2015-08-20 - FlyWeb+Presentation API|2015-08-20 - FlyWeb+Presentation API]]<br />
* [[FlyWeb/Meetings/2015-08-13 - Standup, late|2015-08-13 - Standup, late]]<br />
* [[FlyWeb/Meetings/2015-08-12 - Use case culling|2015-08-12 - Use case culling]]<br />
* [[FlyWeb/Meetings/2015-08-12 - Technical materials compilation|2015-08-12 - Technical materials compilation]]<br />
<br />
=See Also=<br />
* [https://docs.google.com/document/d/1MoyseigM7iYSoQZ0PsnIyU6yE1GzwE7-ETCZOS1hmFw/edit User and Market Research]: Due to the confidential nature of the interviews, and our respect for our interviewees' privacy, we are restricting access to this information.<br />
<br />
==Strategy Essays==<br />
* [https://docs.google.com/document/d/1o3pY73CBiFSx7fNDwDfzJ1TggUIIa-RWBL4-eqpy_nE/edit 2015-05 Operational Overview]<br />
* [https://docs.google.com/document/d/1948ryrtM2_zCQKy7ADcnwoxcviTC4sOvCeCtJGcwDVU/edit 2015-07 In-depth Strategy Document]<br />
<br />
==Related Initiatives==<br />
* [https://github.com/google/physical-web Google's "Physical Web" Initiative]<br />
* [http://coap.technology/impls.html Constrained Application Model - Internet of Things]<br />
<br />
==Related APIs==<br />
* [http://www.w3.org/TR/presentation-api/ W3C Presentation API]<br />
* [https://blog.mozilla.org/blog/2015/05/14/first-panasonic-smart-tvs-powered-by-firefox-os-debut-worldwide/ Mozilla Smart TV's]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1143996 KDDI Web-Cast]<br />
* [https://en.wikipedia.org/wiki/Discovery_and_Launch Discovery and Launch (DIAL)]</div>Sickinghttps://wiki.mozilla.org/index.php?title=FlyWeb/Security_scenarios&diff=1111980FlyWeb/Security scenarios2016-01-08T23:47:40Z<p>Sicking: Created page with "Below is a list of usage scenarios. They are intended to provide a few concrete examples of how FlyWeb can be used, and that we'd like to keep secure. It also contains some c..."</p>
<hr />
<div>Below is a list of usage scenarios. They are intended to provide a few concrete examples of how FlyWeb can be used, and that we'd like to keep secure.<br />
<br />
It also contains some concrete example of information that users would not like to see leaked, and types of attacks that we'd like to protect users against.<br />
<br />
== Home thermostat ==<br />
User installs a IoT-enabled thermostat in her house. They want to be able to connect to the thermostat to configure it. They does this by connecting to the thermostat and loading a HTML-based UI from it. This UI then sends requests to the thermostat in order to change settings.<br />
<br />
User does not want neighbors to be able to change thermostat setting. User does not want neighbors to be able to see when user changes the thermostat to vacation mode.<br />
<br />
== Office TV ==<br />
The user wants to display a picture slideshow on a IoT-enabled TV in the office. The user browse to flickr.com and flickr.com connects to the TV. The TV then loads a HTML UI from the flickr.com page on the users smartphone. The page on the users smartphone also changes to become a controller UI for choosing which pictures to show on the TV.<br />
<br />
The user does not want an attacker to be able to see the picture data that is sent to the TV, even if the attacker is connected to the same office network. The user does not an attacker to be able to make requests to the smartphone and thereby trick the smartphone into sending pictures directly to those devices. The user does not want an attacker to send commands to the TV, tricking the TV into loading and displaying attacker-chosen pictures on the TV.<br />
<br />
== Hotel room devices ==<br />
User rents a hotel room. Once in the hotel room the user wants to connect to several of the IoT enabled devices in the room. For example use netflix on their smartphone to watch netflix on the TV, or use pandora to connect to the in-room speakers to listen to music, connect to the thermostat and curtains to configure temperature and light.<br />
<br />
The user does not want an attacker on the same hotel wifi to be able to display netflix on the users TV, play audio through the room speakers, etc. The user does also not want an attacker on the same hotel wifi to be able to see what movie on netflix that the user is watching, or what songs on pandora that the user is playing.<br />
<br />
== Parking meter ==<br />
User parks car and and wants to pay for parking. User connects to the parking meter and loads a HTML interface from it. User uses the HTML interface to pay for the parking using amazon pay or paypal.<br />
<br />
User does not want the money to be sent to an attacker rather than to the city which owns the parking spot. The user does not want an attacker to know the user's location.<br />
<br />
== P2P photo sharing ==<br />
After attending an event together, two users, Adam and Beth, want to exchange pictures from their smartphones with each other. Adam navigate to pictureshare.com. The pictureshare.com page asks Adam to allow it to create a detectable service which other people can connect to, which Adam approves. Beth connects to the service shared from Adam's smartphone and loads a HTML UI from it.<br />
<br />
Adam and Beth then both select pictures that they want to share with each other, and then both receive the pictures shared by the other person.<br />
<br />
Both Adam and Beth wants to be sure that the pictures they share are sent only to the other person. They also want to be sure that the pictures that they receive are from the other person.</div>Sickinghttps://wiki.mozilla.org/index.php?title=FlyWeb&diff=1111972FlyWeb2016-01-08T22:38:04Z<p>Sicking: /* Team */</p>
<hr />
<div>[[File:FlyWeb.png|150px|frameless|left|FlyWeb]]<br />
<br />
The web already powers the world's email, media, shopping, and more. Interacting with these things is a breeze because they all use the web. What if the electronics around us were the same?<br />
<br />
Meet <strong>FlyWeb</strong>. FlyWeb is a very simple idea at its core. Instead of phones interacting only with the cloud, they can discover and interact with electronics around them that are running empty web clients, such as TV's, projectors, game consoles, etc. The electronics come to life when connected to phones. The key here is that either the phones serve web apps to these electronics, or the electronics serve web apps to the phones.<br />
<br />
<br />
<br />
==Why?==<br />
<br />
The connected devices market is ready to explode. As the market grows, much like the early internet, these devices are being segregated into walled gardens of one-off proprietary initiatives, such as AirPlay, the Google Cast API, etc. These solutions not only lock their users into specific vendor ecosystems -- to the benefit of those vendors and detriment of their users -- but also require significant investment to solve each use case.<br />
<br />
Many of these connected devices initiatives have common underlying platform needs:<br />
* to discover and connect devices together,<br />
* enable bi-directional communication,<br />
* allow arbitrary, but secure code execution on each side,<br />
* and require knowledge of as few details of a device's peers as possible.<br />
<br />
The web is the best platform for serving all of these needs. Indeed, it has been designed for them for over a decade.<br />
<br />
=Demo Videos=<br />
* [https://blog.mozilla.org/blog/2015/11/09/mozfest-2015-demo-garage-showing-whats-possible-with-the-open-web/?fb_action_ids=10208274568127989&fb_action_types=og.likes Demo at Mozfest 11/5/15]<br />
* [https://youtu.be/j3E4dKNaQRM Early Trailer Video]<br />
** [https://youtu.be/kq1ygsQzuO0 Developer commentary over this video.]<br />
* [https://youtu.be/g-zHE33xKng Early-stage browser casting demo.]<br />
<br />
=Proposal=<br />
* [https://docs.google.com/document/d/12i_UjTvmhViXho-wIy4UWrghuFxLls_HYEk1F9-f_GM/edit?usp=sharing Draft Proposal Link]<br />
* [https://github.com/flyweb/spec Draft Specification Link]<br />
<br />
=Team=<br />
* [mailto:kvijayan@mozilla.com Kannan Vijayan (:djvj)] - engineering<br />
* [mailto:jdarcangelo@mozilla.com Justin D'Arcangelo (:justindarc)] - engineering<br />
* [mailto:jonas@sicking.cc Jonas Sicking (:sicking)] - engineering / specifications<br />
* [mailto:nyee@mozilla.com Nicole Yee (:nicoleyee)] - project management<br />
<br />
=Bug Tracking=<br />
<bugzilla><br />
{<br />
"blocks":"1228662",<br />
"status":["NEW","REOPENED","UNCONFIRMED","ASSIGNED","RESOLVED","VERIFIED","CLOSED"],<br />
"include_fields": "id, summary, status, target_milestone, resolution, assigned_to, depends_on, blocks, whiteboard, cf_feature_b2g"<br />
}<br />
</bugzilla><br />
<br />
=Communication=<br />
<br />
==Video Conferencing - Vidyo Room==<br />
<big>[https://v.mozilla.com/flex.html?roomdirect.html&key=8uhXHJqVblWNGubS4x0he1qB810 Quick link to join with the Vidyo app (prompts install if needed)]</big><br />
<br />
We have our own Vidyo room for meetings. Contributors and non-employees are welcome to attend all meetings. Here are the full details for joining:<br />
<br />
{| class="wikitable collapsible collapsed" style="width: 100%"<br />
! "FlyWeb" Vidyo Room<br />
|-<br />
|<br />
Hello,<br><br />
<br><br />
You have been invited to attend a Mozilla Vidyo conference. Please click on the link below to attend:<br><br />
<br><br />
https://v.mozilla.com/flex.html?roomdirect.html&key=8uhXHJqVblWNGubS4x0he1qB810<br><br />
<br><br />
If you do not have a user account, please enter your name in the "Guest Name" field and then click "Join".<br><br />
<br><br />
To join from a telephone, dial one of the following numbers depending on your nearest location:<br><br />
<br><br />
US Toll Free +1 800 707 2533, pin 369, conf 98860<br><br />
US/CA/Mountain View +1 650 903 0800, extension 92, 98860<br><br />
US/CA/San Francisco: +1 415 762 5700, extension 92, 98860<br><br />
US/OR/Portland: +1 971 544 8000, extension 92, 98860<br><br />
CA/BC/Vancouver: +1 778 785 1540, extension 92, 98860<br><br />
CA/ON/Toronto: +1 416 848 3114, extension 92, 98860<br><br />
UK/London: +44 (0)207 855 3000, extension 92, 98860<br><br />
FR/Paris: +33 1 184 883 737, extension 3, extension 92, 98860<br><br />
DE/Berlin: +49 30 983 333 000, extension 92, 98860<br><br />
NZ/Auckland: +64 9 555 1100, extension 92, 98860<br />
|}<br />
<br />
=Project Management=<br />
<br />
<big>[https://trello.com/b/IlFy9m7y/flyweb Trello dashboard]</big><br />
<br />
We use Trello for project management. All ongoing tasks are listed there.<br />
<br />
=Meetings=<br />
<br />
==Calendar==<br />
<big>[https://www.google.com/calendar/embed?src=mozilla.com_g1v696sr9vu27f2tuvunmevna0%40group.calendar.google.com Calendar]</big><br />
<br />
The FlyWeb team has a public calendar with every team meeting.<br />
<br />
===Instructions for Adding to your Calendar===<br />
<br />
# Open the [https://www.google.com/calendar/embed?src=mozilla.com_g1v696sr9vu27f2tuvunmevna0%40group.calendar.google.com calendar].<br />
# Click on the "+ Google Calendar" button in the very bottom right of your screen.<br />
<br />
You can also use the [https://www.google.com/calendar/feeds/mozilla.com_g1v696sr9vu27f2tuvunmevna0%40group.calendar.google.com/public/basic XML] and [https://www.google.com/calendar/ical/mozilla.com_g1v696sr9vu27f2tuvunmevna0%40group.calendar.google.com/public/basic.ics ICS] methods, but these are not recommended.<br />
<br />
Note: The "Find a Time" feature will not work for other people if you import this calendar. As a consequence, others will not see that you are unavailable when attending a FlyWeb meeting. We suggest either accepting this, or adding the meetings to your main calendar as well.<br />
<br />
==Standups==<br />
<br />
We have two weekly standups, with both times available on the [[#Calendar|Public Calendar]]. These standups happen in the [[#Video Conferencing - Vidyo Room|FlyWeb Vidyo room]].<br />
<br />
==All meeting minutes==<br />
===2015-Q3===<br />
* [[FlyWeb/Meetings/2015-08-20 - FlyWeb+Presentation API|2015-08-20 - FlyWeb+Presentation API]]<br />
* [[FlyWeb/Meetings/2015-08-13 - Standup, late|2015-08-13 - Standup, late]]<br />
* [[FlyWeb/Meetings/2015-08-12 - Use case culling|2015-08-12 - Use case culling]]<br />
* [[FlyWeb/Meetings/2015-08-12 - Technical materials compilation|2015-08-12 - Technical materials compilation]]<br />
<br />
=See Also=<br />
* [https://docs.google.com/document/d/1MoyseigM7iYSoQZ0PsnIyU6yE1GzwE7-ETCZOS1hmFw/edit User and Market Research]: Due to the confidential nature of the interviews, and our respect for our interviewees' privacy, we are restricting access to this information.<br />
<br />
==Strategy Essays==<br />
* [https://docs.google.com/document/d/1o3pY73CBiFSx7fNDwDfzJ1TggUIIa-RWBL4-eqpy_nE/edit 2015-05 Operational Overview]<br />
* [https://docs.google.com/document/d/1948ryrtM2_zCQKy7ADcnwoxcviTC4sOvCeCtJGcwDVU/edit 2015-07 In-depth Strategy Document]<br />
<br />
==Related Initiatives==<br />
* [https://github.com/google/physical-web Google's "Physical Web" Initiative]<br />
* [http://coap.technology/impls.html Constrained Application Model - Internet of Things]<br />
<br />
==Related APIs==<br />
* [http://www.w3.org/TR/presentation-api/ W3C Presentation API]<br />
* [https://blog.mozilla.org/blog/2015/05/14/first-panasonic-smart-tvs-powered-by-firefox-os-debut-worldwide/ Mozilla Smart TV's]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1143996 KDDI Web-Cast]<br />
* [https://en.wikipedia.org/wiki/Discovery_and_Launch Discovery and Launch (DIAL)]</div>Sickinghttps://wiki.mozilla.org/index.php?title=ReleaseEngineering/DisposableProjectRepositories&diff=1109445ReleaseEngineering/DisposableProjectRepositories2015-12-16T07:13:07Z<p>Sicking: /* BOOKING SCHEDULE */ add bug link</p>
<hr />
<div>== What is a disposable project branch? ==<br />
These are project branches that can be cloned fresh from any mozilla-central based repo with the full gamut of tests enabled. No l10n or<br />
nightlies for now. Similar to [[ReleaseEngineering/TryServer|TryServer]] but for longer, and just for '''you'''. Unlike Try, the commit level on these branches is '''level_2 (and above) contributors only''' so please bear that in mind.<br />
<br />
===Do you need a disposable branch?===<br />
Ask yourself the following:<br />
<br />
'''Does your project have an end date?'''<br />
<br />
If your answer is '''No''' then you should follow the process at [https://wiki.mozilla.org/ReleaseEngineering:ProjectBranchPlanning Project Branch Planning]<br />
<br />
<br />
If your project is a temporary feature sprint that needs its own rapid test coverage but will eventually be merged into mozilla-central and no longer be on its own by all means, please go ahead and <br />
<br />
===Book one of our fabulous "disposable" project branches===<br />
'''''NOTE:''''' The number of disposable branches is limited by CI capacity. If there are no available branches, contact the owners of existing branches to see if you can "sub let".<br />
<br />
* Sign up below in the [[#BOOKING_SCHEDULE|BOOKING SCHEDULE]]<br />
* Make a [https://bugzilla.mozilla.org/enter_bug.cgi?product=Developer%20Services&component=Mercurial:%20hg.mozilla.org&short_desc=Requesting%20twig%20repo%20{booked_repo}%20be%20reset&comment=Please%20run%20the%20{script_name}%20and%20reset%20{booked_repo}%20to%20{url}&cc=buildduty@releng.bugs request] (example: {{bug|951811}}) to IT to reset the repo for you as a clone from your own project repo (or default mozilla-central:tip). '''Copy the script below into bug request, replacing the REPO_PATH and TWIG with your repo and booked branch'''.<br />
<pre><br />
export REPO_PATH=[path to your repo] # eg: users/lsblakk_mozilla.com/staging or comm-central<br />
export TWIG=[alder|birch|cedar|holly|larch|maple] # whichever twig you booked<br />
<br />
cd /repo/hg/scripts/<br />
./reset_pp_repo.sh -s /repo/hg/mozilla/$REPO_PATH -r tip -d $TWIG<br />
</pre><br />
* '''NOTE''': Coordinate with IT when this repo gets reset to push immediately without hitting the webheads. Otherwise, the permissions won't be set correctly.<br />
* '''NOTE''': Your repository will have no hooks enabled after a reset. You'll need to specify in the request if you need any configured.<br />
* Sit back and watch your builds and test results roll in (eg [http://tbpl.mozilla.org/?tree=Alder Alder], [http://tbpl.mozilla.org/?tree=Birch Birch], [http://tbpl.mozilla.org/?tree=Cedar Cedar],[http://tbpl.mozilla.org/?tree=Holly Holly], [http://tbpl.mozilla.org/?tree=Larch Larch], [http://tbpl.mozilla.org/?tree=Maple Maple]). <br />
* '''Special note:''' the first push to your newly cloned repo may not trigger builds if the repo had been pushed to previously, which is {{bug|774862}}. If it does not, please re-open the bug and move it to Release Engineering :: General Automation with a comment 'Please reconfigure the build scheduler'.<br />
<br />
<div id="unbook"></div><br />
<br />
===When you're done with one of our fabulous "disposable" project branches===<br />
<br />
Simply clear your data (bug, contact, dates) from the [[#BOOKING_SCHEDULE|BOOKING SCHEDULE]] below. If someone is listed in the "Next in Line" column, please let them know you are done.<br />
<br />
That's all there is to it!<br />
<br />
== Using a custom mozconfig ==<br />
<br />
The mozconfigs used for builds live in the same source tree as the main code, eg<br />
* Firefox: <tt>browser/config/mozconfigs/<platform></tt><br />
* Mobile Native: <tt>mobile/android/config/mozconfigs/android</tt><br />
* Mobile XUL: <tt>mobile/xul/config/mozconfigs/android-xul</tt><br />
<br />
The 'nightly' file is used for optimised builds, 'debug' for debug. If you are unsure which file you need consult a build log to see which is used. You can adjust these as needed on your branch, and they will be carried over to mozilla-central when you merge back. Please take care with any mozconfig changes you merge back (eg exclude local conveniences).<br />
<br />
==Enabling/Disabling of platforms, tests, nightly updates ==<br />
If the specific builds/tests you want are not enabled, or if there are builds/tests which you do not need on your branch, ask RelEng to enable/disable them by filing a bug [https://bugzilla.mozilla.org/enter_bug.cgi?product=Release%20Engineering here].<br />
<br />
Nightly builds and updates are disabled by default but can be enabled on request.<br />
<br />
== BOOKING SCHEDULE ==<br />
<br />
{| class="data wikitable"<br />
|-<br />
! Project Branch<br />
! Regist. bug<br />
! email address of borrower<br />
! User/Dev Team contact <br />
! Booking Dates <br />
! Next in Line<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=alder Alder]<br />
| <br />
| bhearsum@mozilla.com<br />
| <br />
| <br />
| <br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=ash Ash]<br />
| <br />
| nthomas@mozilla.com<br />
| <br />
| 2015-06-01 - TBD<br />
|<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=cypress Cypress]<br />
| {{bug|1222301}}<br />
| Pidgeot18@gmail.com<br />
| <br />
| <br />
|<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=date Date]<br />
| {{bug|1118796}}<br />
| nthomas@mozilla.com<br />
| Release automation changes<br />
| 2015-01-11 - 2015-03-31<br />
|<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=elm Elm]<br />
| {{bug|627699}}<br />
| glandium@mozilla.com<br />
| Gtk+3 work<br />
| 2014-06-19 - ??? '''''<span color="yellow">PENDING</span>'''''<br />
| -<br />
|-<br />
| <strike>[https://treeherder.mozilla.org/#/jobs?repo=fig Fig]</strike><br />
| retired<br />
| retired<br />
| retired<br />
| retired<br />
| retired<br />
|-<br />
| <strike>[https://treeherder.mozilla.org/#/jobs?repo=gum Gum]</strike><br />
| retired<br />
| retired<br />
| retired<br />
| retired<br />
| retired<br />
|-<br />
| <strike>[https://treeherder.mozilla.org/#/jobs?repo=holly Holly]</strike><br />
| retired<br />
| retired<br />
| retired<br />
| retired<br />
| retired<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=jamun Jamun]<br />
| {{bug|1147314}}<br />
| kechang@mozilla.com, kchen@mozilla.com<br />
| Nested OOP<br />
| 2015-03-25 - 2015-12-31<br />
| <br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=larch Larch]<br />
| {{bug|1232934}}<br />
| sicking@mozilla.com<br />
| :sicking, FlyWeb platform feature<br />
| 2015-12-15 - 2016-06-30<br />
|<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=oak Oak]<br />
| {{bug|790467}} and other risky updater work<br />
| spohl@mozilla.com, rstrong@mozilla.com<br />
| spohl, rstrong<br />
| 2012-09-11 - 2015-12-31 '''''<span color="yellow">PENDING</span>'''''<br />
| -<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=pine Pine]<br />
| {{bug|929203}}<br />
| jgriffin@mozilla.com<br />
| :gwagner, debug B2G builds and unit tests<br />
| 2013-10-21 - indefinite '''''<span color="yellow">PENDING</span>'''''<br />
| -<br />
|}<br />
<br />
Be sure to keep a copy of anything you need from the repo prior to [[#unbook|unbooking]] it.<br />
<br />
== Indefinite booking ==<br />
See also [[ReleaseEngineering/SpecialBranches]] for more info on these branches.<br />
{| class="data"<br />
|-<br />
! Project Branch<br />
! Regist. bug<br />
! email address of borrower<br />
! User/Dev Team contact <br />
! Booking Dates <br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=birch Birch]<br />
| {{bug|1010674}}<br />
| catlee@mozilla.com<br />
| disabled<br />
| 2014-05-15 - indefinite '''''<span color="yellow">PENDING</span>'''''<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=cedar Cedar]<br />
| -<br />
| jgriffin@mozilla.com<br />
| new build/test testing for #ateam and #releng<br />
| 2012-06-25 - indefinite '''''<span color="yellow">PENDING</span>'''''<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=maple Maple]<br />
| -<br />
| catlee@mozilla.com<br />
| disabled<br />
| -<br />
| -<br />
|}</div>Sickinghttps://wiki.mozilla.org/index.php?title=ReleaseEngineering/DisposableProjectRepositories&diff=1109444ReleaseEngineering/DisposableProjectRepositories2015-12-16T07:07:33Z<p>Sicking: /* BOOKING SCHEDULE */ Book Larch for FlyWeb</p>
<hr />
<div>== What is a disposable project branch? ==<br />
These are project branches that can be cloned fresh from any mozilla-central based repo with the full gamut of tests enabled. No l10n or<br />
nightlies for now. Similar to [[ReleaseEngineering/TryServer|TryServer]] but for longer, and just for '''you'''. Unlike Try, the commit level on these branches is '''level_2 (and above) contributors only''' so please bear that in mind.<br />
<br />
===Do you need a disposable branch?===<br />
Ask yourself the following:<br />
<br />
'''Does your project have an end date?'''<br />
<br />
If your answer is '''No''' then you should follow the process at [https://wiki.mozilla.org/ReleaseEngineering:ProjectBranchPlanning Project Branch Planning]<br />
<br />
<br />
If your project is a temporary feature sprint that needs its own rapid test coverage but will eventually be merged into mozilla-central and no longer be on its own by all means, please go ahead and <br />
<br />
===Book one of our fabulous "disposable" project branches===<br />
'''''NOTE:''''' The number of disposable branches is limited by CI capacity. If there are no available branches, contact the owners of existing branches to see if you can "sub let".<br />
<br />
* Sign up below in the [[#BOOKING_SCHEDULE|BOOKING SCHEDULE]]<br />
* Make a [https://bugzilla.mozilla.org/enter_bug.cgi?product=Developer%20Services&component=Mercurial:%20hg.mozilla.org&short_desc=Requesting%20twig%20repo%20{booked_repo}%20be%20reset&comment=Please%20run%20the%20{script_name}%20and%20reset%20{booked_repo}%20to%20{url}&cc=buildduty@releng.bugs request] (example: {{bug|951811}}) to IT to reset the repo for you as a clone from your own project repo (or default mozilla-central:tip). '''Copy the script below into bug request, replacing the REPO_PATH and TWIG with your repo and booked branch'''.<br />
<pre><br />
export REPO_PATH=[path to your repo] # eg: users/lsblakk_mozilla.com/staging or comm-central<br />
export TWIG=[alder|birch|cedar|holly|larch|maple] # whichever twig you booked<br />
<br />
cd /repo/hg/scripts/<br />
./reset_pp_repo.sh -s /repo/hg/mozilla/$REPO_PATH -r tip -d $TWIG<br />
</pre><br />
* '''NOTE''': Coordinate with IT when this repo gets reset to push immediately without hitting the webheads. Otherwise, the permissions won't be set correctly.<br />
* '''NOTE''': Your repository will have no hooks enabled after a reset. You'll need to specify in the request if you need any configured.<br />
* Sit back and watch your builds and test results roll in (eg [http://tbpl.mozilla.org/?tree=Alder Alder], [http://tbpl.mozilla.org/?tree=Birch Birch], [http://tbpl.mozilla.org/?tree=Cedar Cedar],[http://tbpl.mozilla.org/?tree=Holly Holly], [http://tbpl.mozilla.org/?tree=Larch Larch], [http://tbpl.mozilla.org/?tree=Maple Maple]). <br />
* '''Special note:''' the first push to your newly cloned repo may not trigger builds if the repo had been pushed to previously, which is {{bug|774862}}. If it does not, please re-open the bug and move it to Release Engineering :: General Automation with a comment 'Please reconfigure the build scheduler'.<br />
<br />
<div id="unbook"></div><br />
<br />
===When you're done with one of our fabulous "disposable" project branches===<br />
<br />
Simply clear your data (bug, contact, dates) from the [[#BOOKING_SCHEDULE|BOOKING SCHEDULE]] below. If someone is listed in the "Next in Line" column, please let them know you are done.<br />
<br />
That's all there is to it!<br />
<br />
== Using a custom mozconfig ==<br />
<br />
The mozconfigs used for builds live in the same source tree as the main code, eg<br />
* Firefox: <tt>browser/config/mozconfigs/<platform></tt><br />
* Mobile Native: <tt>mobile/android/config/mozconfigs/android</tt><br />
* Mobile XUL: <tt>mobile/xul/config/mozconfigs/android-xul</tt><br />
<br />
The 'nightly' file is used for optimised builds, 'debug' for debug. If you are unsure which file you need consult a build log to see which is used. You can adjust these as needed on your branch, and they will be carried over to mozilla-central when you merge back. Please take care with any mozconfig changes you merge back (eg exclude local conveniences).<br />
<br />
==Enabling/Disabling of platforms, tests, nightly updates ==<br />
If the specific builds/tests you want are not enabled, or if there are builds/tests which you do not need on your branch, ask RelEng to enable/disable them by filing a bug [https://bugzilla.mozilla.org/enter_bug.cgi?product=Release%20Engineering here].<br />
<br />
Nightly builds and updates are disabled by default but can be enabled on request.<br />
<br />
== BOOKING SCHEDULE ==<br />
<br />
{| class="data wikitable"<br />
|-<br />
! Project Branch<br />
! Regist. bug<br />
! email address of borrower<br />
! User/Dev Team contact <br />
! Booking Dates <br />
! Next in Line<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=alder Alder]<br />
| <br />
| bhearsum@mozilla.com<br />
| <br />
| <br />
| <br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=ash Ash]<br />
| <br />
| nthomas@mozilla.com<br />
| <br />
| 2015-06-01 - TBD<br />
|<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=cypress Cypress]<br />
| {{bug|1222301}}<br />
| Pidgeot18@gmail.com<br />
| <br />
| <br />
|<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=date Date]<br />
| {{bug|1118796}}<br />
| nthomas@mozilla.com<br />
| Release automation changes<br />
| 2015-01-11 - 2015-03-31<br />
|<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=elm Elm]<br />
| {{bug|627699}}<br />
| glandium@mozilla.com<br />
| Gtk+3 work<br />
| 2014-06-19 - ??? '''''<span color="yellow">PENDING</span>'''''<br />
| -<br />
|-<br />
| <strike>[https://treeherder.mozilla.org/#/jobs?repo=fig Fig]</strike><br />
| retired<br />
| retired<br />
| retired<br />
| retired<br />
| retired<br />
|-<br />
| <strike>[https://treeherder.mozilla.org/#/jobs?repo=gum Gum]</strike><br />
| retired<br />
| retired<br />
| retired<br />
| retired<br />
| retired<br />
|-<br />
| <strike>[https://treeherder.mozilla.org/#/jobs?repo=holly Holly]</strike><br />
| retired<br />
| retired<br />
| retired<br />
| retired<br />
| retired<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=jamun Jamun]<br />
| {{bug|1147314}}<br />
| kechang@mozilla.com, kchen@mozilla.com<br />
| Nested OOP<br />
| 2015-03-25 - 2015-12-31<br />
| <br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=larch Larch]<br />
|<br />
| sicking@mozilla.com<br />
| :sicking, FlyWeb platform feature<br />
| 2015-12-15 - 2016-06-30<br />
|<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=oak Oak]<br />
| {{bug|790467}} and other risky updater work<br />
| spohl@mozilla.com, rstrong@mozilla.com<br />
| spohl, rstrong<br />
| 2012-09-11 - 2015-12-31 '''''<span color="yellow">PENDING</span>'''''<br />
| -<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=pine Pine]<br />
| {{bug|929203}}<br />
| jgriffin@mozilla.com<br />
| :gwagner, debug B2G builds and unit tests<br />
| 2013-10-21 - indefinite '''''<span color="yellow">PENDING</span>'''''<br />
| -<br />
|}<br />
<br />
Be sure to keep a copy of anything you need from the repo prior to [[#unbook|unbooking]] it.<br />
<br />
== Indefinite booking ==<br />
See also [[ReleaseEngineering/SpecialBranches]] for more info on these branches.<br />
{| class="data"<br />
|-<br />
! Project Branch<br />
! Regist. bug<br />
! email address of borrower<br />
! User/Dev Team contact <br />
! Booking Dates <br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=birch Birch]<br />
| {{bug|1010674}}<br />
| catlee@mozilla.com<br />
| disabled<br />
| 2014-05-15 - indefinite '''''<span color="yellow">PENDING</span>'''''<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=cedar Cedar]<br />
| -<br />
| jgriffin@mozilla.com<br />
| new build/test testing for #ateam and #releng<br />
| 2012-06-25 - indefinite '''''<span color="yellow">PENDING</span>'''''<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=maple Maple]<br />
| -<br />
| catlee@mozilla.com<br />
| disabled<br />
| -<br />
| -<br />
|}</div>Sickinghttps://wiki.mozilla.org/index.php?title=ReleaseEngineering/DisposableProjectRepositories&diff=1109434ReleaseEngineering/DisposableProjectRepositories2015-12-16T02:57:28Z<p>Sicking: /* BOOKING SCHEDULE */ asfd</p>
<hr />
<div>== What is a disposable project branch? ==<br />
These are project branches that can be cloned fresh from any mozilla-central based repo with the full gamut of tests enabled. No l10n or<br />
nightlies for now. Similar to [[ReleaseEngineering/TryServer|TryServer]] but for longer, and just for '''you'''. Unlike Try, the commit level on these branches is '''level_2 (and above) contributors only''' so please bear that in mind.<br />
<br />
===Do you need a disposable branch?===<br />
Ask yourself the following:<br />
<br />
'''Does your project have an end date?'''<br />
<br />
If your answer is '''No''' then you should follow the process at [https://wiki.mozilla.org/ReleaseEngineering:ProjectBranchPlanning Project Branch Planning]<br />
<br />
<br />
If your project is a temporary feature sprint that needs its own rapid test coverage but will eventually be merged into mozilla-central and no longer be on its own by all means, please go ahead and <br />
<br />
===Book one of our fabulous "disposable" project branches===<br />
'''''NOTE:''''' The number of disposable branches is limited by CI capacity. If there are no available branches, contact the owners of existing branches to see if you can "sub let".<br />
<br />
* Sign up below in the [[#BOOKING_SCHEDULE|BOOKING SCHEDULE]]<br />
* Make a [https://bugzilla.mozilla.org/enter_bug.cgi?product=Developer%20Services&component=Mercurial:%20hg.mozilla.org&short_desc=Requesting%20twig%20repo%20{booked_repo}%20be%20reset&comment=Please%20run%20the%20{script_name}%20and%20reset%20{booked_repo}%20to%20{url}&cc=buildduty@releng.bugs request] (example: {{bug|951811}}) to IT to reset the repo for you as a clone from your own project repo (or default mozilla-central:tip). '''Copy the script below into bug request, replacing the REPO_PATH and TWIG with your repo and booked branch'''.<br />
<pre><br />
export REPO_PATH=[path to your repo] # eg: users/lsblakk_mozilla.com/staging or comm-central<br />
export TWIG=[alder|birch|cedar|holly|larch|maple] # whichever twig you booked<br />
<br />
cd /repo/hg/scripts/<br />
./reset_pp_repo.sh -s /repo/hg/mozilla/$REPO_PATH -r tip -d $TWIG<br />
</pre><br />
* '''NOTE''': Coordinate with IT when this repo gets reset to push immediately without hitting the webheads. Otherwise, the permissions won't be set correctly.<br />
* '''NOTE''': Your repository will have no hooks enabled after a reset. You'll need to specify in the request if you need any configured.<br />
* Sit back and watch your builds and test results roll in (eg [http://tbpl.mozilla.org/?tree=Alder Alder], [http://tbpl.mozilla.org/?tree=Birch Birch], [http://tbpl.mozilla.org/?tree=Cedar Cedar],[http://tbpl.mozilla.org/?tree=Holly Holly], [http://tbpl.mozilla.org/?tree=Larch Larch], [http://tbpl.mozilla.org/?tree=Maple Maple]). <br />
* '''Special note:''' the first push to your newly cloned repo may not trigger builds if the repo had been pushed to previously, which is {{bug|774862}}. If it does not, please re-open the bug and move it to Release Engineering :: General Automation with a comment 'Please reconfigure the build scheduler'.<br />
<br />
<div id="unbook"></div><br />
<br />
===When you're done with one of our fabulous "disposable" project branches===<br />
<br />
Simply clear your data (bug, contact, dates) from the [[#BOOKING_SCHEDULE|BOOKING SCHEDULE]] below. If someone is listed in the "Next in Line" column, please let them know you are done.<br />
<br />
That's all there is to it!<br />
<br />
== Using a custom mozconfig ==<br />
<br />
The mozconfigs used for builds live in the same source tree as the main code, eg<br />
* Firefox: <tt>browser/config/mozconfigs/<platform></tt><br />
* Mobile Native: <tt>mobile/android/config/mozconfigs/android</tt><br />
* Mobile XUL: <tt>mobile/xul/config/mozconfigs/android-xul</tt><br />
<br />
The 'nightly' file is used for optimised builds, 'debug' for debug. If you are unsure which file you need consult a build log to see which is used. You can adjust these as needed on your branch, and they will be carried over to mozilla-central when you merge back. Please take care with any mozconfig changes you merge back (eg exclude local conveniences).<br />
<br />
==Enabling/Disabling of platforms, tests, nightly updates ==<br />
If the specific builds/tests you want are not enabled, or if there are builds/tests which you do not need on your branch, ask RelEng to enable/disable them by filing a bug [https://bugzilla.mozilla.org/enter_bug.cgi?product=Release%20Engineering here].<br />
<br />
Nightly builds and updates are disabled by default but can be enabled on request.<br />
<br />
== BOOKING SCHEDULE ==<br />
<br />
{| class="data wikitable"<br />
|-<br />
! Project Branch<br />
! Regist. bug<br />
! email address of borrower<br />
! User/Dev Team contact <br />
! Booking Dates <br />
! Next in Line<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=alder Alder]<br />
| <br />
| bhearsum@mozilla.com<br />
| <br />
| <br />
| <br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=ash Ash]<br />
| <br />
| nthomas@mozilla.com<br />
| <br />
| 2015-06-01 - TBD<br />
|<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=cypress Cypress]<br />
| {{bug|1222301}}<br />
| Pidgeot18@gmail.com<br />
| <br />
| <br />
|<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=date Date]<br />
| {{bug|1118796}}<br />
| nthomas@mozilla.com<br />
| Release automation changes<br />
| 2015-01-11 - 2015-03-31<br />
|<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=elm Elm]<br />
| {{bug|627699}}<br />
| glandium@mozilla.com<br />
| Gtk+3 work<br />
| 2014-06-19 - ??? '''''<span color="yellow">PENDING</span>'''''<br />
| -<br />
|-<br />
| <strike>[https://treeherder.mozilla.org/#/jobs?repo=fig Fig]</strike><br />
| retired<br />
| retired<br />
| retired<br />
| retired<br />
| retired<br />
|-<br />
| <strike>[https://treeherder.mozilla.org/#/jobs?repo=gum Gum]</strike><br />
| retired<br />
| retired<br />
| retired<br />
| retired<br />
| retired<br />
|-<br />
| <strike>[https://treeherder.mozilla.org/#/jobs?repo=holly Holly]</strike><br />
| retired<br />
| retired<br />
| retired<br />
| retired<br />
| retired<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=jamun Jamun]<br />
| {{bug|1147314}}<br />
| kechang@mozilla.com, kchen@mozilla.com<br />
| Nested OOP<br />
| 2015-03-25 - 2015-12-31<br />
| <br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=larch Larch]<br />
| -<br />
| fabrice@mozilla.com<br />
| Project Graphene<br />
| '''''<span color="yellow">PENDING</span>'''''<br />
| <br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=oak Oak]<br />
| {{bug|790467}} and other risky updater work<br />
| spohl@mozilla.com, rstrong@mozilla.com<br />
| spohl, rstrong<br />
| 2012-09-11 - 2015-12-31 '''''<span color="yellow">PENDING</span>'''''<br />
| -<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=pine Pine]<br />
| {{bug|929203}}<br />
| jgriffin@mozilla.com<br />
| :gwagner, debug B2G builds and unit tests<br />
| 2013-10-21 - indefinite '''''<span color="yellow">PENDING</span>'''''<br />
| -<br />
|}<br />
<br />
Be sure to keep a copy of anything you need from the repo prior to [[#unbook|unbooking]] it.<br />
<br />
== Indefinite booking ==<br />
See also [[ReleaseEngineering/SpecialBranches]] for more info on these branches.<br />
{| class="data"<br />
|-<br />
! Project Branch<br />
! Regist. bug<br />
! email address of borrower<br />
! User/Dev Team contact <br />
! Booking Dates <br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=birch Birch]<br />
| {{bug|1010674}}<br />
| catlee@mozilla.com<br />
| disabled<br />
| 2014-05-15 - indefinite '''''<span color="yellow">PENDING</span>'''''<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=cedar Cedar]<br />
| -<br />
| jgriffin@mozilla.com<br />
| new build/test testing for #ateam and #releng<br />
| 2012-06-25 - indefinite '''''<span color="yellow">PENDING</span>'''''<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=maple Maple]<br />
| -<br />
| catlee@mozilla.com<br />
| disabled<br />
| -<br />
| -<br />
|}</div>Sickinghttps://wiki.mozilla.org/index.php?title=ReleaseEngineering/DisposableProjectRepositories&diff=1109433ReleaseEngineering/DisposableProjectRepositories2015-12-16T02:56:40Z<p>Sicking: /* BOOKING SCHEDULE */ revoke request</p>
<hr />
<div>== What is a disposable project branch? ==<br />
These are project branches that can be cloned fresh from any mozilla-central based repo with the full gamut of tests enabled. No l10n or<br />
nightlies for now. Similar to [[ReleaseEngineering/TryServer|TryServer]] but for longer, and just for '''you'''. Unlike Try, the commit level on these branches is '''level_2 (and above) contributors only''' so please bear that in mind.<br />
<br />
===Do you need a disposable branch?===<br />
Ask yourself the following:<br />
<br />
'''Does your project have an end date?'''<br />
<br />
If your answer is '''No''' then you should follow the process at [https://wiki.mozilla.org/ReleaseEngineering:ProjectBranchPlanning Project Branch Planning]<br />
<br />
<br />
If your project is a temporary feature sprint that needs its own rapid test coverage but will eventually be merged into mozilla-central and no longer be on its own by all means, please go ahead and <br />
<br />
===Book one of our fabulous "disposable" project branches===<br />
'''''NOTE:''''' The number of disposable branches is limited by CI capacity. If there are no available branches, contact the owners of existing branches to see if you can "sub let".<br />
<br />
* Sign up below in the [[#BOOKING_SCHEDULE|BOOKING SCHEDULE]]<br />
* Make a [https://bugzilla.mozilla.org/enter_bug.cgi?product=Developer%20Services&component=Mercurial:%20hg.mozilla.org&short_desc=Requesting%20twig%20repo%20{booked_repo}%20be%20reset&comment=Please%20run%20the%20{script_name}%20and%20reset%20{booked_repo}%20to%20{url}&cc=buildduty@releng.bugs request] (example: {{bug|951811}}) to IT to reset the repo for you as a clone from your own project repo (or default mozilla-central:tip). '''Copy the script below into bug request, replacing the REPO_PATH and TWIG with your repo and booked branch'''.<br />
<pre><br />
export REPO_PATH=[path to your repo] # eg: users/lsblakk_mozilla.com/staging or comm-central<br />
export TWIG=[alder|birch|cedar|holly|larch|maple] # whichever twig you booked<br />
<br />
cd /repo/hg/scripts/<br />
./reset_pp_repo.sh -s /repo/hg/mozilla/$REPO_PATH -r tip -d $TWIG<br />
</pre><br />
* '''NOTE''': Coordinate with IT when this repo gets reset to push immediately without hitting the webheads. Otherwise, the permissions won't be set correctly.<br />
* '''NOTE''': Your repository will have no hooks enabled after a reset. You'll need to specify in the request if you need any configured.<br />
* Sit back and watch your builds and test results roll in (eg [http://tbpl.mozilla.org/?tree=Alder Alder], [http://tbpl.mozilla.org/?tree=Birch Birch], [http://tbpl.mozilla.org/?tree=Cedar Cedar],[http://tbpl.mozilla.org/?tree=Holly Holly], [http://tbpl.mozilla.org/?tree=Larch Larch], [http://tbpl.mozilla.org/?tree=Maple Maple]). <br />
* '''Special note:''' the first push to your newly cloned repo may not trigger builds if the repo had been pushed to previously, which is {{bug|774862}}. If it does not, please re-open the bug and move it to Release Engineering :: General Automation with a comment 'Please reconfigure the build scheduler'.<br />
<br />
<div id="unbook"></div><br />
<br />
===When you're done with one of our fabulous "disposable" project branches===<br />
<br />
Simply clear your data (bug, contact, dates) from the [[#BOOKING_SCHEDULE|BOOKING SCHEDULE]] below. If someone is listed in the "Next in Line" column, please let them know you are done.<br />
<br />
That's all there is to it!<br />
<br />
== Using a custom mozconfig ==<br />
<br />
The mozconfigs used for builds live in the same source tree as the main code, eg<br />
* Firefox: <tt>browser/config/mozconfigs/<platform></tt><br />
* Mobile Native: <tt>mobile/android/config/mozconfigs/android</tt><br />
* Mobile XUL: <tt>mobile/xul/config/mozconfigs/android-xul</tt><br />
<br />
The 'nightly' file is used for optimised builds, 'debug' for debug. If you are unsure which file you need consult a build log to see which is used. You can adjust these as needed on your branch, and they will be carried over to mozilla-central when you merge back. Please take care with any mozconfig changes you merge back (eg exclude local conveniences).<br />
<br />
==Enabling/Disabling of platforms, tests, nightly updates ==<br />
If the specific builds/tests you want are not enabled, or if there are builds/tests which you do not need on your branch, ask RelEng to enable/disable them by filing a bug [https://bugzilla.mozilla.org/enter_bug.cgi?product=Release%20Engineering here].<br />
<br />
Nightly builds and updates are disabled by default but can be enabled on request.<br />
<br />
== BOOKING SCHEDULE ==<br />
<br />
{| class="data wikitable"<br />
|-<br />
! Project Branch<br />
! Regist. bug<br />
! email address of borrower<br />
! User/Dev Team contact <br />
! Booking Dates <br />
! Next in Line<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=alder Alder]<br />
| <br />
| bhearsum@mozilla.com<br />
| <br />
| <br />
| <br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=ash Ash]<br />
| <br />
| nthomas@mozilla.com<br />
| <br />
| 2015-06-01 - TBD<br />
|<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=cypress Cypress]<br />
| {{bug|1222301}}<br />
| <br />
| <br />
| <br />
|<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=date Date]<br />
| {{bug|1118796}}<br />
| nthomas@mozilla.com<br />
| Release automation changes<br />
| 2015-01-11 - 2015-03-31<br />
|<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=elm Elm]<br />
| {{bug|627699}}<br />
| glandium@mozilla.com<br />
| Gtk+3 work<br />
| 2014-06-19 - ??? '''''<span color="yellow">PENDING</span>'''''<br />
| -<br />
|-<br />
| <strike>[https://treeherder.mozilla.org/#/jobs?repo=fig Fig]</strike><br />
| retired<br />
| retired<br />
| retired<br />
| retired<br />
| retired<br />
|-<br />
| <strike>[https://treeherder.mozilla.org/#/jobs?repo=gum Gum]</strike><br />
| retired<br />
| retired<br />
| retired<br />
| retired<br />
| retired<br />
|-<br />
| <strike>[https://treeherder.mozilla.org/#/jobs?repo=holly Holly]</strike><br />
| retired<br />
| retired<br />
| retired<br />
| retired<br />
| retired<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=jamun Jamun]<br />
| {{bug|1147314}}<br />
| kechang@mozilla.com, kchen@mozilla.com<br />
| Nested OOP<br />
| 2015-03-25 - 2015-12-31<br />
| <br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=larch Larch]<br />
| -<br />
| fabrice@mozilla.com<br />
| Project Graphene<br />
| '''''<span color="yellow">PENDING</span>'''''<br />
| <br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=oak Oak]<br />
| {{bug|790467}} and other risky updater work<br />
| spohl@mozilla.com, rstrong@mozilla.com<br />
| spohl, rstrong<br />
| 2012-09-11 - 2015-12-31 '''''<span color="yellow">PENDING</span>'''''<br />
| -<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=pine Pine]<br />
| {{bug|929203}}<br />
| jgriffin@mozilla.com<br />
| :gwagner, debug B2G builds and unit tests<br />
| 2013-10-21 - indefinite '''''<span color="yellow">PENDING</span>'''''<br />
| -<br />
|}<br />
<br />
Be sure to keep a copy of anything you need from the repo prior to [[#unbook|unbooking]] it.<br />
<br />
== Indefinite booking ==<br />
See also [[ReleaseEngineering/SpecialBranches]] for more info on these branches.<br />
{| class="data"<br />
|-<br />
! Project Branch<br />
! Regist. bug<br />
! email address of borrower<br />
! User/Dev Team contact <br />
! Booking Dates <br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=birch Birch]<br />
| {{bug|1010674}}<br />
| catlee@mozilla.com<br />
| disabled<br />
| 2014-05-15 - indefinite '''''<span color="yellow">PENDING</span>'''''<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=cedar Cedar]<br />
| -<br />
| jgriffin@mozilla.com<br />
| new build/test testing for #ateam and #releng<br />
| 2012-06-25 - indefinite '''''<span color="yellow">PENDING</span>'''''<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=maple Maple]<br />
| -<br />
| catlee@mozilla.com<br />
| disabled<br />
| -<br />
| -<br />
|}</div>Sickinghttps://wiki.mozilla.org/index.php?title=ReleaseEngineering/DisposableProjectRepositories&diff=1109429ReleaseEngineering/DisposableProjectRepositories2015-12-16T02:02:46Z<p>Sicking: /* BOOKING SCHEDULE */ add bug link</p>
<hr />
<div>== What is a disposable project branch? ==<br />
These are project branches that can be cloned fresh from any mozilla-central based repo with the full gamut of tests enabled. No l10n or<br />
nightlies for now. Similar to [[ReleaseEngineering/TryServer|TryServer]] but for longer, and just for '''you'''. Unlike Try, the commit level on these branches is '''level_2 (and above) contributors only''' so please bear that in mind.<br />
<br />
===Do you need a disposable branch?===<br />
Ask yourself the following:<br />
<br />
'''Does your project have an end date?'''<br />
<br />
If your answer is '''No''' then you should follow the process at [https://wiki.mozilla.org/ReleaseEngineering:ProjectBranchPlanning Project Branch Planning]<br />
<br />
<br />
If your project is a temporary feature sprint that needs its own rapid test coverage but will eventually be merged into mozilla-central and no longer be on its own by all means, please go ahead and <br />
<br />
===Book one of our fabulous "disposable" project branches===<br />
'''''NOTE:''''' The number of disposable branches is limited by CI capacity. If there are no available branches, contact the owners of existing branches to see if you can "sub let".<br />
<br />
* Sign up below in the [[#BOOKING_SCHEDULE|BOOKING SCHEDULE]]<br />
* Make a [https://bugzilla.mozilla.org/enter_bug.cgi?product=Developer%20Services&component=Mercurial:%20hg.mozilla.org&short_desc=Requesting%20twig%20repo%20{booked_repo}%20be%20reset&comment=Please%20run%20the%20{script_name}%20and%20reset%20{booked_repo}%20to%20{url}&cc=buildduty@releng.bugs request] (example: {{bug|951811}}) to IT to reset the repo for you as a clone from your own project repo (or default mozilla-central:tip). '''Copy the script below into bug request, replacing the REPO_PATH and TWIG with your repo and booked branch'''.<br />
<pre><br />
export REPO_PATH=[path to your repo] # eg: users/lsblakk_mozilla.com/staging or comm-central<br />
export TWIG=[alder|birch|cedar|holly|larch|maple] # whichever twig you booked<br />
<br />
cd /repo/hg/scripts/<br />
./reset_pp_repo.sh -s /repo/hg/mozilla/$REPO_PATH -r tip -d $TWIG<br />
</pre><br />
* '''NOTE''': Coordinate with IT when this repo gets reset to push immediately without hitting the webheads. Otherwise, the permissions won't be set correctly.<br />
* '''NOTE''': Your repository will have no hooks enabled after a reset. You'll need to specify in the request if you need any configured.<br />
* Sit back and watch your builds and test results roll in (eg [http://tbpl.mozilla.org/?tree=Alder Alder], [http://tbpl.mozilla.org/?tree=Birch Birch], [http://tbpl.mozilla.org/?tree=Cedar Cedar],[http://tbpl.mozilla.org/?tree=Holly Holly], [http://tbpl.mozilla.org/?tree=Larch Larch], [http://tbpl.mozilla.org/?tree=Maple Maple]). <br />
* '''Special note:''' the first push to your newly cloned repo may not trigger builds if the repo had been pushed to previously, which is {{bug|774862}}. If it does not, please re-open the bug and move it to Release Engineering :: General Automation with a comment 'Please reconfigure the build scheduler'.<br />
<br />
<div id="unbook"></div><br />
<br />
===When you're done with one of our fabulous "disposable" project branches===<br />
<br />
Simply clear your data (bug, contact, dates) from the [[#BOOKING_SCHEDULE|BOOKING SCHEDULE]] below. If someone is listed in the "Next in Line" column, please let them know you are done.<br />
<br />
That's all there is to it!<br />
<br />
== Using a custom mozconfig ==<br />
<br />
The mozconfigs used for builds live in the same source tree as the main code, eg<br />
* Firefox: <tt>browser/config/mozconfigs/<platform></tt><br />
* Mobile Native: <tt>mobile/android/config/mozconfigs/android</tt><br />
* Mobile XUL: <tt>mobile/xul/config/mozconfigs/android-xul</tt><br />
<br />
The 'nightly' file is used for optimised builds, 'debug' for debug. If you are unsure which file you need consult a build log to see which is used. You can adjust these as needed on your branch, and they will be carried over to mozilla-central when you merge back. Please take care with any mozconfig changes you merge back (eg exclude local conveniences).<br />
<br />
==Enabling/Disabling of platforms, tests, nightly updates ==<br />
If the specific builds/tests you want are not enabled, or if there are builds/tests which you do not need on your branch, ask RelEng to enable/disable them by filing a bug [https://bugzilla.mozilla.org/enter_bug.cgi?product=Release%20Engineering here].<br />
<br />
Nightly builds and updates are disabled by default but can be enabled on request.<br />
<br />
== BOOKING SCHEDULE ==<br />
<br />
{| class="data wikitable"<br />
|-<br />
! Project Branch<br />
! Regist. bug<br />
! email address of borrower<br />
! User/Dev Team contact <br />
! Booking Dates <br />
! Next in Line<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=alder Alder]<br />
| <br />
| bhearsum@mozilla.com<br />
| <br />
| <br />
| <br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=ash Ash]<br />
| <br />
| nthomas@mozilla.com<br />
| <br />
| 2015-06-01 - TBD<br />
|<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=cypress Cypress]<br />
| {{bug|1232872}}<br />
| sicking@mozilla.com<br />
| :sicking, FlyWeb platform feature<br />
| 2015-12-15 - 2016-06-30<br />
|<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=date Date]<br />
| {{bug|1118796}}<br />
| nthomas@mozilla.com<br />
| Release automation changes<br />
| 2015-01-11 - 2015-03-31<br />
|<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=elm Elm]<br />
| {{bug|627699}}<br />
| glandium@mozilla.com<br />
| Gtk+3 work<br />
| 2014-06-19 - ??? '''''<span color="yellow">PENDING</span>'''''<br />
| -<br />
|-<br />
| <strike>[https://treeherder.mozilla.org/#/jobs?repo=fig Fig]</strike><br />
| retired<br />
| retired<br />
| retired<br />
| retired<br />
| retired<br />
|-<br />
| <strike>[https://treeherder.mozilla.org/#/jobs?repo=gum Gum]</strike><br />
| retired<br />
| retired<br />
| retired<br />
| retired<br />
| retired<br />
|-<br />
| <strike>[https://treeherder.mozilla.org/#/jobs?repo=holly Holly]</strike><br />
| retired<br />
| retired<br />
| retired<br />
| retired<br />
| retired<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=jamun Jamun]<br />
| {{bug|1147314}}<br />
| kechang@mozilla.com, kchen@mozilla.com<br />
| Nested OOP<br />
| 2015-03-25 - 2015-12-31<br />
| <br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=larch Larch]<br />
| -<br />
| fabrice@mozilla.com<br />
| Project Graphene<br />
| '''''<span color="yellow">PENDING</span>'''''<br />
| <br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=oak Oak]<br />
| {{bug|790467}} and other risky updater work<br />
| spohl@mozilla.com, rstrong@mozilla.com<br />
| spohl, rstrong<br />
| 2012-09-11 - 2015-12-31 '''''<span color="yellow">PENDING</span>'''''<br />
| -<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=pine Pine]<br />
| {{bug|929203}}<br />
| jgriffin@mozilla.com<br />
| :gwagner, debug B2G builds and unit tests<br />
| 2013-10-21 - indefinite '''''<span color="yellow">PENDING</span>'''''<br />
| -<br />
|}<br />
<br />
Be sure to keep a copy of anything you need from the repo prior to [[#unbook|unbooking]] it.<br />
<br />
== Indefinite booking ==<br />
See also [[ReleaseEngineering/SpecialBranches]] for more info on these branches.<br />
{| class="data"<br />
|-<br />
! Project Branch<br />
! Regist. bug<br />
! email address of borrower<br />
! User/Dev Team contact <br />
! Booking Dates <br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=birch Birch]<br />
| {{bug|1010674}}<br />
| catlee@mozilla.com<br />
| disabled<br />
| 2014-05-15 - indefinite '''''<span color="yellow">PENDING</span>'''''<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=cedar Cedar]<br />
| -<br />
| jgriffin@mozilla.com<br />
| new build/test testing for #ateam and #releng<br />
| 2012-06-25 - indefinite '''''<span color="yellow">PENDING</span>'''''<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=maple Maple]<br />
| -<br />
| catlee@mozilla.com<br />
| disabled<br />
| -<br />
| -<br />
|}</div>Sickinghttps://wiki.mozilla.org/index.php?title=ReleaseEngineering/DisposableProjectRepositories&diff=1109422ReleaseEngineering/DisposableProjectRepositories2015-12-16T01:30:32Z<p>Sicking: Request a twig for FlyWeb</p>
<hr />
<div>== What is a disposable project branch? ==<br />
These are project branches that can be cloned fresh from any mozilla-central based repo with the full gamut of tests enabled. No l10n or<br />
nightlies for now. Similar to [[ReleaseEngineering/TryServer|TryServer]] but for longer, and just for '''you'''. Unlike Try, the commit level on these branches is '''level_2 (and above) contributors only''' so please bear that in mind.<br />
<br />
===Do you need a disposable branch?===<br />
Ask yourself the following:<br />
<br />
'''Does your project have an end date?'''<br />
<br />
If your answer is '''No''' then you should follow the process at [https://wiki.mozilla.org/ReleaseEngineering:ProjectBranchPlanning Project Branch Planning]<br />
<br />
<br />
If your project is a temporary feature sprint that needs its own rapid test coverage but will eventually be merged into mozilla-central and no longer be on its own by all means, please go ahead and <br />
<br />
===Book one of our fabulous "disposable" project branches===<br />
'''''NOTE:''''' The number of disposable branches is limited by CI capacity. If there are no available branches, contact the owners of existing branches to see if you can "sub let".<br />
<br />
* Sign up below in the [[#BOOKING_SCHEDULE|BOOKING SCHEDULE]]<br />
* Make a [https://bugzilla.mozilla.org/enter_bug.cgi?product=Developer%20Services&component=Mercurial:%20hg.mozilla.org&short_desc=Requesting%20twig%20repo%20{booked_repo}%20be%20reset&comment=Please%20run%20the%20{script_name}%20and%20reset%20{booked_repo}%20to%20{url}&cc=buildduty@releng.bugs request] (example: {{bug|951811}}) to IT to reset the repo for you as a clone from your own project repo (or default mozilla-central:tip). '''Copy the script below into bug request, replacing the REPO_PATH and TWIG with your repo and booked branch'''.<br />
<pre><br />
export REPO_PATH=[path to your repo] # eg: users/lsblakk_mozilla.com/staging or comm-central<br />
export TWIG=[alder|birch|cedar|holly|larch|maple] # whichever twig you booked<br />
<br />
cd /repo/hg/scripts/<br />
./reset_pp_repo.sh -s /repo/hg/mozilla/$REPO_PATH -r tip -d $TWIG<br />
</pre><br />
* '''NOTE''': Coordinate with IT when this repo gets reset to push immediately without hitting the webheads. Otherwise, the permissions won't be set correctly.<br />
* '''NOTE''': Your repository will have no hooks enabled after a reset. You'll need to specify in the request if you need any configured.<br />
* Sit back and watch your builds and test results roll in (eg [http://tbpl.mozilla.org/?tree=Alder Alder], [http://tbpl.mozilla.org/?tree=Birch Birch], [http://tbpl.mozilla.org/?tree=Cedar Cedar],[http://tbpl.mozilla.org/?tree=Holly Holly], [http://tbpl.mozilla.org/?tree=Larch Larch], [http://tbpl.mozilla.org/?tree=Maple Maple]). <br />
* '''Special note:''' the first push to your newly cloned repo may not trigger builds if the repo had been pushed to previously, which is {{bug|774862}}. If it does not, please re-open the bug and move it to Release Engineering :: General Automation with a comment 'Please reconfigure the build scheduler'.<br />
<br />
<div id="unbook"></div><br />
<br />
===When you're done with one of our fabulous "disposable" project branches===<br />
<br />
Simply clear your data (bug, contact, dates) from the [[#BOOKING_SCHEDULE|BOOKING SCHEDULE]] below. If someone is listed in the "Next in Line" column, please let them know you are done.<br />
<br />
That's all there is to it!<br />
<br />
== Using a custom mozconfig ==<br />
<br />
The mozconfigs used for builds live in the same source tree as the main code, eg<br />
* Firefox: <tt>browser/config/mozconfigs/<platform></tt><br />
* Mobile Native: <tt>mobile/android/config/mozconfigs/android</tt><br />
* Mobile XUL: <tt>mobile/xul/config/mozconfigs/android-xul</tt><br />
<br />
The 'nightly' file is used for optimised builds, 'debug' for debug. If you are unsure which file you need consult a build log to see which is used. You can adjust these as needed on your branch, and they will be carried over to mozilla-central when you merge back. Please take care with any mozconfig changes you merge back (eg exclude local conveniences).<br />
<br />
==Enabling/Disabling of platforms, tests, nightly updates ==<br />
If the specific builds/tests you want are not enabled, or if there are builds/tests which you do not need on your branch, ask RelEng to enable/disable them by filing a bug [https://bugzilla.mozilla.org/enter_bug.cgi?product=Release%20Engineering here].<br />
<br />
Nightly builds and updates are disabled by default but can be enabled on request.<br />
<br />
== BOOKING SCHEDULE ==<br />
<br />
{| class="data wikitable"<br />
|-<br />
! Project Branch<br />
! Regist. bug<br />
! email address of borrower<br />
! User/Dev Team contact <br />
! Booking Dates <br />
! Next in Line<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=alder Alder]<br />
| <br />
| bhearsum@mozilla.com<br />
| <br />
| <br />
| <br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=ash Ash]<br />
| <br />
| nthomas@mozilla.com<br />
| <br />
| 2015-06-01 - TBD<br />
|<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=cypress Cypress]<br />
| <br />
| sicking@mozilla.com<br />
| :sicking, FlyWeb platform feature<br />
| 2015-12-15 - 2016-06-30<br />
|<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=date Date]<br />
| {{bug|1118796}}<br />
| nthomas@mozilla.com<br />
| Release automation changes<br />
| 2015-01-11 - 2015-03-31<br />
|<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=elm Elm]<br />
| {{bug|627699}}<br />
| glandium@mozilla.com<br />
| Gtk+3 work<br />
| 2014-06-19 - ??? '''''<span color="yellow">PENDING</span>'''''<br />
| -<br />
|-<br />
| <strike>[https://treeherder.mozilla.org/#/jobs?repo=fig Fig]</strike><br />
| retired<br />
| retired<br />
| retired<br />
| retired<br />
| retired<br />
|-<br />
| <strike>[https://treeherder.mozilla.org/#/jobs?repo=gum Gum]</strike><br />
| retired<br />
| retired<br />
| retired<br />
| retired<br />
| retired<br />
|-<br />
| <strike>[https://treeherder.mozilla.org/#/jobs?repo=holly Holly]</strike><br />
| retired<br />
| retired<br />
| retired<br />
| retired<br />
| retired<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=jamun Jamun]<br />
| {{bug|1147314}}<br />
| kechang@mozilla.com, kchen@mozilla.com<br />
| Nested OOP<br />
| 2015-03-25 - 2015-12-31<br />
| <br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=larch Larch]<br />
| -<br />
| fabrice@mozilla.com<br />
| Project Graphene<br />
| '''''<span color="yellow">PENDING</span>'''''<br />
| <br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=oak Oak]<br />
| {{bug|790467}} and other risky updater work<br />
| spohl@mozilla.com, rstrong@mozilla.com<br />
| spohl, rstrong<br />
| 2012-09-11 - 2015-12-31 '''''<span color="yellow">PENDING</span>'''''<br />
| -<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=pine Pine]<br />
| {{bug|929203}}<br />
| jgriffin@mozilla.com<br />
| :gwagner, debug B2G builds and unit tests<br />
| 2013-10-21 - indefinite '''''<span color="yellow">PENDING</span>'''''<br />
| -<br />
|}<br />
<br />
Be sure to keep a copy of anything you need from the repo prior to [[#unbook|unbooking]] it.<br />
<br />
== Indefinite booking ==<br />
See also [[ReleaseEngineering/SpecialBranches]] for more info on these branches.<br />
{| class="data"<br />
|-<br />
! Project Branch<br />
! Regist. bug<br />
! email address of borrower<br />
! User/Dev Team contact <br />
! Booking Dates <br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=birch Birch]<br />
| {{bug|1010674}}<br />
| catlee@mozilla.com<br />
| disabled<br />
| 2014-05-15 - indefinite '''''<span color="yellow">PENDING</span>'''''<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=cedar Cedar]<br />
| -<br />
| jgriffin@mozilla.com<br />
| new build/test testing for #ateam and #releng<br />
| 2012-06-25 - indefinite '''''<span color="yellow">PENDING</span>'''''<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=maple Maple]<br />
| -<br />
| catlee@mozilla.com<br />
| disabled<br />
| -<br />
| -<br />
|}</div>Sickinghttps://wiki.mozilla.org/index.php?title=WebOfThings/WorkshopSep2015&diff=1096400WebOfThings/WorkshopSep20152015-09-21T18:20:44Z<p>Sicking: Added more detail to "Areas of opportunity identified"</p>
<hr />
<div>Summary<br />
<br />
* Teams present: Firefox OS, Developer Relations, Product Marketing, Research & Insights, Mozilla Japan, Mozilla Taiwan<br />
* Goals: Identify the diverse efforts related to IoT at Mozilla, share project status, understand role of Web in IoT, identify opportunities, define the principles driving our activity.<br />
* Project wiki: https://wiki.mozilla.org/WebOfThings<br />
* Agenda: https://docs.google.com/presentation/d/1PYYlt5zVdcbA4Gjs-vQbUcke9-rtB0WRyLHxZQMvHTU/edit#slide=id.p<br />
* Full notes: https://docs.google.com/document/d/14IAshSiqqnFpXGeUYDDNh6zrxrj0h3mL-EYrB5pUPss/edit?usp=sharing<br />
* Presentations<br />
** WebEverywhere: https://drive.google.com/a/mozilla.com/file/d/0B1S9RuMdOMpcckdIc0dTeFpYYTg/view?usp=sharing<br />
** Accessing Arduino from the Web, Eddie Lin: https://docs.google.com/presentation/d/1m13AJJHnwDprZw6LFNZLG1deOCRgE4mnjM9EZI2RgpY/edit#slide=id.p<br />
** WoT Toolkit/Workshop for beginners, Daisuke: https://docs.google.com/presentation/d/15GAv_1O3hOKaLMM0i2zh2hB_WDzk4dHtRBi9E_RQ73k/edit<br />
* Summary of Findings<br />
** Currently active projects are bridging the Web platform and popular microcontrollers, Firefox OS developer boards, device-to-device interaction and content delivery, connecting the Web to fabrication tools.<br />
** Areas of opportunity identified:<br />
*** Lowering barrier to entry for developers, makers and hardware vendors.<br />
*** Standardization on existing trusted infrastructure.<br />
*** Bridging maker and Web developer communities.<br />
*** Allowing web-based identity providers (facebook, google, Firefox Accounts) to handle logins to IoT devices. <br />
*** Reduce app exhaustion by enabling IoT to work through the browser rather than require dedicated app.<br />
*** Using education and advocacy to influence consumers/industry/government behavior.<br />
*** Service and data management.<br />
*** There’s no clear pathway from hobby/maker/DIY development and productization/scale.<br />
** Challenges identified: Early/large movers pushing verticalization for consumers, Mozilla has no established credibility in IoT, difficult to conceptually bridge Web technologies with local/direct device interaction and development, no over-arching theme in Mozilla’s current activity, the categories of activity are extremely diverse (maker vs consumer products vs enterprise/industrial).<br />
** Manifesto principles #4, #5 and #6 are relevant to IoT. They should inform our product designs, and can be differentiators.<br />
* Projects<br />
** Chirimen: https://github.com/MozOpenHard/CHIRIMEN<br />
** FlyWeb: https://wiki.mozilla.org/FlyWeb<br />
** wot.js - http://wotjs.io/<br />
** serialport-io: Use socket.io to proxy the Web to a serial port, https://github.com/elin-moco/serialport-io<br />
** ble-serialport: Use Bluetooth LE to proxy the Web to a serial port, https://github.com/elin-moco/ble-serialport<br />
** wot-daemon: Helper for desktop dev, https://github.com/elin-moco/wot-daemon<br />
** chrome-app-api-proxy: Call Chrome App APIs from a Webpage, https://github.com/wotjs/chrome-app-api-proxy<br />
** chrome-usb-serialport: A serialport module for Google Chrome browser, https://github.com/wotjs/chrome-usb-serialport<br />
** browserify-johnny-five: Build Johnny Five as a browserify module, https://github.com/wotjs/browserify-johnny-five<br />
** BlueYeast: A wrapper for BLE APIs in FxOS, https://github.com/evanxd/blue-yeast<br />
* Upcoming event opportunities for demos, meetings, development<br />
** W3C TPAC, Oct 26-30, Sapporo, http://www.w3.org/2015/10/TPAC/<br />
** View Source, Nov 2-4, Portland, https://viewsourceconf.org/<br />
** MozFest, Nov 6-8, London, https://2015.mozillafestival.org/<br />
** Mozlando, Dev 7-11, Orlando<br />
** MWC 2016, late February<br />
* How to Participate<br />
** Join on Slack: https://webofthings.slack.com/<br />
** Join on IRC: #wot, #flyweb<br />
** Wiki: https://wiki.mozilla.org/WebOfThings<br />
* Misc Links<br />
** FlyWeb use-cases: https://docs.google.com/document/d/1zAhvJJhH2kxvQ3Qo-qlts1nToCZHMTn6av5VCAesJHI/edit</div>Sickinghttps://wiki.mozilla.org/index.php?title=FirefoxOS/TestingInfrastructureImprovements&diff=1090748FirefoxOS/TestingInfrastructureImprovements2015-08-19T07:07:04Z<p>Sicking: Sicking moved page FirefoxOS/TestingInfrastructureHitList to FirefoxOS/TestingInfrastructureImprovements</p>
<hr />
<div><br />
== Meeting notes Aug 17 ==<br />
<br />
=== Marionette JS vs. Python ===<br />
<br />
Original MarionetteJS duplicated a lot of the python infrastructure. Including parts that we've worked a long time on to stabilize and get running smoothly. Since then work has been done to make MarionetteJS reuse more of the existing python-based infrastructure.<br />
<br />
However there's more to be done. MarionetteJS tests can almost run on-device, but only python tests are able to run in the twice-daily QA automation. We also can't extract crash dump from MarionetteJS test failures, nor gecko logs or screenshots.<br />
<br />
'''Action Items'''<br />
* Stand up MarionetteJS to run in the existing twice-daily automation.<br />
* Enable turning on MarionetteJS tests only on specific platforms (on-device vs. emulator vs. Mulet)<br />
* Try running a few MarionetteJS tests in the twice-daily automation and weed out stability issues.<br />
<br />
=== Mach integration ===<br />
<br />
It is currently very hard for non-FirefoxOS mozilla developers to locally get all dependencies and run our test suites. This is needed in order to help non-FirefoxOS mozilla developers to fix any test failures and regressions that they cause in FirefoxOS.<br />
<br />
For Firefox desktop and Fennec we use mach to solve some of these problems. We should potentially look into integrating with that. However we didn't end up having time to get into enough details here, and it seemed lower priority for now.<br />
<br />
No action items for now.<br />
<br />
== Meeting notes July 28 ==<br />
<br />
=== Intermittent failures ===<br />
<br />
We still have problems with intermittent failures. In particular, we still have a few infrastructure issues which is causing intermittent failures in *all* Gij tests.<br />
<br />
Some of these infrastructure issues are due to known problems that are being worked on, Aus is on top of that. But the big one is that we still have a problem with the socket connection randomly disconnecting. This is a really tough problem and people have worked on it for years with no progress.<br />
<br />
These intermittent issues are somewhat less of a problem because we now run tests three times and only if all three fail will we consider it a failure. Unfortunately this means that bugs in our product which only happen intermittently are no longer caught.<br />
<br />
We also have some intermittent issues in individual tests, but unclear how much. One proposed solution was to write helper functions which help with writing stable tests. The "Page object pattern" used by calendar tests were pointed out as a good example.<br />
<br />
'''Action items'''<br />
* Fix the known causes of infrastructure issues (Aus is already working on this).<br />
* Catch the socket disconnect issue in rr.<br />
<br />
<br />
=== Get more info when a test fails ===<br />
<br />
When a test fails, we would like to collect<br />
<br />
Gecko log (bug 1188648)<br />
Error stack<br />
Screen shot<br />
crash dump in case of crashes<br />
<br />
'''Action items'''<br />
* Add the above to Gij infrastructure<br />
<br />
<br />
=== Which platforms do we want to maintain ===<br />
<br />
We currently have too many development platforms: mulet/gaia-in-nightly/b2g-desktop/simulator/emulator-ICS/emulator-L/B2GDroid/on-device.<br />
<br />
We should narrow it down to: Mulet, Emulator-L, B2GDroid (not yet ready), and on-device.<br />
<br />
B2G-desktop, gaia-in-nightly and simulator should be removed from the tree and from test automation. But first we need to make sure that all tests that are currently running on B2G-desktop are also running in Mulet.<br />
<br />
We also want to kill |DEBUG=1 make|. But first we need to improve the "shift-f5 reload" development flow. Possibly by hooking it in to a super-fast rebuild step.<br />
<br />
'''Action items'''<br />
* Ensure that all tests that are run in B2G-desktop is also run in Mulet (Lissy is working on it)<br />
* Kill B2G-desktop, gaia-in-nightly and simulator<br />
* Stand up Emulator-L (Hsin-Yi is working on it)<br />
* Figure out how to make "shift-f5 reload" work (Tim is thinking about this, no one is working on this yet)<br />
<br />
<br />
=== What tests do we need to run on-device/in emulator ===<br />
<br />
Running on emulator is really slow. In part because of arm. In part because we restart emulator. We would like to run most tests in emulator (except unit tests). However we need Emulator-x86 for that to be viable.<br />
<br />
We have tests for Bluetooth/RIL/Wifi/NFC which run on emulator, but they are not reporting to treeherder because we only have emulator-ics on treeherder and it doesn't support those features.<br />
<br />
We are running perf tests on-device, but no one knew if they are reporting to raptor.<br />
<br />
'''Action items'''<br />
* Stand up Emulator-x86 and Emulator-L on treeherder.<br />
* Enable Bluetooth/RIL/Wifi/NFC tests on treeherder.<br />
* Make sure perf tests that are running on hardware report to raptor.</div>Sickinghttps://wiki.mozilla.org/index.php?title=FirefoxOS/TestingInfrastructureHitList&diff=1090749FirefoxOS/TestingInfrastructureHitList2015-08-19T07:07:04Z<p>Sicking: Sicking moved page FirefoxOS/TestingInfrastructureHitList to FirefoxOS/TestingInfrastructureImprovements</p>
<hr />
<div>#REDIRECT [[FirefoxOS/TestingInfrastructureImprovements]]</div>Sickinghttps://wiki.mozilla.org/index.php?title=FirefoxOS/TestingInfrastructureImprovements&diff=1090747FirefoxOS/TestingInfrastructureImprovements2015-08-19T07:05:33Z<p>Sicking: Meeting notes Aug 17</p>
<hr />
<div><br />
== Meeting notes Aug 17 ==<br />
<br />
=== Marionette JS vs. Python ===<br />
<br />
Original MarionetteJS duplicated a lot of the python infrastructure. Including parts that we've worked a long time on to stabilize and get running smoothly. Since then work has been done to make MarionetteJS reuse more of the existing python-based infrastructure.<br />
<br />
However there's more to be done. MarionetteJS tests can almost run on-device, but only python tests are able to run in the twice-daily QA automation. We also can't extract crash dump from MarionetteJS test failures, nor gecko logs or screenshots.<br />
<br />
'''Action Items'''<br />
* Stand up MarionetteJS to run in the existing twice-daily automation.<br />
* Enable turning on MarionetteJS tests only on specific platforms (on-device vs. emulator vs. Mulet)<br />
* Try running a few MarionetteJS tests in the twice-daily automation and weed out stability issues.<br />
<br />
=== Mach integration ===<br />
<br />
It is currently very hard for non-FirefoxOS mozilla developers to locally get all dependencies and run our test suites. This is needed in order to help non-FirefoxOS mozilla developers to fix any test failures and regressions that they cause in FirefoxOS.<br />
<br />
For Firefox desktop and Fennec we use mach to solve some of these problems. We should potentially look into integrating with that. However we didn't end up having time to get into enough details here, and it seemed lower priority for now.<br />
<br />
No action items for now.<br />
<br />
== Meeting notes July 28 ==<br />
<br />
=== Intermittent failures ===<br />
<br />
We still have problems with intermittent failures. In particular, we still have a few infrastructure issues which is causing intermittent failures in *all* Gij tests.<br />
<br />
Some of these infrastructure issues are due to known problems that are being worked on, Aus is on top of that. But the big one is that we still have a problem with the socket connection randomly disconnecting. This is a really tough problem and people have worked on it for years with no progress.<br />
<br />
These intermittent issues are somewhat less of a problem because we now run tests three times and only if all three fail will we consider it a failure. Unfortunately this means that bugs in our product which only happen intermittently are no longer caught.<br />
<br />
We also have some intermittent issues in individual tests, but unclear how much. One proposed solution was to write helper functions which help with writing stable tests. The "Page object pattern" used by calendar tests were pointed out as a good example.<br />
<br />
'''Action items'''<br />
* Fix the known causes of infrastructure issues (Aus is already working on this).<br />
* Catch the socket disconnect issue in rr.<br />
<br />
<br />
=== Get more info when a test fails ===<br />
<br />
When a test fails, we would like to collect<br />
<br />
Gecko log (bug 1188648)<br />
Error stack<br />
Screen shot<br />
crash dump in case of crashes<br />
<br />
'''Action items'''<br />
* Add the above to Gij infrastructure<br />
<br />
<br />
=== Which platforms do we want to maintain ===<br />
<br />
We currently have too many development platforms: mulet/gaia-in-nightly/b2g-desktop/simulator/emulator-ICS/emulator-L/B2GDroid/on-device.<br />
<br />
We should narrow it down to: Mulet, Emulator-L, B2GDroid (not yet ready), and on-device.<br />
<br />
B2G-desktop, gaia-in-nightly and simulator should be removed from the tree and from test automation. But first we need to make sure that all tests that are currently running on B2G-desktop are also running in Mulet.<br />
<br />
We also want to kill |DEBUG=1 make|. But first we need to improve the "shift-f5 reload" development flow. Possibly by hooking it in to a super-fast rebuild step.<br />
<br />
'''Action items'''<br />
* Ensure that all tests that are run in B2G-desktop is also run in Mulet (Lissy is working on it)<br />
* Kill B2G-desktop, gaia-in-nightly and simulator<br />
* Stand up Emulator-L (Hsin-Yi is working on it)<br />
* Figure out how to make "shift-f5 reload" work (Tim is thinking about this, no one is working on this yet)<br />
<br />
<br />
=== What tests do we need to run on-device/in emulator ===<br />
<br />
Running on emulator is really slow. In part because of arm. In part because we restart emulator. We would like to run most tests in emulator (except unit tests). However we need Emulator-x86 for that to be viable.<br />
<br />
We have tests for Bluetooth/RIL/Wifi/NFC which run on emulator, but they are not reporting to treeherder because we only have emulator-ics on treeherder and it doesn't support those features.<br />
<br />
We are running perf tests on-device, but no one knew if they are reporting to raptor.<br />
<br />
'''Action items'''<br />
* Stand up Emulator-x86 and Emulator-L on treeherder.<br />
* Enable Bluetooth/RIL/Wifi/NFC tests on treeherder.<br />
* Make sure perf tests that are running on hardware report to raptor.</div>Sickinghttps://wiki.mozilla.org/index.php?title=FirefoxOS/TestingInfrastructureImprovements&diff=1090726FirefoxOS/TestingInfrastructureImprovements2015-08-19T00:31:56Z<p>Sicking: Meeting notes July 28</p>
<hr />
<div><br />
== Meeting notes July 28 ==<br />
<br />
=== Intermittent failures ===<br />
<br />
We still have problems with intermittent failures. In particular, we still have a few infrastructure issues which is causing intermittent failures in *all* Gij tests.<br />
<br />
Some of these infrastructure issues are due to known problems that are being worked on, Aus is on top of that. But the big one is that we still have a problem with the socket connection randomly disconnecting. This is a really tough problem and people have worked on it for years with no progress.<br />
<br />
These intermittent issues are somewhat less of a problem because we now run tests three times and only if all three fail will we consider it a failure. Unfortunately this means that bugs in our product which only happen intermittently are no longer caught.<br />
<br />
We also have some intermittent issues in individual tests, but unclear how much. One proposed solution was to write helper functions which help with writing stable tests. The "Page object pattern" used by calendar tests were pointed out as a good example.<br />
<br />
'''Action items'''<br />
* Fix the known causes of infrastructure issues (Aus is already working on this).<br />
* Catch the socket disconnect issue in rr.<br />
<br />
<br />
=== Get more info when a test fails ===<br />
<br />
When a test fails, we would like to collect<br />
<br />
Gecko log (bug 1188648)<br />
Error stack<br />
Screen shot<br />
crash dump in case of crashes<br />
<br />
'''Action items'''<br />
* Add the above to Gij infrastructure<br />
<br />
<br />
=== Which platforms do we want to maintain ===<br />
<br />
We currently have too many development platforms: mulet/gaia-in-nightly/b2g-desktop/simulator/emulator-ICS/emulator-L/B2GDroid/on-device.<br />
<br />
We should narrow it down to: Mulet, Emulator-L, B2GDroid (not yet ready), and on-device.<br />
<br />
B2G-desktop, gaia-in-nightly and simulator should be removed from the tree and from test automation. But first we need to make sure that all tests that are currently running on B2G-desktop are also running in Mulet.<br />
<br />
We also want to kill |DEBUG=1 make|. But first we need to improve the "shift-f5 reload" development flow. Possibly by hooking it in to a super-fast rebuild step.<br />
<br />
'''Action items'''<br />
* Ensure that all tests that are run in B2G-desktop is also run in Mulet (Lissy is working on it)<br />
* Kill B2G-desktop, gaia-in-nightly and simulator<br />
* Stand up Emulator-L (Hsin-Yi is working on it)<br />
* Figure out how to make "shift-f5 reload" work (Tim is thinking about this, no one is working on this yet)<br />
<br />
<br />
=== What tests do we need to run on-device/in emulator ===<br />
<br />
Running on emulator is really slow. In part because of arm. In part because we restart emulator. We would like to run most tests in emulator (except unit tests). However we need Emulator-x86 for that to be viable.<br />
<br />
We have tests for Bluetooth/RIL/Wifi/NFC which run on emulator, but they are not reporting to treeherder because we only have emulator-ics on treeherder and it doesn't support those features.<br />
<br />
We are running perf tests on-device, but no one knew if they are reporting to raptor.<br />
<br />
'''Action items'''<br />
* Stand up Emulator-x86 and Emulator-L on treeherder.<br />
* Enable Bluetooth/RIL/Wifi/NFC tests on treeherder.<br />
* Make sure perf tests that are running on hardware report to raptor.</div>Sickinghttps://wiki.mozilla.org/index.php?title=WebExtensions&diff=1089031WebExtensions2015-08-07T21:54:25Z<p>Sicking: /* Packaging */</p>
<hr />
<div>This page is an introduction to Mozilla's implementation of WebExtensions, a new browser extension API. The goals of this API are:<br />
* It should be easier to use.<br />
* It must be compatible with multiprocess Firefox ([[Electrolysis]]).<br />
* Porting add-ons to and from other browsers should be easier.<br />
* Changes to Firefox's internal code should be less likely to break add-ons.<br />
* It should be easier to review add-ons to reduce the backlog on addons.mozilla.org.<br />
<br />
Much of the specifics of the new API are similar to the Blink extension API. Google has [https://developer.chrome.com/extensions extensive documentation on the API]. [https://dev.opera.com/extensions/ So does Opera].<br />
<br />
We hope to ship a preliminary version of this API in Firefox 42.<br />
<br />
== Packaging ==<br />
<br />
At this point it's difficult to experiment with the API because extensions cannot be installed directly. [https://bugzilla.mozilla.org/show_bug.cgi?id=1190692 Bug 1190692] tracks the work to make it possible to install them using the add-on manager. The only way WebExtensions can be installed right now is to package them into XPIs via [http://mxr.mozilla.org/mozilla-central/source/browser/components/extensions/prepare.py a Python script]. This script generates install.rdf and bootstrap.js files. It can then be zipped into an .xpi and installed using the add-on manager.<br />
<br />
In the future, we're planning to use the .zip file extension. All of the data currently in install.rdf will be moved to the manifest.json file. Will will not use install.rdf or bootstrap.js. Extensions will be signed using JAR signing (the same as we do for existing Firefox add-ons).<br />
<br />
See https://developer.chrome.com/extensions/manifest for a complete list of manifest directives. The ones we currently support are below.<br />
<br />
* name<br />
* version<br />
* description<br />
* content_scripts<br />
* permissions<br />
* web_accessible_resources<br />
* background<br />
* browser_action<br />
* default_locale<br />
<br />
In addition, we plan to add the following section '''Didn't we decide not to do this?''':<br />
<br />
<blockquote><pre><br />
"applications": {<br />
"gecko": {<br />
"id": "{the-addon-id}",<br />
"strict_min_version": "40.0.0",<br />
"strict_max_version": "50.*"<br />
"update_url": "https://foo/bar"<br />
}<br />
}<br />
</pre></blockquote><br />
<br />
Both versions will be Gecko rapid release versions. The update URL points to an [https://developer.mozilla.org/en-US/docs/Extension_Versioning,_Update_and_Compatibility#Update_RDF_Format update manifest]. We hope to make all of these properties optional. The id would have to be generated fresh either upon local installation or when uploaded to addons.mozilla.org or Marketplace.<br />
<br />
== List of supported APIs ==<br />
<br />
Note that we expect to fix virtually all of the exceptions printed below.<br />
<br />
* [https://developer.chrome.com/extensions/alarms alarms]<br />
** This API is entirely supported.<br />
<br />
* [https://developer.chrome.com/extensions/browserAction browserAction]<br />
** We don't support the imageData attribute on setIcon.<br />
** We don't support enable or disable.<br />
<br />
* [https://developer.chrome.com/extensions/extension extension]<br />
** We support only getBackgroundPage and getURL.<br />
<br />
* [https://developer.chrome.com/extensions/i18n i18n]<br />
** We support only getMessage in the JavaScript API.<br />
** We only support @@extension_id and @@ui_locale predefined messages.<br />
** We don't localize CSS files.<br />
** Strings to be localized must consist entirely of __MSG_foo__ in order for a substitution to be made.<br />
<br />
* [https://developer.chrome.com/extensions/notifications notifications]<br />
** The only supported notification options are iconUrl, title, and message.<br />
** The only methods we support are create, clear, and getAll.<br />
** The only event we support is onClosed. We don't provide byUser data.<br />
<br />
* [https://developer.chrome.com/extensions/runtime runtime]<br />
** We support onStartup, getManifest, id, and the message passing interfaces (sendMessage, onMessage, onConnect).<br />
<br />
* [https://developer.chrome.com/extensions/storage storage]<br />
** The only storage area we support is local.<br />
** We don't support getBytesInUse or clear.<br />
<br />
* [https://developer.chrome.com/extensions/tabs tabs]<br />
** Unsupported functions: getCurrent, sendRequest, getSelected, duplicate, highlight, move, detectLanguage, captureVisibleTab, get/setZoom, get/setZoomSettings. We probably will never support detectLanguage or captureVisibleTab.<br />
** We treat highlighted and active as effectively the same since Firefox cannot select multiple tabs.<br />
<br />
* [https://developer.chrome.com/extensions/webNavigation webNavigation]<br />
** We don't support getFrame or getAllFrames.<br />
** We don't support onCreatedNavigationTarget or onHistoryStateUpdated.<br />
** We don't support transition types and qualifiers.<br />
** onReferenceFragmentUpdated also triggers for pushState.<br />
** Filtering is unsupported.<br />
<br />
* [https://developer.chrome.com/extensions/webRequest webRequest]<br />
** We don't support handlerBehaviorChanged.<br />
** We don't support onAuthRequired, onBeforeRedirect, or onErrorOccurred.<br />
** Requests can be canceled only in onBeforeRequest.<br />
** Requests can be modified/redirected only in onBeforeSendHeaders.<br />
** Responses can be modified only in onHeadersReceived.<br />
<br />
* [https://developer.chrome.com/extensions/windows windows]<br />
** onFocusChanged will trigger multiple times for a given focus change.<br />
** create does not support the focused, type, or state options.<br />
** update only supports the focused option.<br />
<br />
== List of APIs we will likely support in the future ==<br />
<br />
* [https://developer.chrome.com/extensions/bookmarks bookmarks]<br />
* [https://developer.chrome.com/extensions/commands commands]<br />
* [https://developer.chrome.com/extensions/contextMenus contextMenus]<br />
* [https://developer.chrome.com/extensions/cookies cookies]<br />
* [https://developer.chrome.com/extensions/downloads downloads]<br />
* [https://developer.chrome.com/extensions/history history]<br />
* [https://developer.chrome.com/extensions/idle idle]<br />
* [https://developer.chrome.com/extensions/omnibox omnibox]<br />
* [https://developer.chrome.com/extensions/pageAction pageAction]<br />
* [https://developer.chrome.com/extensions/permissions permissions]<br />
<br />
== Technical details ==<br />
<br />
We currently enforce Chrome's permission model. However, we don't yet support the activeTab permission. We also don't enforce the CSP protections at all. Support for that is planned.<br />
<br />
WebExtensions run in the main Firefox process (except for content scripts, which run in the same process as web content). We are planning to run extensions in a separate process (or possibly the content process) eventually.<br />
<br />
== Additional APIs ==<br />
<br />
We plan to add our own APIs based on the needs of existing Firefox add-ons.<br />
<br />
* NoScript-type functionality. This would come in the form of extensions to webRequest and possibly contentSettings.<br />
* Sidebars. Opera already supports sidebar functionality; Chrome may soon. We would like to be able to implement Tree Style Tabs or Vertical Tabs by hiding the tab strip and showing a tab sidebar.<br />
* Toolbars. Firefox has a lot of existing toolbar add-ons.<br />
* Better keyboard shortcut support. We'd like to support Vimperator-type functionality.<br />
* Ability to add tabs to about:addons.<br />
* Ability to modify the tab strip (Tab Mix Plus).</div>Sickinghttps://wiki.mozilla.org/index.php?title=FirefoxOS/New_security_model&diff=1087212FirefoxOS/New security model2015-07-29T23:27:17Z<p>Sicking: Document the OriginAttributes solution</p>
<hr />
<div>== Goals ==<br />
<br />
* Enable exposing "sensitive APIs" to 3rd party developers.<br />
* Use the same update and security model for gaia and for 3rd party content.<br />
* Don't require content which uses "senstivie APIs" to be installed. Users should be able to simply browse to it.<br />
* Don't have separate cookie jars for separate apps. At least for normal content which doesn't use "sensitive APIs".<br />
* Ensure that content which uses "sensitive APIs" always runs in a separate process. Enforce in the parent process that only these separate processes can trigger "sensitive APIs". I.e. hacking a child process should not permit access to more sensitive APIs.<br />
* Enable content which uses "sensitive APIs" to have normal http(s) URLs such that they can use OAuth providers like facebook.<br />
* Enable content which uses "sensitive APIs" to use service workers.<br />
<br />
"Sensitive APIs" here means APIs that we have not figured out how to safely expose to normal web pages. About 5-10% of the content in our marketplace falls into this category, and none of the content on the rest of the web fall into this category. I.e. most content does not use sensitive APIs, and can and should remain as normal websites.<br />
<br />
<br />
==New Security Model==<br />
<br />
=== Signing - {{Bug|1153420}}===<br />
We will require that all content which uses "sensitive APIs" is signed. For now only the firefox marketplace will be allowed to do the signing. Possibly this will be changed in the future, but that's likely more a policy change than a code change.<br />
<br />
Signing is done by having the developer package the content into a package and submit it to the mozilla marketplace. The marketplace will review the app and then add a signature to the package. The developer can then download the signed package and upload to the developer's website.<br />
<br />
♦ '''Issue:''' Should we allow other forms manual review of each app? Can the marketplace "review a developer" and give the developer access to automatic signing?<br />
<br />
The format used for the packaging will be the one defined in the [https://github.com/w3ctag/packaging-on-the-web W3C packaging spec draft]. A header is added to the package to indicate that it's a signed package. The advantage of this packaging format, compared to zip, is that it's streamable.<br />
<br />
The format used for the signature is still to be determined, but hopefully we can use the same file formats and file names as used today. However it's important that the signatures also cover the header data for each resource, as well as the header data for the package itself.<br />
<br />
♦ '''Issue:''' Decide on exact signature format. Should we require that the signature-files live at the start of the package. That way we'd always have the signature available before the file contents covered by the signature.<br />
<br />
=== Verifying signatures - {{Bug|1153422}} ===<br />
To load a webpage in a signed package, the user navigates to a URL like "https://website.com/RSSReader2000/package.pak!//index.html". The part before the "!//" is the URL to the package itself. The part after the "!//" is the resource path inside the package.<br />
<br />
So loading signed content does not require an installation to happen. Simply navigating to a URL like the above is enough.<br />
<br />
When the user navigates to such a page, Gecko will download the package from the webserver. Gecko will then see in the header of the package that the package is signed.<br />
<br />
Before serving any resources from the package to the rest of Gecko, the network layer will first wait for the signatures to be loaded from the package. It will also verify that the resource that is currently being loaded is covered by, and matches, the signature.<br />
<br />
We should likely cache which resources in the package that we've checked the signature of, so that we don't have to recheck if a resource is loaded multiple times.<br />
<br />
Another thing that needs to be done before any content is served by the network layer is to look in the manifest and populate the nsIPermissionManager database with any permissions enumerated in the manifest. After having checked that the manifest properly matches the signature of course.<br />
<br />
=== CSP - {{Bug|1153423}} ===<br />
We need to make sure that it can't load scripts from outside of the signed package. And we need to make sure that it can't use inline scripts.<br />
<br />
The plan is to use the CSP code to accomplish this. We can mainly leverage existing code which enables applying a default CSP policy to certain content. We'll use this to apply a default CSP to all signed content similarly to how we currently apply a default CSP to all privileged apps.<br />
<br />
We'll also need to extend it to enable it to enforce loads to happen "from same package", rather than just "from same origin".<br />
<br />
<br />
We also can't allow signed content to be opened in an <iframe>, other than by pages from the same signed package. This is partially to prevent signed content from getting clickjacked. However it's also because we want to always open signed content in a separate OS process, and currently gecko does not support out-of-process plain <iframe>s.<br />
<br />
Hopefully this is a restriction we can eventually relax, for example by allowing pages in a signed package to opt in to being iframe-able. But this will require out-of-process <iframe>s and so will have to wait.<br />
<br />
=== Process isolation - {{Bug|1153428}} ===<br />
<br />
In order to ensure that only signed content can access the APIs that it has been signed for, we want to always use separate child processes to run such content.<br />
<br />
This means that when a user navigates from an unsigned page to a signed page, that we need to switch which process render the pages. Right now this can only be done by creating a new <iframe mozbrowser>.<br />
<br />
However only Gecko knows that a particular URL is signed. Gaia could not simply look at a URL to know if it will return signed content or not. And Gecko only knows that it's signed content once response data starts arriving.<br />
<br />
Even if we add some way for gecko to signal to the <iframe mozbrowser> embedder that a new <iframe mozbrowser> needs to be created, this will make going "back"/"forward" between the two very messy.<br />
<br />
We also need to change security checks that currently are done in the parent process. Currently many of them are heavily based on app-ids and installed apps. This may need to be changed.<br />
<br />
=== Installing and updating - {{Bug|1153432}} ===<br />
<br />
Issue: How can we register web activities when we pin a page. And update those registries when the pinned manifest is updated.<br />
<br />
<br />
Signed packages follow normal http semantics. I.e. if the package still exists in our http cache when the user revisits a signed page, but the cache headers indicate that the content needs to be updated, we do a normal GET request to see if a new version needs to be downloaded.<br />
<br />
If a new version of the package is being sent, we follow the same behavior as when visiting a package for the first time. I.e. we need to reverify signatures as well as update any permissions in the nsIPermissionManager database.<br />
<br />
However, we want to avoid having to download a whole package if just part of it has changed. In order to support that we hope to enable the server to respond to the GET request for an updated package with just a "diff" of what's changed between the previous and current version.<br />
<br />
One possible way to do this would be to have gecko indicate that it supports a new type of content encoding as well as send the etag of the current package file. The server can then look at the etag and if it has (or can generate) a diff between the clients version and the latest version, it can respond with a special content-encoding as well as the package diff.<br />
<br />
Gecko can then use the diff to patch the existing package.<br />
<br />
Note that sending a diff is entirely the server's choice. If the server doesn't support this newly created diff mechanism, then it will simply serve a full package. Likewise if the user is on a very old version which the server doesn't have a diff for or if the diff has bigger size than the resulting package, the server can simply serve a full package.<br />
<br />
In the case when a diff is received, it is probably fine to not support streaming package content. I.e. in that case its probably fine to wait for the full diff to be downloaded and applied, before returning any data from the Gecko network layer.<br />
<br />
We do in that case still need to verify signatures of the new package version.<br />
<br />
Installing a signed package mainly consists of pinning it in the http cache such that it doesn't get evicted. We still need to check for updates according to normal "app update" scheduling.<br />
<br />
=== Service Workers - {{Bug|1153433}} ===<br />
<br />
One of the central pieces of the new Gaia architecture is the use of service workers. This isn't just to support offline for gaia apps, but also to support dynamic generation of page markup, and the ability to run logic in order to decide what resource to return for a given URL.<br />
<br />
In order to make service workers work with the package update logic we should couple package update with service worker update. When the ServiceWorker spec require the browser to check for updates of, or download updates of, the ServiceWorker script, we instead update the full signed package.<br />
<br />
This means that both when we do an "automatic" ServiceWorker update check, such as when the user visit a page which uses the ServiceWorker, and when the ServiceWorkerRegistration.update() function is called, that we update the full package rather than just the ServiceWorker script.<br />
<br />
Once a new package has been downloaded, we go through the normal ServiceWorker update cycle. I.e. Gecko fire both "install" and "activate" events on the ServiceWorker. This will happen any time that a package is updated, even if the contents of the ServiceWorker script hasn't changed.<br />
<br />
Gecko need to still serve the previous package content until the "activate" event for the new ServiceWorker version fires. I.e. until the new version has been installed, the old version of the package needs to be served for any network requests.<br />
<br />
♦ '''Issue:''' How do we enable the newly installing serviceworker to load content from the new package version, even though the previous package version is the one pinned in the cache.<br />
<br />
♦ '''Issue:''' Does CSP allow putting limits on where serviceworkers can be loaded from? We need to restrict ServiceWorkers scopes as well as script-urls to be from inside the package.<br />
<br />
=== Origins and cookie jars - {{Bug|1153435}} ===<br />
The biggest change here is that we should stop always using different cookie jars for different apps. In particular normal unsigned content should always use the same cookie jar no matter where it was loaded.<br />
<br />
However signed packages will get their own cookies and IndexedDB data. Content inside a signed package will not share cookies, IndexedDB data, etc with unsigned content from the same domain. It will also not share data with content from other signed packages from the same domain. This is to ensure that unsigned content from the same domain can't read for example sensitive data that the signed content has cached in IndexedDB. And to prevent unsigned content from writing into the localStorage that signed content uses and thereby tricking the signed content into performing unintended actions.<br />
<br />
However when pages from inside a signed package makes network requests to other websites, it should still use the normal cookies from those websites. And if a page from a signed package creates an <iframe> containing an insigned website, then that website will be loaded with its normal cookies and will have access to its normal IndexedDB data.<br />
<br />
In other words, each signed package acts like a separate website. They do not act like a separate "world"/"context".<br />
<br />
The way that we will implement this is by generalizing the current <tt>appId</tt> and <tt>isInBrowserElement</tt> mechanism. We will introduce a <tt>OriginAttributes</tt> struct which will hold the "cookie jar" that is used for a given web page. We can then write policies for which parts of this struct is inherited into iframes, and which parts do not. The nsIPrincipal interface will contain one of these structs. We will also have functions for serializing this struct to a string, and for parsing such a string back into a struct.<br />
<br />
Most code will treat this OriginAttributes struct as an opaque value. When we store data we store as part of the key the serialization of the OriginAttributes.<br />
<br />
Two pages will only be considered same-origin if they have the same scheme+host+port, but also if all of the values inside the OriginAttributes of their nsIPrincipal have the exact same values.<br />
<br />
We will then add a 'signedPkg' member to OriginAttributes. When a page is loaded from inside a signed package, we will read a package-identifier from inside the package and set it in the OriginAttributes of the nsIPrincipal of the page.<br />
<br />
However, when we do the network request for the package itself, this is treated like other network requests to the webserver. I.e. the network request is considered as an unsigned request and so the normal cookies of the webserver is sent. We have to do it this way since when we fetch a signed package the first time, we don't know that the package is signed, and so we use the normal cookie jar for that domain.<br />
<br />
The effect of this is that when we are making network requests, these are never affected by package signing. As mentioned above, requests for the package itself are not affected, and requests for pages inside the package don't send any cookies at all since they are simply loaded from the package.<br />
<br />
However, when a page from a signed package access the document.cookies API, the cookies returned *do* use the full OriginAttributes. I.e. the document.cookies API is treated like other storage APIs like IndexedDB and localStorage.<br />
<br />
♦ '''Issue:''' Verify with Honza that this is is doable and not complex. It should hopefully be the most natural way to write the cookie code.<br />
<br />
If any page does a XHR request to a URL inside a signed package this is treated like any other network request and is permitted. This doesn't expose any user-private information and simply returns content that resides on the server.<br />
<br />
== Implementation ==<br />
* P1: Milestone 1 (Sept 4)<br />
* P2: Milestone 2 (Oct 2)<br />
* P3: Feature complete (Nov 2)<br />
* P4: Post-2.5 release<br />
<br />
=== Signing - {{Bug|1153420}}===<br />
<bugzilla><br />
{<br />
"blocks": 1153420,<br />
"resolution": "---",<br />
"include_fields": "id, priority, summary, status, assigned_to,resolution",<br />
"order": "bug_id "<br />
}<br />
</bugzilla><br />
<br />
=== Verifying signatures - {{Bug|1153422}} ===<br />
<bugzilla><br />
{<br />
"blocks": 1153422,<br />
"include_fields": "id, priority, summary, status, assigned_to,resolution",<br />
"order": "bug_id"<br />
}<br />
</bugzilla><br />
<br />
=== CSP - {{Bug|1153423}} ===<br />
<br />
<bugzilla><br />
{<br />
"blocks": 1153423,<br />
"include_fields": "id, priority, summary, status, assigned_to,resolution",<br />
"order": "bug_id"<br />
}<br />
</bugzilla><br />
<br />
=== Process isolation - {{Bug|1153428}} ===<br />
<br />
<bugzilla><br />
{<br />
"blocks": 1153428,<br />
"include_fields": "id, priority, summary, status, assigned_to,resolution",<br />
"order": "bug_id"<br />
}<br />
</bugzilla><br />
<br />
=== Installing and updating - {{Bug|1153432}} ===<br />
<br />
<bugzilla><br />
{<br />
"blocks": 1153432,<br />
"include_fields": "id, priority, summary, status, assigned_to,resolution",<br />
"order": "bug_id"<br />
}<br />
</bugzilla><br />
<br />
=== Service Workers - {{Bug|1153433}} ===<br />
<br />
<bugzilla><br />
{<br />
"blocks": 1153433,<br />
"include_fields": "id, priority, summary, status, assigned_to,resolution",<br />
"order": "bug_id"<br />
}<br />
</bugzilla><br />
<br />
=== Origins and cookie jars - {{Bug|nsec-origins}} ===<br />
<br />
<bugzilla><br />
{<br />
"blocks": "1153435,1163254,1179985",<br />
"include_fields": "id, priority, summary, status, assigned_to,resolution",<br />
"order": "bug_id"<br />
}<br />
</bugzilla></div>Sickinghttps://wiki.mozilla.org/index.php?title=FirefoxOS/New_security_model&diff=1064969FirefoxOS/New security model2015-03-28T10:39:32Z<p>Sicking: </p>
<hr />
<div>== Goals ==<br />
<br />
* Enable exposing "sensitive APIs" to 3rd party developers.<br />
* Use the same update and security model for gaia and for 3rd party content.<br />
* Don't require content which uses "senstivie APIs" to be installed. Users should be able to simply browse to it.<br />
* Don't have separate cookie jars for separate apps. At least for normal content which doesn't use "sensitive APIs".<br />
* Ensure that content which uses "sensitive APIs" always runs in a separate process. Enforce in the parent process that only these separate processes can trigger "sensitive APIs". I.e. hacking a child process should not permit access to more sensitive APIs.<br />
* Enable content which uses "sensitive APIs" to have normal http(s) URLs such that they can use OAuth providers like facebook.<br />
* Enable content which uses "sensitive APIs" to use service workers.<br />
<br />
"Sensitive APIs" here means APIs that we have not figured out how to safely expose to normal web pages. About 5-10% of the content in our marketplace falls into this category, and none of the content on the rest of the web fall into this category. I.e. most content does not use sensitive APIs, and can and should remain as normal websites.<br />
<br />
<br />
== Implementation ==<br />
<br />
=== Signing ===<br />
<br />
We will require that all content which uses "sensitive APIs" is signed. For now only the firefox marketplace will be allowed to do the signing. Possibly this will be changed in the future, but that's likely more a policy change than a code change.<br />
<br />
Signing is done by having the developer package the content into a package and submit it to the mozilla marketplace. The marketplace will review the app and then add a signature to the package. The developer can then download the signed package and upload to the developer's website.<br />
<br />
'''Issue:''' Should we allow other forms manual review of each app? Can the marketplace "review a developer" and give the developer access to automatic signing?<br />
<br />
'''Issue:''' Is there a reason to restrict signed packages to only be hosted on the marketplace?<br />
<br />
'''Issue:''' Should we enable the marketplace to host signed packages for developers which doesn't want to run a web server?<br />
<br />
The format used for the packaging will be the one defined in the [https://github.com/w3ctag/packaging-on-the-web W3C packaging spec draft]. A header is added to the package to indicate that it's a signed package. The advantage of this packaging format, compared to zip, is that it's streamable.<br />
<br />
The format used for the signature is still to be determined, but hopefully we can use the same file formats and file names as used today. However it's important that the signatures also cover the header data for each resource, as well as the header data for the package itself.<br />
<br />
'''Issue:''' Decide on exact signature format<br />
<br />
<br />
=== Verifying signatures ===<br />
<br />
To load a webpage in a signed package, the user navigates to a URL like "https://website.com/RSSReader2000/package.pak!//index.html". The part before the "!//" is the URL to the package itself. The part after the "!//" is the resource path inside the package.<br />
<br />
So loading signed content does not require an installation to happen. Simply navigating to a URL like the above is enough.<br />
<br />
When the user navigates to such a page, Gecko will download the package from the webserver. Gecko will then see in the header of the package that the package is signed.<br />
<br />
Before serving any resources from the package to the rest of Gecko, the network layer will first wait for the signatures to be loaded from the package. It will also verify that the resource that is currently being loaded is covered by, and matches, the signature.<br />
<br />
'''Issue:''' Should we require that the signature-files live at the start of the package. That way we'd always have the signature available before the file contents covered by the signature.<br />
<br />
We should likely cache which resources in the package that we've checked the signature of, so that we don't have to recheck if a resource is loaded multiple times.<br />
<br />
Another thing that needs to be done before any content is served by the network layer is to look in the manifest and populate the nsIPermissionManager database with any permissions enumerated in the manifest. After having checked that the manifest properly matches the signature of course.<br />
<br />
<br />
=== CSP ===<br />
<br />
We need to make sure that it can't load scripts from outside of the signed package. And we need to make sure that it can't use inline scripts.<br />
<br />
The plan is to use the CSP code to accomplish this. We can mainly leverage existing code which enables applying a default CSP policy to certain content. We'll use this to apply a default CSP to all signed content similarly to how we currently apply a default CSP to all privileged apps.<br />
<br />
We'll also need to extend it to enable it to enforce loads to happen "from same package", rather than just "from same origin".<br />
<br />
'''Issue:''' Does CSP allow putting limits on where serviceworkers can be loaded from? We need to restrict ServiceWorkers scopes as well as script-urls to be from inside the package.<br />
<br />
We also can't allow signed content to be opened in an <iframe>, other than by pages from the same signed package. This is partially to prevent signed content from getting clickjacked. However it's also because we want to always open signed content in a separate OS process, and currently gecko does not support out-of-process plain <iframe>s.<br />
<br />
Hopefully this is a restriction we can eventually relax, for example by allowing pages in a signed package to opt in to being iframe-able. But this will require out-of-process <iframe>s and so will have to wait.<br />
<br />
<br />
=== Process isolation ===<br />
<br />
In order to ensure that only signed content can access the APIs that it has been signed for, we want to always use separate child processes to run such content.<br />
<br />
This means that when a user navigates from an unsigned page to a signed page, that we need to switch which process render the pages. Right now this can only be done by creating a new <iframe mozbrowser>.<br />
<br />
However only Gecko knows that a particular URL is signed. Gaia could not simply look at a URL to know if it will return signed content or not. And Gecko only knows that it's signed content once response data starts arriving.<br />
<br />
Even if we add some way for gecko to signal to the <iframe mozbrowser> embedder that a new <iframe mozbrowser> needs to be created, this will make going "back"/"forward" between the two very messy.<br />
<br />
'''Issue:''' We need to figure out how to make navigation work. This will likely require very tricky <iframe mozbrowser> work.<br />
<br />
We also need to change security checks that currently are done in the parent process. Currently many of them are heavily based on app-ids and installed apps. This may need to be changed.<br />
<br />
'''Issue:''' We need to figure out if changes are needed to the security checks of sensitive APIs.<br />
<br />
<br />
=== Installing and updating ===<br />
<br />
Signed packages follow normal http semantics. I.e. if the package still exists in our http cache when the user revisits a signed page, but the cache headers indicate that the content needs to be updated, we do a normal GET request to see if a new version needs to be downloaded.<br />
<br />
If a new version of the package is being sent, we follow the same behavior as when visiting a package for the first time. I.e. we need to reverify signatures as well as update any permissions in the nsIPermissionManager database.<br />
<br />
However, we want to avoid having to download a whole package if just part of it has changed. In order to support that we hope to enable the server to respond to the GET request for an updated package with just a "diff" of what's changed between the previous and current version.<br />
<br />
One possible way to do this would be to have gecko indicate that it supports a new type of content encoding as well as send the etag of the current package file. The server can then look at the etag and if it has (or can generate) a diff between the clients version and the latest version, it can respond with a special content-encoding as well as the package diff.<br />
<br />
Gecko can then use the diff to patch the existing package.<br />
<br />
'''Issue:''' Decide on details of diff mechanism and format<br />
<br />
Note that sending a diff is entirely the server's choice. If the server doesn't support this newly created diff mechanism, then it will simply serve a full package. Likewise if the user is on a very old version which the server doesn't have a diff for, the server can simply serve a full package.<br />
<br />
In the case when a diff is received, it is probably fine to not support streaming package content. I.e. in that case its probably fine to wait for the full diff to be downloaded and applied, before returning any data from the Gecko network layer.<br />
<br />
We do in that case still need to verify signatures of the new package version.<br />
<br />
'''Issue:''' Decide on how to verify signatures when a diff is downloaded. Also decide if we can verify signatures incrementally or not.<br />
<br />
Installing a signed package mainly consists of pinning it in the http cache such that it doesn't get evicted. We still need to check for updates according to normal "app update" scheduling.<br />
<br />
<br />
=== Service Workers ===<br />
<br />
One of the central pieces of the new Gaia architecture is the use of service workers. This isn't just to support offline for gaia apps, but also to support dynamic generation of page markup, and the ability to run logic in order to decide what resource to return for a given URL.<br />
<br />
In order to make service workers work with the package update logic we should couple package update with service worker update. When the ServiceWorker spec require the browser to check for updates of, or download updates of, the ServiceWorker script, we instead update the full signed package.<br />
<br />
This means that both when we do an "automatic" ServiceWorker update check, such as when the user visit a page which uses the ServiceWorker, and when the ServiceWorkerRegistration.update() function is called, that we update the full package rather than just the ServiceWorker script.<br />
<br />
Once a new package has been downloaded, we go through the normal ServiceWorker update cycle. I.e. Gecko fire both "install" and "activate" events on the ServiceWorker. This will happen any time that a package is updated, even if the contents of the ServiceWorker script hasn't changed.<br />
<br />
Gecko need to still serve the previous package content until the "activate" event for the new ServiceWorker version fires. I.e. until the new version has been installed, the old version of the package needs to be served for any network requests.<br />
<br />
'''Issue:''' How do we enable the newly installing serviceworker to load content from the new package version, even though the previous package version is the one pinned in the cache.<br />
<br />
'''Issue:''' Does CSP allow putting limits on where serviceworkers can be loaded from? We need to restrict ServiceWorkers scopes as well as script-urls to be from inside the package.<br />
<br />
<br />
=== Origins and cookie jars ===<br />
<br />
The biggest change here is that we should stop always using different cookie jars for different apps. In particular normal unsigned content should always use the same cookie jar no matter which app it belongs to.<br />
<br />
However signed packages will get their own cookie jars. So a signed package will not share cookies, IndexedDB data, etc with unsigned content from the same domain. It will also not share data with other signed packages from the same domain. This is to ensure that unsigned content from the same domain can't read for example sensitive data that the signed content has cached in IndexedDB.<br />
<br />
'''Issue:''' Do requests from a signed package to unsigned content use the package's cookie jar? Or the normal cookie jar. I.e. if a signed package does an XHR request to a normal website, does that use the website's cookies?<br />
<br />
'''Issue:''' Figure out how to give signed content its own cookie jar. One potential solution here is to remove our close tie between cookie jar and appid. Another possible solution would be to make the various APIs use the full package path instead of the domain as key.<br />
<br />
However when we are loading the package itself, we don't use the cookie jar of the signed app. Instead we use the cookie jar of the unsigned content for the origin which the package lives un. We have to do it this way since when we fetch a signed package the first time, we don't know that the package is signed, and so we use the normal cookie jar for that domain.<br />
<br />
'''Issue:''' What happens if unsigned content does an XHR request to a URL inside a signed package. There doesn't seem to be any security issues involved in allowing that.<br />
<br />
'''Issue:''' Does this mean that the *cookies* used for signed content is the same as the cookies used for unsigned content? I.e. that only IDB/localStorage/permissions are separate for signed content. That seems to be the case if network requests to normal websites from signed content uses the normal cookie jar. What does document.cookies return? Should we make it return null?<br />
<br />
'''Issue:''' One potential solution here is to do security checks in the parent only to protect the storage data and permissions of the signed content. And make sure to flag the principals used for documents loaded from signed packages as belonging to the appropriate package. But for anything related to network, just treat signed content like normal content belonging to the normal cookie jar.<br />
<br />
'''Issue:''' Would it be simpler to make signed content use an entirely separate cookie jar. Including for XHR requests and <iframe>s to content outside of the signed package? That might allow us to use a more generic cookie jar feature.<br />
<br />
Signed content must never be considered same-origin with unsigned content, or content from another signed package. This is to ensure that unsigned content from the same https domain can't open the signed content in an <iframe> and then reach in to the opened page and use its privileges.<br />
<br />
The mechanism which is used to ensure that signed packages get a unique cookie jar should also be used to make sure that principals from signed an unsigned pages are never considered same-origin.<br />
<br />
'''Issue:''' Figure out exactly what field to use to indicate which signed package a principal belongs to.</div>Sickinghttps://wiki.mozilla.org/index.php?title=FirefoxOS/New_security_model&diff=1064968FirefoxOS/New security model2015-03-28T10:26:04Z<p>Sicking: Created page with "== Goals == * Enable exposing "sensitive APIs" to 3rd party developers. * Use the same update and security model for gaia and for 3rd party content. * Don't require content w..."</p>
<hr />
<div>== Goals ==<br />
<br />
* Enable exposing "sensitive APIs" to 3rd party developers.<br />
* Use the same update and security model for gaia and for 3rd party content.<br />
* Don't require content which uses "senstivie APIs" to be installed. Users should be able to simply browse to it.<br />
* Don't have separate cookie jars for separate apps. At least for normal content which doesn't use "sensitive APIs".<br />
* Ensure that content which uses "sensitive APIs" always runs in a separate process. Enforce in the parent process that only these separate processes can trigger "sensitive APIs". I.e. hacking a child process should not permit access to more sensitive APIs.<br />
* Enable content which uses "sensitive APIs" to have normal http(s) URLs such that they can use OAuth providers like facebook.<br />
* Enable content which uses "sensitive APIs" to use service workers.<br />
<br />
"Sensitive APIs" here means APIs that we have not figured out how to safely expose to normal web pages. About 5-10% of the content in our marketplace falls into this category, and none of the content on the rest of the web fall into this category. I.e. most content does not use sensitive APIs, and can and should remain as normal websites.<br />
<br />
<br />
== Implementation ==<br />
<br />
=== Signing ===<br />
<br />
We will require that all content which uses "sensitive APIs" is signed. For now only the firefox marketplace will be allowed to do the signing. Possibly this will be changed in the future, but that's likely more a policy change than a code change.<br />
<br />
Signing is done by having the developer package the content into a package and submit it to the mozilla marketplace. The marketplace will review the app and then add a signature to the package. The developer can then download the signed package and upload to the developer's website.<br />
<br />
Issue: Should we allow other forms manual review of each app? Can the marketplace "review a developer" and give the developer access to automatic signing?<br />
<br />
Issue: Is there a reason to restrict signed packages to only be hosted on the marketplace?<br />
<br />
Issue: Should we enable the marketplace to host signed packages for developers which doesn't want to run a web server?<br />
<br />
The format used for the packaging will be the one defined in the [https://github.com/w3ctag/packaging-on-the-web W3C packaging spec draft]. A header is added to the package to indicate that it's a signed package. The advantage of this packaging format, compared to zip, is that it's streamable.<br />
<br />
The format used for the signature is still to be determined, but hopefully we can use the same file formats and file names as used today. However it's important that the signatures also cover the header data for each resource, as well as the header data for the package itself.<br />
<br />
Issue: Decide on exact signature format<br />
<br />
<br />
=== Verifying signatures ===<br />
<br />
To load a webpage in a signed package, the user navigates to a URL like "https://website.com/RSSReader2000/package.pak!//index.html". The part before the "!//" is the URL to the package itself. The part after the "!//" is the resource path inside the package.<br />
<br />
So loading signed content does not require an installation to happen. Simply navigating to a URL like the above is enough.<br />
<br />
When the user navigates to such a page, Gecko will download the package from the webserver. Gecko will then see in the header of the package that the package is signed.<br />
<br />
Before serving any resources from the package to the rest of Gecko, the network layer will first wait for the signatures to be loaded from the package. It will also verify that the resource that is currently being loaded is covered by, and matches, the signature.<br />
<br />
Issue: Should we require that the signature-files live at the start of the package. That way we'd always have the signature available before the file contents covered by the signature.<br />
<br />
We should likely cache which resources in the package that we've checked the signature of, so that we don't have to recheck if a resource is loaded multiple times.<br />
<br />
Another thing that needs to be done before any content is served by the network layer is to look in the manifest and populate the nsIPermissionManager database with any permissions enumerated in the manifest. After having checked that the manifest properly matches the signature of course.<br />
<br />
<br />
=== CSP ===<br />
<br />
We need to make sure that it can't load scripts from outside of the signed package. And we need to make sure that it can't use inline scripts.<br />
<br />
The plan is to use the CSP code to accomplish this. We can mainly leverage existing code which enables applying a default CSP policy to certain content. We'll use this to apply a default CSP to all signed content similarly to how we currently apply a default CSP to all privileged apps.<br />
<br />
We'll also need to extend it to enable it to enforce loads to happen "from same package", rather than just "from same origin".<br />
<br />
Issue: Does CSP allow putting limits on where serviceworkers can be loaded from? We need to restrict ServiceWorkers scopes as well as script-urls to be from inside the package.<br />
<br />
We also can't allow signed content to be opened in an <iframe>, other than by pages from the same signed package. This is partially to prevent signed content from getting clickjacked. However it's also because we want to always open signed content in a separate OS process, and currently gecko does not support out-of-process plain <iframe>s.<br />
<br />
Hopefully this is a restriction we can eventually relax, for example by allowing pages in a signed package to opt in to being iframe-able. But this will require out-of-process <iframe>s and so will have to wait.<br />
<br />
<br />
=== Process isolation ===<br />
<br />
In order to ensure that only signed content can access the APIs that it has been signed for, we want to always use separate child processes to run such content.<br />
<br />
This means that when a user navigates from an unsigned page to a signed page, that we need to switch which process render the pages. Right now this can only be done by creating a new <iframe mozbrowser>.<br />
<br />
However only Gecko knows that a particular URL is signed. Gaia could not simply look at a URL to know if it will return signed content or not. And Gecko only knows that it's signed content once response data starts arriving.<br />
<br />
Even if we add some way for gecko to signal to the <iframe mozbrowser> embedder that a new <iframe mozbrowser> needs to be created, this will make going "back"/"forward" between the two very messy.<br />
<br />
Issue: We need to figure out how to make navigation work. This will likely require very tricky <iframe mozbrowser> work.<br />
<br />
We also need to change security checks that currently are done in the parent process. Currently many of them are heavily based on app-ids and installed apps. This may need to be changed.<br />
<br />
Issue: We need to figure out if changes are needed to the security checks of sensitive APIs.<br />
<br />
<br />
=== Installing and updating ===<br />
<br />
Signed packages follow normal http semantics. I.e. if the package still exists in our http cache when the user revisits a signed page, but the cache headers indicate that the content needs to be updated, we do a normal GET request to see if a new version needs to be downloaded.<br />
<br />
If a new version of the package is being sent, we follow the same behavior as when visiting a package for the first time. I.e. we need to reverify signatures as well as update any permissions in the nsIPermissionManager database.<br />
<br />
However, we want to avoid having to download a whole package if just part of it has changed. In order to support that we hope to enable the server to respond to the GET request for an updated package with just a "diff" of what's changed between the previous and current version.<br />
<br />
One possible way to do this would be to have gecko indicate that it supports a new type of content encoding as well as send the etag of the current package file. The server can then look at the etag and if it has (or can generate) a diff between the clients version and the latest version, it can respond with a special content-encoding as well as the package diff.<br />
<br />
Gecko can then use the diff to patch the existing package.<br />
<br />
Issue: Decide on details of diff mechanism and format<br />
<br />
Note that sending a diff is entirely the server's choice. If the server doesn't support this newly created diff mechanism, then it will simply serve a full package. Likewise if the user is on a very old version which the server doesn't have a diff for, the server can simply serve a full package.<br />
<br />
In the case when a diff is received, it is probably fine to not support streaming package content. I.e. in that case its probably fine to wait for the full diff to be downloaded and applied, before returning any data from the Gecko network layer.<br />
<br />
We do in that case still need to verify signatures of the new package version.<br />
<br />
Issue: Decide on how to verify signatures when a diff is downloaded. Also decide if we can verify signatures incrementally or not.<br />
<br />
Installing a signed package mainly consists of pinning it in the http cache such that it doesn't get evicted. We still need to check for updates according to normal "app update" scheduling.<br />
<br />
<br />
=== Service Workers ===<br />
<br />
One of the central pieces of the new Gaia architecture is the use of service workers. This isn't just to support offline for gaia apps, but also to support dynamic generation of page markup, and the ability to run logic in order to decide what resource to return for a given URL.<br />
<br />
In order to make service workers work with the package update logic we should couple package update with service worker update. When the ServiceWorker spec require the browser to check for updates of, or download updates of, the ServiceWorker script, we instead update the full signed package.<br />
<br />
This means that both when we do an "automatic" ServiceWorker update check, such as when the user visit a page which uses the ServiceWorker, and when the ServiceWorkerRegistration.update() function is called, that we update the full package rather than just the ServiceWorker script.<br />
<br />
Once a new package has been downloaded, we go through the normal ServiceWorker update cycle. I.e. Gecko fire both "install" and "activate" events on the ServiceWorker. This will happen any time that a package is updated, even if the contents of the ServiceWorker script hasn't changed.<br />
<br />
Gecko need to still serve the previous package content until the "activate" event for the new ServiceWorker version fires. I.e. until the new version has been installed, the old version of the package needs to be served for any network requests.<br />
<br />
Issue: How do we enable the newly installing serviceworker to load content from the new package version, even though the previous package version is the one pinned in the cache.<br />
<br />
Issue: Does CSP allow putting limits on where serviceworkers can be loaded from? We need to restrict ServiceWorkers scopes as well as script-urls to be from inside the package.<br />
<br />
<br />
=== Origins and cookie jars ===<br />
<br />
The biggest change here is that we should stop always using different cookie jars for different apps. In particular normal unsigned content should always use the same cookie jar no matter which app it belongs to.<br />
<br />
However signed packages will get their own cookie jars. So a signed package will not share cookies, IndexedDB data, etc with unsigned content from the same domain. It will also not share data with other signed packages from the same domain. This is to ensure that unsigned content from the same domain can't read for example sensitive data that the signed content has cached in IndexedDB.<br />
<br />
Issue: Do requests from a signed package to unsigned content use the package's cookie jar? Or the normal cookie jar. I.e. if a signed package does an XHR request to a normal website, does that use the website's cookies?<br />
<br />
Issue: Figure out how to give signed content its own cookie jar. One potential solution here is to remove our close tie between cookie jar and appid. Another possible solution would be to make the various APIs use the full package path instead of the domain as key.<br />
<br />
However when we are loading the package itself, we don't use the cookie jar of the signed app. Instead we use the cookie jar of the unsigned content for the origin which the package lives un. We have to do it this way since when we fetch a signed package the first time, we don't know that the package is signed, and so we use the normal cookie jar for that domain.<br />
<br />
Issue: What happens if unsigned content does an XHR request to a URL inside a signed package. There doesn't seem to be any security issues involved in allowing that.<br />
<br />
Issue: Does this mean that the *cookies* used for signed content is the same as the cookies used for unsigned content? I.e. that only IDB/localStorage/permissions are separate for signed content. That seems to be the case if network requests to normal websites from signed content uses the normal cookie jar. What does document.cookies return? Should we make it return null?<br />
<br />
Issue: One potential solution here is to do security checks in the parent only to protect the storage data and permissions of the signed content. And make sure to flag the principals used for documents loaded from signed packages as belonging to the appropriate package. But for anything related to network, just treat signed content like normal content belonging to the normal cookie jar.<br />
<br />
Issue: Would it be simpler to make signed content use an entirely separate cookie jar. Including for XHR requests and <iframe>s to content outside of the signed package? That might allow us to use a more generic cookie jar feature.<br />
<br />
Signed content must never be considered same-origin with unsigned content, or content from another signed package. This is to ensure that unsigned content from the same https domain can't open the signed content in an <iframe> and then reach in to the opened page and use its privileges.<br />
<br />
The mechanism which is used to ensure that signed packages get a unique cookie jar should also be used to make sure that principals from signed an unsigned pages are never considered same-origin.<br />
<br />
Issue: Figure out exactly what field to use to indicate which signed package a principal belongs to.</div>Sickinghttps://wiki.mozilla.org/index.php?title=Gecko_BD_Guidelines&diff=1023937Gecko BD Guidelines2014-10-09T21:49:39Z<p>Sicking: </p>
<hr />
<div>When partners request Gecko features, consider the following:<br />
<br />
* We need descriptions that are clear enough for engineers to understand the scope. We also need a description of why the partner need the feature. I.e. what end-user functionality they are trying to build.<br />
<br />
* It's rare that we get enough details in an initial request that we can go off and build the feature. Generally we need to talk engineer to engineer with the partner to hammer out details.<br />
<br />
* Staff who are going to work on a feature should sign off before we agree to it (including work needed on dependencies).<br />
<br />
* Features accessible to Web sites require special attention. Web-visible features must have a public specification. There are some specs we don't want to implement, so check with staff (module owners) whether an existing spec is one we're willing to implement. If there is no spec, we can work with a partner to create one. This includes extensions to existing features. The reason this is needed is because once we expose a feature to the web, we essentially commit to supporting that feature indefinitely.<br />
<br />
* Features that are only exposed to "privileged" FirefoxOS apps are easier to build than features exposed to the web. However they still require significant design work since we have to support the feature for a very long time.<br />
<br />
* Restricting features to "internal" apps (that ship with the device) is much easier --- especially if the partner can ship the feature(s) by applying their own patches to Gecko.</div>Sickinghttps://wiki.mozilla.org/index.php?title=Gecko_BD_Guidelines&diff=1023917Gecko BD Guidelines2014-10-09T21:12:10Z<p>Sicking: </p>
<hr />
<div>When partners request Gecko features, consider the following:<br />
<br />
* We need descriptions that are clear enough for engineers to understand the scope. We also need a description of why the partner need the feature. I.e. what end-user functionality they are trying to build.<br />
<br />
* It's rare that we get enough details in an initial request that we can go off and build the feature. Generally we need to talk engineer to engineer with the partner to hammer out details.<br />
<br />
* Staff who are going to work on a feature should sign off before we agree to it (including work needed on dependencies).<br />
<br />
* Features accessible to Web sites. Web-visible features must have a public specification. There are some specs we don't want to implement, so check with staff (module owners) whether an existing spec is one we're willing to implement. If there is no spec, we can work with a partner to create one. This includes extensions to existing features. The reason this is needed is because once we expose a feature to the web, we essentially commit to supporting that feature indefinitely.<br />
<br />
* Features that are only exposed to "privileged" FirefoxOS apps are easier to build than features exposed to the web. However they still require significant design work since we have to support the feature for a very long time.<br />
<br />
* Restricting features to "internal" apps (that ship with the device) is much easier --- especially if the partner can ship the feature(s) by applying their own patches to Gecko.</div>Sickinghttps://wiki.mozilla.org/index.php?title=Modules/Core&diff=995162Modules/Core2014-07-07T20:22:51Z<p>Sicking: </p>
<hr />
<div><noinclude><br />
'''Do not edit this page''' unless either:<br />
<br />
# you are a module owner who is:<br />
#* altering the list of peers in your module<br />
#* adding or removing a sub-module<br />
#* changing the owner of one of your sub-modules; or<br />
# you have agreed a change of owner or module addition/deletion with the Module Ownership Module group, probably via [https://www.mozilla.org/about/forums/#governance mozilla.governance].<br />
</noinclude><br />
{{Module<br />
|name=Accessibility<br />
|description=Support for platform accessibility APIs. Accessibility APIs are used by 3rd party software like screen readers, screen magnifiers, and voice dictation software, which need information about document content and UI controls, as well as important events like changes of focus.<br />
|owner=[mailto:surkov.alexander@gmail.com Alexander Surkov]<br />
|peers=[mailto:bolterbugz@gmail.com David Bolter], [mailto:ginn.chen@oracle.com Ginn Chen], [mailto:trev.saunders@gmail.com Trevor Saunders], [mailto:marco.zehe@googlemail.com Marco Zehe] <br />
|group=dev-accessibility<br />
|source_dirs=accessible/<br />
|url=http://www.mozilla.org/access/<br />
|components=Core::Disability Access APIs<br />
}}<br />
<br />
{{Module<br />
|name=Browser WebAPI<br />
|description=Web API for rendering apps, browser windows and widgets.<br />
|owner=[mailto:kchen@mozilla.com Kan-Ru Chen]<br />
|peers=[mailto:Olli.Pettay@helsinki.fi Olli Pettay], [mailto:fabrice@mozilla.com Fabrice Desré]<br />
|group=dev-webapi<br />
|source_dirs=dom/browser-element/<br />
|url=<br />
|components=Core::DOM<br />
}}<br />
<br />
{{Module<br />
|name=Build and Release Tools<br />
|description=Tools related to build and release automation and configuration of release builds.<br />
|owner=[mailto:nrthomas@gmail.com Nick Thomas]<br />
|peers=[mailto:bhearsum@mozilla.com Ben Hearsum], [mailto:ccooper@deadsquid.com Chris Cooper], [mailto:cmp@mozilla.org Chase Phillips], [mailto:mozpreed@sigkill.com John Paul Reed], [mailto:robert@roberthelmer.com Robert Helmer]<br />
|group=dev-builds<br />
|source_dirs=tools/botrunner.py, tools/build-environment/, tools/build/, tools/buildbot-configs/, tools/buildbot/, tools/buildbotcustom/, tools/l10n/, tools/MozBuild/, tools/patcher-configs/, tools/patcher/, tools/release/, tools/tinderbox-configs/, tools/tinderbox/, tools/update-packaging/, browser/config/mozconfigs/, mobile/config/mozconfigs/, xulrunner/config/mozconfigs/<br />
|url=<br />
|components=mozilla.org::Release Engineering, mozilla.org::Release Engineering: Custom Builds<br />
}}<br />
<br />
{{Module<br />
|name=Build Config<br />
|description=The build system for Gecko and several mozilla.org hosted Gecko-based applications.<br />
|owner=[mailto:gps@mozilla.com Gregory Szorc] (:gps)<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg] (:bsmedberg), [mailto:mh@glandium.org Mike Hommey] (:glandium), [mailto:ted@mielczarek.org Ted Mielczarek] (:ted), [mailto:mshal@mozilla.com Mike Shal] (:mshal), [mailto:me@kylehuey.com Kyle Huey] (:khuey) (less active - send reviews to others)<br />
|group=dev-builds<br />
|source_dirs=build/, config/, python/mozbuild, tools/cross-commit, tools/cvs2hg-import.py, tools/cvsmgmt/, tools/elf-dynstr-gc/, tools/trees.pl, browser/config/mozconfigs/, mobile/config/mozconfigs/, xulrunner/config/mozconfigs/<br />
|url=http://www.mozilla.org/build/<br />
|components=Core::Build Config<br />
}}<br />
<br />
{{Module<br />
|name=Code Analysis and Debugging Tools<br />
|description=Tools for debugging Mozilla code or for analyzing speed, memory use, and other characteristics of it.<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|peers=<br />
|group=dev-performance<br />
|source_dirs=tools/codesighs/, tools/debug/, tools/dreftool/, tools/dumpdeps/, tools/footprint/, tools/jprof/, tools/leaky/, tools/memory/, tools/module-deps/, tools/performance/, tools/post_compile/, tools/preloader/, tools/rb/, tools/reorder/, tools/trace-malloc/, tools/uuiddeps/, <br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Content HTTP Headers<br />
|description=HTTP headers related to content, e.g. User-Agent, Content-Type, Accept. (Transport-related headers are the responsibility of the Necko module owner.)<br />
|owner=[mailto:gerv@mozilla.org Gervase Markham]<br />
|peers=[mailto:lmandel@mozilla.com Lawrence Mandel]<br />
|group=dev-platform<br />
|source_dirs= <br />
|url=https://developer.mozilla.org/en/Gecko_user_agent_string_reference<br />
|components=Core::Networking: HTTP<br />
}}<br />
<br />
{{Module<br />
|name=Content Security<br />
|description=Native content-based security features, including: Content Security Policy (CSP), Mixed Content Blocker (MCB), and Safe Browsing.<br />
|owner=[mailto:sstamm@mozilla.org Sid Stamm], [mailto:gpascutto@mozilla.com Gian-Carlo Pascutto]<br />
|peers=[mailto:grobinson@mozilla.com Garrett Robinson], [mailto:tvyas@mozilla.com Tanvi Vyas], [mailto:dveditz@mozilla.com Dan Veditz]<br />
|group=dev-security<br />
|source_dirs=dom/security (needs to be created)<br />
|components=Core::DOM: Security<br />
}}<br />
<br />
{{Module<br />
|name=Cookies and Permissions<br />
|description=<br />
|owner=[mailto:mchew@mozilla.com Monica Chew]<br />
|peers=[mailto:josh@joshmatthews.com Josh Matthews], [mailto:ehsan@mozilla.com Ehsan Akhgari], [mailto:mconnor@steelgryphon.com Mike Connor], [mailto:dwitte@gmail.com Dan Witte], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:sdwilsh@shawnwilsher.com Shawn Wilsher (ping on irc)]<br />
|group=dev-tech-network<br />
|source_dirs=extensions/cookie/, netwerk/cookie/<br />
|url=<br />
|components=Core::Networking: Cookies<br />
}}<br />
{{Module<br />
|name=Cycle Collector<br />
|description=Code to break and collect objects within reference cycles<br />
|owner=[mailto:continuation@gmail.com Andrew McCreight]<br />
|peers=Peter Van der Beken, Olli Pettay, David Baron<br />
|source_dirs=xpcom/base/nsCycleCollector.* and some support headers<br />
|components=Core::XPCOM<br />
|group=dev-platform<br />
}}<br />
{{Module<br />
|name=docshell<br />
|description=<br />
|owner=[mailto:bzbarsky@mit.edu Boris Zbarsky]<br />
|peers=[mailto:cbiesinger@gmail.com Christian Biesinger],[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:jst@mozilla.org Johnny Stenback], [mailto:Olli.Pettay@helsinki.fi Olli Pettay], [mailto:justin.lebar@gmail.com Justin Lebar]<br />
|group=dev-tech-layout<br />
|source_dirs=docshell/, uriloader/, webshell/<br />
|url=<br />
|components=Core::Document Navigation<br />
}}<br />
<br />
{{Module<br />
|name=Device Storage<br />
|description=Support for the device storage API<br />
|owner=[https://mozillians.org/u/dhylands/ Dave Hylands], [mailto:jvarga@mozilla.com Jan Varga]<br />
|peers=[mailto:dougt@dougt.org Doug Turner]<br />
|group=dev-tech-dom<br />
|source_dirs=dom/devicestorage/, dom/interfaces/devicestorage/<br />
|url=https://developer.mozilla.org/en-US/docs/WebAPI/Device_Storage<br />
|components=Core::DOM: Device Interfaces<br />
}}<br />
<br />
{{Module<br />
|name=Document Object Model<br />
|description=<br />
|owner=[mailto:jst@mozilla.org Johnny Stenback], [mailto:peterv@propagandism.org Peter Van der Beken]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:jonas@sicking.cc Jonas Sicking], [mailto:Olli.Pettay@helsinki.fi Olli Pettay], [mailto:bent@mozilla.com Ben Turner], [mailto:mounir.lamouri@mozilla.com Mounir Lamouri], [mailto:me@kylehuey.com Kyle Huey], [mailto:justin.lebar@gmail.com Justin Lebar], [mailto:hsivonen@iki.fi Henri Sivonen], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:bobbyholley@gmail.com Bobby Holley]<br />
|group=dev-tech-dom<br />
|source_dirs=content/*, dom/*, except directories covered by other modules<br />
|url=http://developer.mozilla.org/en/docs/DOM<br />
|components=Core::DOM, Core::DOM: CSS Object Model, Core::DOM: Core & HTML, Core::DOM: Events<br />
}}<br />
<br />
{{Module<br />
|name=Web Workers<br />
|description=<br />
|owner=[mailto:bent@mozilla.com Ben Turner]<br />
|peers=[mailto:mrbkap@mozilla.com Blake Kaplan], [mailto:jonas@sicking.cc Jonas Sicking], [mailto:me@kylehuey.com Kyle Huey]<br />
|group=dev-platform<br />
|source_dirs=dom/workers/<br />
|url=https://developer.mozilla.org/En/Using_web_workers<br />
|components=Core::DOM: Workers<br />
}}<br />
<br />
{{Module<br />
|name=IndexedDB<br />
|description=<br />
|owner=[mailto:bent@mozilla.com Ben Turner]<br />
|peers=[mailto:jonas@sicking.cc Jonas Sicking], [mailto:me@kylehuey.com Kyle Huey], [mailto:jvarga@mozilla.com Jan Varga]<br />
|group=dev-platform<br />
|source_dirs=dom/indexedDB/<br />
|url=https://developer.mozilla.org/en/IndexedDB<br />
|components=Core::DOM: IndexedDB<br />
}}<br />
<br />
{{Module<br />
|name=Editor<br />
|description=<br />
|owner=[mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|peers=<br />
|group=dev-platform<br />
|source_dirs=editor/<br />
|url=http://www.mozilla.org/editor/<br />
|components=Core::Editor<br />
}}<br />
<br />
{{Module<br />
|name=Embedding<br />
|description=<br />
|owner=[mailto:benjamin@smedbergs.us Benjamin Smedberg]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:jst@mozilla.org Johnny Stenback]<br />
|group=dev-embedding<br />
|source_dirs=embedding/<br />
|url=<br />
|components=Core::Embedding: APIs, Core::Embedding: ActiveX Wrapper, Core::Embedding: GRE Core, Core::Embedding: GTK Widget, Core::Embedding: MFC Embed, Core::Embedding: Mac, Core::Embedding: Packaging<br />
}}<br />
<br />
{{Module<br />
|name=Find As You Type<br />
|description=Find As You Type (formerly called Type Ahead Find) is a feature that allows quick web page navigation when you type a succession of characters in the body of the displayed page (not in an edit box of or drop down list). Currently seeks new owner.<br />
|owner=<br />
|peers=<br />
|group=dev-accessibility<br />
|source_dirs=extensions/typeaheadfind/<br />
|url=http://www.mozilla.org/access/type-ahead/<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Geolocation<br />
|description=Implementation of the Geolocation W3C Spec, location provider apis, and wifi scanning code.<br />
|owner=[mailto:dougt@dougt.org Doug Turner]<br />
|peers=[mailto:josh@joshmatthews.net Josh Matthews], [mailto:kchen@mozilla.com Kan-Ru Chen]<br />
|group=dev-tech-dom<br />
|source_dirs=dom/src/geolocation, dom/system/, netwerk/wifi<br />
|url=https://developer.mozilla.org/En/Using_geolocation<br />
|components=Core::Geolocation<br />
}}<br />
<br />
{{Module<br />
|name=Global Key Bindings<br />
|description=Global hot keys in Mozilla for the browser, editor, mail-news and widgets. Does not include underlined menu accelerators and the like, as those are part of i18n.<br />
|owner=[mailto:aaronleventhal@moonset.net Aaron Leventhal]<br />
|peers=[mailto:neil@parkwaycc.co.uk Neil Rashbrook]<br />
|group=dev-accessibility<br />
|source_dirs=content/xbl/builtin/<br />
|url=http://www.mozilla.org/projects/ui/accessibility/mozkeyintro.html<br />
|components=Core::Keyboard: Navigation<br />
}}<br />
<br />
{{Module<br />
|name=Graphics<br />
|description=Mozilla graphics API<br />
|owner=[mailto:jrmuizel@mozilla.com Jeff Muizelaar](Thebes, QCMS, YCbCr, Cairo/Pixman, Regions, OS X, Other), [mailto:roc+@cs.cmu.edu Robert O'Callahan]<br />
|peers=[mailto:jdrew@mozilla.com Joe Drew], [mailto:vladimir@pobox.com Vladimir Vukicevic], [mailto:bas.schouten@live.nl Bas Schouten](Layers, Windows), [mailto:bjacob@mozilla.com Benoit Jacob](gfx/gl), [mailto:bgirard@mozilla.com Benoit Girard](Compositor, Performance), [mailto:ajuma.bugzilla@alijuma.com Ali Juma], [mailto:jgilbert@mozilla.com Jeff Gilbert](WebGL, ANGLE), [mailto:george@mozilla.com George Wright](Canvas2D, Skia), [mailto:mwoodrow@mozilla.com Matt Woodrow](Layers API), [mailto:jdaggett@mozilla.com John Daggett](text/fonts), [mailto:jfkthame@googlemail.com Jonathan Kew](text/fonts), [mailto:nsilva@mozilla.com Nicolas Silva](MozSurface), [mailto:ncameron@mozilla.com Nick Cameron], [mailto:sikeda@mozilla.com Sotaro Ikeda](B2G), [mailto:snorp@mozilla.com James Willcox](Android), [mailto:clord@mozilla.com Christopher Lord]<br />
|group=dev-platform<br />
|source_dirs=gfx/, content/canvas/src/<br />
|url=https://wiki.mozilla.org/Platform/GFX https://wiki.mozilla.org/Gecko:Layers https://wiki.mozilla.org/Gecko:2DGraphicsSketch<br />
|components=Core::Graphics, Core::Graphics: Layers, Core::Graphics: Text, Core::GFX: Color Management, Core::Canvas: 2D, Core::Canvas: WebGL<br />
}}<br />
<br />
{{Module<br />
|name=APZ (Graphics submodule)<br />
|description=Asynchronous panning and zooming<br />
|owner=[mailto:kgupta@mozilla.com Kartikaya Gupta]<br />
|peers=[mailto:bballo@mozilla.com Botond Ballo], [mailto:tnikkel@mozilla.com Timothy Nikkel], [mailto:bgirard@mozilla.com Benoit Girard], [mailto:clord@mozilla.com Christopher Lord]<br />
|group=dev-platform<br />
|source=gfx/layers/apz<br />
|url=https://wiki.mozilla.org/Platform/GFX/APZ<br />
|components=Core::Panning and Zooming<br />
}}<br />
<br />
{{Module<br />
|name=Moz2D (Graphics submodule)<br />
|description=Platform independent 2D graphics API<br />
|owner=[mailto:bschouten@mozilla.com Bas Schouten]<br />
|peers=[mailto:jmuizelaar@mozilla.com Jeff Muizelaar], [mailto:gwright@mozilla.com George Wright], [mailto:jwatt@mozilla.com Jonathan Watt]<br />
|group=dev-platform<br />
|source=gfx/2d<br />
|url=https://wiki.mozilla.org/Platform/GFX/Moz2D<br />
|components=Core::Graphics<br />
}}<br />
<br />
<br />
{{Module<br />
|name=GTK Embedding Widget<br />
|description=Gtk Widget for embedding Mozilla into Gtk applications<br />
|owner=[mailto:marco@gnome.org Marco Pesenti Gritti]<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:dougt@meer.net Doug Turner]<br />
|group=dev-embedding<br />
|source_dirs=<br />
|url=<br />
|components=Core::Embedding: GTK Widget<br />
}}<br />
<br />
{{Module<br />
|name=Legacy HTML Parser<br />
|description=<br />
|owner=[mailto:mrbkap@gmail.com Blake Kaplan]<br />
|peers=[mailto:dbaron@dbaron.org David Baron], [mailto:jst@mozilla.org Johnny Stenback], [mailto:peterv@propagandism.org Peter Van der Beken], [mailto:rbs@maths.uq.edu.au rbs@maths.uq.edu.au]<br />
|group=dev-tech-dom<br />
|source_dirs=parser/htmlparser<br />
|url=http://www.mozilla.org/newlayout/doc/parser.html<br />
|components=Core::HTML: Parser<br />
}}<br />
<br />
{{Module<br />
|name=HAL<br />
|description=Hardware Abstraction Layer<br />
|owner=[https://mozillians.org/u/dhylands/ Dave Hylands]<br />
|peers=[mailto:gsvelto@mozilla.com Gabriele Svelto]<br />
|group=dev-platform<br />
|source_dirs=hal/<br />
|components=Core::Hardware Abstraction Layer (HAL)<br />
}}<br />
<br />
{{Module<br />
|name=HTML Parser<br />
|description=The HTML Parser transforms HTML source code into a DOM. It conforms to the HTML specification, and is mostly translated automatically from Java to C++.<br />
|owner=[mailto:hsivonen@iki.fi Henri Sivonen]<br />
|peers=<br />
|group=dev-tech-dom<br />
|source_dirs=parser/html<br />
|url=http://about.validator.nu/<br />
|components=Core::HTML: Parser<br />
}}<br />
<br />
{{Module<br />
|name=I18N Library<br />
|description=<br />
|owner=[mailto:jshin1987@gmail.com Jungshik Shin], [mailto:smontagu@smontagu.org Simon Montagu]<br />
|peers=[mailto:VYV03354@nifty.ne.jp Masatoshi Kimura]<br />
|group=dev-i18n<br />
|source_dirs=intl/<br />
|url=http://mozilla.org/projects/intl/index.html<br />
|components=Core::Internationalization<br />
}}<br />
<br />
{{Module<br />
|name=ImageLib<br />
|description=<br />
|owner=[mailto:joe@drew.ca Joe Drew]<br />
|peers=[mailto:netzen@gmail.com Brian Bondy], [mailto:jmuizelaar@mozilla.com Jeff Muizelaar], [mailto:jlebar@mozilla.com Justin Lebar], [mailto:seth@mozilla.com Seth Fowler]<br />
|group=dev-platform<br />
|source_dirs=media/libjpeg/, media/libpng/, image/, modules/zlib/<br />
|url=<br />
|components=Core::ImageLib<br />
}}<br />
<br />
{{Module<br />
|name=IPC<br />
|description=Message-passing between threads and processes<br />
|owner=[mailto:cjones@mozilla.com Chris Jones]<br />
|peers=[mailto:danderson@mozilla.com David Anderson], [mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:bent.mozilla@gmail.com Ben Turner]<br />
|group=dev-platform<br />
|source_dirs=ipc/glue/, ipc/ipdl/, ipc/chromium/<br />
|url=<br />
|components=Core::IPC}}<br />
<br />
{{Module<br />
|name=Java APIs for DOM<br />
|description=APIs for Java access to the Document Object Model<br />
|owner=[mailto:ashuk@eng.sun.com Ashutosh Kulkarni]<br />
|peers=<br />
|group=dev-tech-dom,dev-tech-java<br />
|source_dirs=java/dom/<br />
|url=http://www.mozilla.org/projects/blackwood/dom/<br />
|components=Core::Java APIs for DOM<br />
}}<br />
<br />
{{Module<br />
|name=Java APIs to WebShell<br />
|description=<br />
|owner=[mailto:edburns@acm.org Ed Burns]<br />
|peers=[mailto:ashuk@eng.sun.com Ashutosh Kulkarni]<br />
|group=dev-tech-java,dev-embedding<br />
|source_dirs=java/webclient/<br />
|url=http://www.mozilla.org/projects/blackwood/webclient/<br />
|components=Core::Java APIs to WebShell<br />
}}<br />
<br />
{{Module<br />
|name=Java Stubs<br />
|description=OJI<br />
|owner=[mailto:alfred.peng@sun.com Alfred Peng]<br />
|peers=[mailto:Xiaobin.Lu@eng.Sun.com Xiaobin Lu]<br />
|group=dev-tech-java<br />
|source_dirs=modules/oji/, nav-java/, sun-java/<br />
|url=http://www.mozilla.org/oji/<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Java to XPCOM Bridge<br />
|description=<br />
|owner=[mailto:pedemont@us.ibm.com Javier Pedemont]<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg]<br />
|group=dev-tech-xpcom,dev-tech-java<br />
|source_dirs=extensions/java<br />
|url=http://www.mozilla.org/projects/blackwood/connect/<br />
|components=Core::Java to XPCOM Bridge<br />
}}<br />
<br />
{{Module<br />
|name=Java Utility Classes<br />
|description=assert, debug, utilities, etc.<br />
|owner=[mailto:edburns@acm.org Ed Burns]<br />
|peers=[mailto:ashuk@eng.sun.com Ashutosh Kulkarni]<br />
|group=dev-tech-java<br />
|source_dirs=java/util/<br />
|url=http://www.mozilla.org/projects/blackwood/java-util/<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Java-Implemented Plugins<br />
|description=Infrastructure for writing MIME content-handlers<br />
in Java.<br />
|owner=[mailto:idk@eng.sun.com Igor Kushnirskiy]<br />
|peers=<br />
|group=dev-tech-java<br />
|source_dirs=java/plugins/<br />
|url=http://www.mozilla.org/projects/blackwood/java-plugins/<br />
|components=Core::Java-Implemented Plugins<br />
}}<br />
<br />
{{Module<br />
|name=JavaScript<br />
|description=JavaScript engine (SpiderMonkey)<br />
|owner=[mailto:jorendorff@mozilla.com Jason Orendorff]<br />
|peers=[mailto:danderson@mozilla.com David Anderson], [mailto:igor@mir2.org Igor Bukanov], [mailto:brendan@mozilla.org Brendan Eich], [mailto:gal@mozilla.com Andreas Gal], [mailto:wmccloskey@mozilla.com Bill McCloskey], [mailto:nnethercote@mozilla.com Nick Nethercote], [mailto:luke@mozilla.com Luke Wagner], [mailto:jwalden@mit.edu Jeff Walden], [mailto:ejpbruel@mozilla.com Eddy Bruel], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:jdemooij@mozilla.com Jan de Mooij], [mailto:hv1989@gmail.com Hannes Verschore], [mailto:kvijayan@mozilla.com Kannan Vijayan], [mailto:nmatsakis@mozilla.com Niko Matsakis], [mailto:shu@mozilla.com Shu-yu Guo], [mailto:evilpies@gmail.com Tom Schuster], [mailto:bhackett1024@gmail.com Brian Hackett], [mailto:bobbyholley@gmail.com Bobby Holley], [mailto:till@tillschneidereit.net Till Schneidereit]<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/src<br />
|url=http://www.mozilla.org/js/spidermonkey,<br />
http://developer.mozilla.org/en/docs/About_JavaScript<br />
|components=Core::JavaScript Engine<br />
}}<br />
<br />
{{Module<br />
|name=JavaScript JIT<br />
|description=JavaScript engine's JIT compilers (IonMonkey, Baseline)<br />
|owner=[mailto:jdemooij@mozilla.com Jan de Mooij]<br />
|peers=[mailto:danderson@mozilla.com David Anderson], [mailto:shu@mozilla.com Shu-yu Guo], [mailto:bhackett1024@gmail.com Brian Hackett], [mailto:nicolas.b.pierron@mozilla.com Nicolas Pierron], [mailto:mrosenberg@mozilla.com Marty Rosenberg], [mailto:evilpies@gmail.com Tom Schuster], [mailto:sstangl@mozilla.com Sean Stangl], [mailto:hv1989@gmail.com Hannes Verschore], [mailto:kvijayan@mozilla.com Kannan Vijayan], [mailto:luke@mozilla.com Luke Wagner]<br />
|group=dev-tech-js-engine-internals<br />
|source_dirs=js/src/jit<br />
|url=http://www.mozilla.org/js/spidermonkey<br />
|components=Core::JavaScript Engine: JIT<br />
}}<br />
<br />
{{Module<br />
|name=JavaScript Debugger Backend<br />
|description=JavaScript debugging hooks<br />
|owner=[mailto:timeless@mozdev.org Josh 'timeless' Soref]<br />
|peers=[mailto:brendan@mozilla.org Brendan Eich], [mailto:rginda@hacksrus.com Rob Ginda]<br />
|group=dev-apps-js-debugger<br />
|source_dirs=js/jsd/<br />
|url=http://www.mozilla.org/js/jsd<br />
|components=Other Applications::Venkman JS Debugger<br />
}}<br />
<br />
{{Module<br />
|name=js-ctypes<br />
|description=A foreign function interface which allows privileged JS code to interact with binary code without using XPCOM/XPConnect.<br />
|owner=[mailto:jorendorff@mozilla.com Jason Orendorff]<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:bobbyholley@gmail.com Bobby Holley]<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/src/ctypes/<br />
|url=https://wiki.mozilla.org/JSctypes<br />
|components=Core::js-ctypes<br />
}}<br />
<br />
{{Module<br />
|name=js-tests<br />
|description=JavaScript test suite<br />
|owner=[mailto:bclary@bclary.com Bob Clary]<br />
|peers=<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/tests/<br />
|url=http://www.mozilla.org/js/tests/library.html<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Layout Engine<br />
|description=rendering tree construction, layout (reflow), painting, etc.<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|peers=[mailto:roc+@cs.cmu.edu Robert O'Callahan], [mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:bmlk@gmx.de Bernd Mielke], [mailto:smontagu@smontagu.org Simon Montagu]<br />
|group=dev-tech-layout<br />
|source_dirs=layout/%, layout/base/, layout/build/, layout/doc/, layout/forms/, layout/generic/, layout/html/, layout/macbuild/, layout/printing/, layout/tables/, layout/tools/<br />
|url=http://mozilla.org/newlayout/doc/ ,<br />
http://lxr.mozilla.org/mozilla/source/layout/doc/<br />
|components=Core::Layout, Core::Layout: Block and Inline, Core::Layout: Floats, Core::Layout: Form Controls, Core::Layout: HTML Frames, Core::Layout: Images, Core::Layout: Misc Code, Core::Layout: R & A Pos, Core::Layout: Tables, Core::Layout: Text, Core::Layout: View Rendering<br />
}}<br />
<br />
{{Module<br />
|name=libjar<br />
|description=The JAR handling code (protocol handler, stream implementation, and zipreader/zipwriter).<br />
|owner=[mailto:tglek@mozilla.com Taras Glek]<br />
|peers=[mailto:mwu@mozilla.com Michael Wu]<br />
|group=dev-platform<br />
|source_dirs=modules/libjar<br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=MathML<br />
|description=MathML is a low-level specification for describing mathematics which provides a foundation for the inclusion of mathematical expressions in Web pages.<br />
|owner=[mailto:karlt+@karlt.net Karl Tomlinson]<br />
|peers=[mailto:roc+@cs.cmu.edu Robert O'Callahan]<br />
|group=dev-tech-mathml<br />
|source_dirs=layout/mathml/<br />
|url=http://www.mozilla.org/projects/mathml/<br />
|components=Core::MathML<br />
}}<br />
<br />
{{Module<br />
|name=mfbt<br />
|description=mfbt is a collection of headers, macros, data structures, methods, and other functionality available for use and reuse throughout all Mozilla code (including SpiderMonkey and Gecko more broadly).<br />
|owner=[mailto:jwalden@mit.edu Jeff Walden]<br />
|peers=[mailto:froydnj@mozilla.com Nathan Froyd], [mailto:Ms2ger@gmail.com Ms2ger], [mailto:mh+mozilla@glandium.org Mike Hommey]<br />
|group=dev-platform<br />
|source_dirs=mfbt/<br />
|url=<br />
|components=Core::MFBT<br />
}}<br />
<br />
{{Module<br />
|name=mozApps API & UI<br />
|description=Implementation of the navigator.mozApps API<br />
|owner=[mailto:fabrice@mozilla.com Fabrice Desré], [mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|peers=[mailto:myk@mozilla.org Myk Melez], [mailto:mar.castelluccio@studenti.unina.it Marco Castelluccio], [mailto:ferjmoreno@gmail.com Fernando Jiménez]<br />
|group=dev-webapi<br />
|source_dirs=dom/apps/, dom/interfaces/apps, product specific files implementing UI hooks.<br />
|url=<br />
|components=Core::DOM: Apps<br />
}}<br />
<br />
{{Module<br />
|name=mozilla-toplevel<br />
|description=The top level directory for the mozilla tree.<br />
|owner=[mailto:brendan@mozilla.org Brendan Eich]<br />
|peers=<br />
|group=<br />
|source_dirs=tools/README<br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Necko<br />
|description=The Mozilla Networking Library<br />
|owner=[mailto:pmcmanus@mozilla.com Patrick McManus]<br />
|peers=[mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:jduell.mcbugs@gmail.com Jason Duell], [mailto:honzab.moz@firemni.cz Honza Bambas], [mailto:brian@briansmith.org Brian Smith], [mailto:mnovotny@mozilla.com Michal Novotny], [mailto:hurley@mozilla.com Nick Hurley], [mailto:sworkman@mozilla.com Steve Workman]<br />
|group=dev-tech-network<br />
|source_dirs=netwerk/%, netwerk/base/, netwerk/build/, netwerk/cache/, netwerk/dns/, netwerk/locales/, netwerk/mime/, netwerk/protocol/, netwerk/resources/, netwerk/socket/, netwerk/streamconv/, netwerk/system/, netwerk/test/, netwerk/testserver/<br />
|url=http://www.mozilla.org/projects/netlib/, https://developer.mozilla.org/en/Necko<br />
|components=Core::Networking, Core::Networking: Cache, Core::Networking: Cookies, Core::Networking: FTP, Core::Networking: File, Core::Networking: HTTP, Core::Networking: JAR, Core::Networking: Websockets<br />
}}<br />
<br />
{{Module<br />
|name=NSPR<br />
|description=Netscape Portable Runtime<br />
|owner=[mailto:nelson@bolyard.com Nelson Bolyard], [mailto:wtc@google.com Wan-Teh Chang]<br />
|peers=[mailto:ted.mielczarek@gmail.com Ted Mielczarek]<br />
|group=dev-tech-nspr<br />
|source_dirs=nsprpub/<br />
|url=http://www.mozilla.org/projects/nspr/<br />
http://www.mozilla.org/projects/nspr/reference/html/<br />
http://www.mozilla.org/projects/nspr/release-notes/<br />
|components=NSPR<br />
}}<br />
<br />
{{Module<br />
|name=PDF<br />
|description=Rendering code to display documents encoded in the ISO 32000-1 `PDF' format.<br />
|owner=[mailto:cjones@mozilla.com Chris Jones], [mailto:gal@mozilla.com Andreas Gal]<br />
|peers=[mailto:aadib@mozilla.com Artur Adib], [mailto:bdahl@mozilla.com Brendan Dahl], [mailto:vnicolas@mozilla.com Vivien Nicolas]<br />
|group=dev-platform<br />
|source_dirs=media/pdf/<br />
|url=https://github.com/mozilla/pdf.js<br />
|components=Core::PDF<br />
}}<br />
<br />
{{Module<br />
|name=Plugins<br />
|description= NPAPI Plugin support.<br />
|owner=[mailto:joshmoz@gmail.com Josh Aas]<br />
|peers=[mailto:jst@mozilla.org Johnny Stenback], [mailto:roc+@cs.cmu.edu Robert O'Callahan], [mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:jmathies@mozilla.com Jim Mathies], [mailto:jschoenick@mozilla.com John Schoenick]<br />
|group=<br />
|source_dirs=dom/plugins/, modules/plugin/<br />
|url=https://wiki.mozilla.org/Plugins<br />
|components=Core::Java-Implemented Plugins, Core::Plug-ins<br />
}}<br />
<br />
{{Module<br />
|name=Preferences<br />
|description=Preference library<br />
|owner=vacant<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg]<br />
|group=dev-platform<br />
|source_dirs=modules/libpref/<br />
|url=<br />
|components=Core::Preferences: Backend<br />
}}<br />
<br />
{{Module<br />
|name=Privilege Manager<br />
|description="caps"<br />
|owner=[mailto:bobbyholley@gmail.com Bobby Holley]<br />
|peers=[mailto:brendan@mozilla.org Brendan Eich], [mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:dveditz@cruzio.com Dan Veditz], [mailto:jst@mozilla.org Johnny Stenback]<br />
|group=dev-tech-dom<br />
|source_dirs=caps/<br />
|url=http://www.mozilla.org/projects/security/components/index.html<br />
|components=Core::Security: CAPS<br />
}}<br />
<br />
{{Module<br />
|name=Push Notifications<br />
|description=Push is a way for application developers to send messages to their web applications.<br />
|owner=[mailto:doug.turner@gmail.com Doug Turner]<br />
|peers=[mailto:nsm.nikhil@gmail.com Nikhil Marathe], [mailto:justin.lebar@gmail.com Justin Lebar]<br />
|group=<br />
|source_dirs=dom/push<br />
|url=https://wiki.mozilla.org/WebAPI/SimplePush<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=PyXPCOM<br />
|description=The Python to XPCOM bridge.<br />
|owner=[mailto:toddw@activestate.com Todd Whiteman]<br />
|peers=[mailto:mhammond@skippinet.com.au Mark Hammond]<br />
|group=<br />
|source_dirs=extension/python<br />
|url=https://developer.mozilla.org/en/PyXPCOM<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Qt-based gfx and widget<br />
|description=Qt-based rendering and widget code<br />
|owner=[mailto:romaxa@gmail.com Oleg Romashin]<br />
|peers=[mailto:mozilla@rosenauer.org Wolfgang Rosenauer], [mailto:doug.turner@gmail.com Doug Turner]<br />
|group=dev-tech-widget<br />
|source_dirs=widget/qt/<br />
|url=<br />
|components=Core::Widget: Qt<br />
}}<br />
<br />
{{Module<br />
|name=RDF<br />
|description=<br />
|owner=[mailto:axel@pike.org Axel Hecht]<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg]<br />
|group=dev-tech-rdf<br />
|source_dirs=rdf/<br />
|url=http://www.mozilla.org/rdf/doc/<br />
|components=Core::RDF<br />
}}<br />
<br />
{{Module<br />
|name=security<br />
|description=Crypto/PKI code, including NSS (Network Security Services) and JSS (NSS for Java)<br />
|owner=[mailto:rrelyea@redhat.com Bob Relyea], [mailto:wtc@google.com Wan-Teh Chang]<br />
|peers=[mailto:emaldona@redhat.com Elio Maldonado], [mailto:bsmith@mozilla.com Brian Smith], [mailto:kaie@kuix.de Kai Engert], [mailto:ryan.sleevi@gmail.com Ryan Sleevi]<br />
|group=dev-tech-crypto<br />
|source_dirs=dbm/, security/coreconf/, security/dbm/, security/jss/, security/nss/, security/tinderbox/, security/tinderlight/<br />
|url=http://mozilla.org/projects/security/pki/<br />
|components=NSS, JSS, Core::Security, Core::Security: S/MIME<br />
}}<br />
<br />
{{Module<br />
|name=Security - Mozilla PSM Glue<br />
|description=Personal Security Manager<br />
|owner=[mailto:bsmith@mozilla.com Brian Smith]<br />
|peers=[mailto:honzab.moz@firemni.cz Honza Bambas], [mailto:dkeeler@mozilla.com David Keeler], [mailto:wtc@google.com Wan-Teh Chang]<br />
|group=dev-tech-crypto<br />
|source_dirs=security/manager/<br />
|url=<br />
|components=Core::Security: PSM, Core::Security: UI<br />
}}<br />
<br />
{{Module<br />
|name=storage<br />
|description=Storage APIs with a SQLite backend<br />
|owner=[mailto:mak77@bonardo.net Marco Bonardo]<br />
|peers=[mailto:bugmail@asutherland.org Andrew Sutherland], [mailto:bent.mozillla@gmail.com Ben Turner]<br />
|group=dev-platform<br />
|source_dirs=db/sqlite3/, storage/<br />
|url=http://developer.mozilla.org/en/docs/Storage<br />
|components=Toolkit::Storage, Core::SQL<br />
}}<br />
<br />
{{Module<br />
|name=String<br />
|description=<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:jlebar@mozilla.com Justin Lebar]<br />
|group=dev-tech-xpcom<br />
|source_dirs=string/, xpcom/string/<br />
|url=https://developer.mozilla.org/En/Mozilla_internal_string_guide<br />
|components=Core::String<br />
}}<br />
<br />
{{Module<br />
|name=Style System<br />
|description=CSS style sheet handling; style data computation<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky]<br />
|group=dev-tech-layout<br />
|source_dirs=layout/style/<br />
|url=https://wiki.mozilla.org/Gecko:Overview#Style_System<br />
|components=Core::CSS Parsing and Computation<br />
}}<br />
<br />
{{Module<br />
|name=SVG<br />
|description=Scalable Vector Graphics<br />
|owner=[mailto:jwatt@jwatt.org Jonathan Watt]<br />
|peers=[mailto:longsonr@gmail.com Robert Longson], [mailto:roc+@cs.cmu.edu Robert O'Callahan], [mailto:dholbert@mozilla.com Daniel Holbert], [mailto:birtles@gmail.com Brian Birtles]<br />
|group=dev-tech-svg<br />
|source_dirs=content/svg/, layout/svg/, content/smil/<br />
|url=https://developer.mozilla.org/en-US/docs/Web/SVG<br />
|components=Core::SVG<br />
}}<br />
<br />
{{Module<br />
|name=Tamarin<br />
|description=VM for ActionScript and JavaScript<br />
|owner=[mailto:edwsmith@adobe.com Edwin Smith], [mailto:jodyer@adobe.com Jeff Dyer]<br />
|peers=[mailto:brendan@mozilla.org Brendan Eich], [mailto:stejohns@adobe.com Steven Johnson], [mailto:tierney@adobe.com Erik Tierney], [mailto:treilly@adobe.com Tom Reilly]<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/tamarin<br />
|url=http://www.mozilla.org/projects/tamarin/<br />
http://wiki.mozilla.org/tamarin/<br />
http://hg.mozilla.org/tamarin-central/<br />
http://hg.mozilla.org/tamarin-tracing/<br />
|components=Tamarin<br />
}}<br />
<br />
{{Module<br />
|name=Test Harness<br />
|description=In-tree test infrastructure and tools. Harnesses include, XPCShell, Mochitest (& Chrome), Reftest, JsREftest, Compiled Code Tests, Robocop, Mozmill and Marionette. Requests for new harnesses should go to Testing::General.<br />
|owner=[mailto:ted@mozilla.com Ted Mielczarek]<br />
|peers=[mailto:dbaron@dbaron.org David Baron] (reftest), [mailto:jwalden@mit.edu Jeff Walden] (httpd.js, jsreftest), [mailto:rcampbell@mozilla.com Rob Campbell] (mochitest, mochitest chrome, marionette), [mailto:jmaher@mozilla.com Joel Maher] (reftest, mochitest, jsreftest), [mailto:ctalbert@mozilla.com Clint Talbert] (reftest, compiled code, mozmill), [mailto:geoffbrown@mozilla.com Geoff Brown] (robocop), [mailto:hskupin@mozilla.com Henrik Skupin] (mozmill), [mailto:mdas@mozilla.com Malini Das] (marionette), [mailto:jgriffin Jonathan Griffin] (marionette), [mailto:dburns@mozilla.com David Burns] (marionette) [mailto:dminor@mozilla.com Dan Minor]<br />
|group=dev-quality<br />
|source_dirs=/testing<br />
|url=http://wiki.mozilla.org/SoftwareTesting<br />
|components=Testing::General, Testing::Mochitest, Testing::Mochitest Chrome, Testing::Marionette, Testing::Mozmill, Testing::Reftest, Testing::XPCShell Harness, Testing::httpd.js<br />
}}<br />
<br />
{{Module<br />
|name=Testing Infrastructure<br />
|description=Testing tools and infrastructure for Mozilla projects, harnesses for automated tests, stand-alone test tools. Talos, Graph Server, Mozbase, Pulse, WOO, Bughunter, SUTAgent, Eideticker<br />
|owner=[mailto:jmaher@mozilla.com Joel Maher]<br />
|peers=[mailto:bclary@bclary.com Bob Clary], [mailto:bhearsum@mozilla.com Ben Hearsum], [mailto:ccooper@deadsquid.com Chris Cooper], [mailto:ctalbert@mozilla.com Clint Talbert], [mailto:robert@roberthelmer.com Robert Helmer], [mailto:jmaher@mozilla.com Joel Maher], [mailto:rcampbell@mozilla.com Rob Campbell], [mailto:wlach@mozilla.com William Lachance], [mailto:jeads@mozilla.com Jonathan Eads], [mailto:jgriffin Jonathan Griffin], [mailto:bmoss@mozilla.com Bob Moss], [mailto:mcote@mozilla.com Mark Côté]<br />
|group=dev-quality<br />
|source_dirs=testing/, tools/httptester/, tools/page-loader/, tools/test-harness/, tools/tests/, tools/testserver/, tools/testy/<br />
|url=http://wiki.mozilla.org/SoftwareTesting<br />
|components=Testing::Infrastructure<br />
}}<br />
<br />
{{Module<br />
|name=JS Marionette Harness and Tools<br />
|description=Test harness and associated tools for running marionette tests on NodeJS (submodule of Test Infrastructure)<br />
|owner=[mailto:jlal@mozilla.com James Lal] <lightsofapollo>, [mailto:gaye@mozilla.com Gareth Aye] <gaye><br />
|peers=[mailto:aus@mozilla.com Ghislain "Aus" Lacroix] <auswerk>, [mailto:mike@bocoup.com Mike Pennisi] <jugglinmike>, [mailto:evanxd@mozilla.com Evan Tseng] <evanxd><br />
|source_dirs=These are all mozilla-b2g github repos: [https://github.com/mozilla-b2g/marionette-js-runner Marionette JS Runner], [https://github.com/mozilla-b2g/mocha-json-proxy Mocha JSON Proxy], [https://github.com/mozilla-b2g/mocha-tbpl-reporter Mocha TBPL Reporter], [https://github.com/mozilla-b2g/marionette-js-client Marionette JS Client], [https://github.com/mozilla-b2g/sockit-to-me Sockit To Me], [https://github.com/mozilla-b2g/marionette-apps Marionette Apps], [https://github.com/mozilla-b2g/marionette-js-logger Marionette JS Logger], [https://github.com/mozilla-b2g/marionette-b2gdesktop-host Marionette B2G Desktop Host], [https://github.com/mozilla-b2g/marionette-firefox-host Marionette Firefox Host], [https://github.com/mozilla-b2g/marionette-profile-builder Marionette Profile Builder], [https://github.com/mozilla-b2g/mozilla-profile-builder Mozilla Profile Builder]<br />
|components=Testing::JSMarionette<br />
|group=dev-gaia<br />
}}<br />
<br />
{{Module<br />
|name=XPCShell Test Harness<br />
|description=The XPCShell Harness<br />
|owner=[mailto:ted.mielczarek@gmail.com Ted Mielczarek]<br />
|peers=[mailto:jmaher@mozilla.com Joel Maher]<br />
|source_dirs=testing/xpcshell<br />
|components=Testing::XPCShell Harness<br />
}}<br />
<br />
{{Module<br />
|name=Update Service<br />
|description=server code for Mozilla Update services (aus, addons, pfs)<br />
|owner=[mailto:morgamic@mozilla.com Mike Morgan]<br />
|peers=[mailto:jscott@mozilla.com Justin Scott], [mailto:shaver@mozilla.org Mike Shaver], [mailto:wclouser@mozilla.com Will Clouser]<br />
|group=dev-amo<br />
|source_dirs=webtools/addons/, webtools/aus/, webtools/update/<br />
|url=http://wiki.mozilla.org/wiki/AMO<br />
|components=AUS::Administration, AUS::Systems<br />
}}<br />
<br />
{{Module<br />
|name=View System<br />
|description=The View Manager is responsible for handling "heavyweight" rendering (some clipping, compositing) and event handling tasks.<br />
|owner=[mailto:roc+@cs.cmu.edu Robert O'Callahan]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:dbaron@dbaron.org David Baron]<br />
|group=dev-tech-layout<br />
|source_dirs=view/<br />
|url=<br />
|components=Core::Layout: View Rendering<br />
}}<br />
<br />
{{Module<br />
|name=Web Audio<br />
|description=Support for the W3C Web Audio API specification.<br />
|owner=[mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|peers=[mailto:roc+@cs.cmu.edu Robert O'Callahan], [mailto:padenot@mozilla.com Paul Adenot]<br />
|group=dev-platform<br />
|source_dirs=content/media/webaudio<br />
|url=https://wiki.mozilla.org/Web_Audio_API<br />
|components=Core::Web Audio<br />
}}<br />
<br />
{{Module<br />
|name=WebRTC<br />
|description=WebRTC is responsible for realtime audio and video communication, as well as related issues like low-level camera and microphone access (on desktop at least)<br />
|owner=[mailto:rjesup@mozilla.com Randell Jesup]<br />
|peers=[mailto:ekr@mozilla.com Eric Rescorla], [mailto:ehugg@cisco.com Ethan Hugg], [mailto:tterriberry@mozilla.com Tim Terriberry], [mailto:anant@mozilla.com Anant Narayanan]<br />
|group=dev-media<br />
|source_dirs=media/webrtc<br />
|url=https://wiki.mozilla.org/Media/webrtc<br />
|components=Core::WebRTC, Core::WebRTC (Audio/Video), Core::WebRTC (Networking), Core::WebRTC (Signaling)<br />
}}<br />
<br />
{{Module<br />
|name=Widget<br />
|description=<br />
|owner=[mailto:roc+@cs.cmu.edu Robert O'Callahan]<br />
|peers=[mailto:pavlov@pavlov.net Stuart Parmenter], [mailto:vladimir@pobox.com Vladimir Vukicevic]<br />
|group=dev-platform<br />
|source_dirs=widget/%, widget/public/, widget/%, widget/xpwidgets/<br />
|url=<br />
|components=Core::Drag and Drop, Core::Widget<br />
}}<br />
<br />
{{Module<br />
|name=Widget - Android<br />
|description=The Android Port<br />
|owner=[mailto:blassey.bugs@lassey.us Brad Lassey]<br />
|peers=[mailto:jwillcox@mozilla.com James Willcox]<br />
|group=dev-platforms-mobile<br />
|source_dirs=widget/android/, embedding/android<br />
|url=<br />
|components=Core::Widget: Android<br />
}}<br />
<br />
{{Module<br />
|name=Widget - GTK<br />
|description=supported X widgetry and gfx<br />
|owner=[mailto:roc+@cs.cmu.edu Robert O'Callahan]<br />
|peers=[mailto:karlt+@karlt.net Karl Tomlinson]<br />
|group=dev-platform<br />
|source_dirs=widget/gtk/, widget/gtk2/, widget/gtksuperwin/, widget/gtkxtbin/<br />
|url=http://www.mozilla.org/unix/, http://www.gtk.org, http://www.mozilla.org/ports/gtk/<br />
|components=Core::Widget: Gtk<br />
}}<br />
<br />
{{Module<br />
|name=Widget - OS X<br />
|description= Gecko's OS X compatibility layer.<br />
|owner=[mailto:smichaud@pobox.com Steven Michaud]<br />
|peers=[mailto:joshmoz@gmail.com Josh Aas], [mailto:mstange@themasta.com Markus Stange], [mailto:bgirard@mozilla.com Benoit Girard], [mailto:spohl@mozilla.com Stephen Pohl]<br />
|group=dev-platform<br />
|source_dirs=widget/cocoa/<br />
|url=<br />
|components=Core::Widget: Cocoa<br />
}}<br />
<br />
{{Module<br />
|name=Widget - Windows<br />
|description=Windows widgets and desktop integration<br />
|owner=[mailto:jmathies@mozilla.com Jim Mathies]<br />
|peers=[mailto:blassey@mozilla.com Brad Lassey], [mailto:netzen@gmail.com Brian Bondy], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:dougt@meer.net Doug Turner], [mailto:neil@parkwaycc.co.uk Neil Rashbrook], [mailto:robarnold@cmu.edu Rob Arnold], [mailto:timeless@mozdev.org Josh 'timeless' Soref], [mailto:vladimir@pobox.com Vladimir Vukicevic]<br />
|group=dev-platform<br />
|source_dirs=widget/windows/<br />
|url=<br />
|components=Core::Widget: Win32<br />
}}<br />
<br />
{{Module<br />
|name=XBL<br />
|description=eXtensible Binding Language<br />
|owner=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:jonas@sicking.cc Jonas Sicking]<br />
|peers=[mailto:mrbkap@gmail.com Blake Kaplan], [mailto:bobbyholley@gmail.com Bobby Holley]<br />
|group=dev-tech-xbl<br />
|source_dirs=content/xbl/%, content/xbl/public/, content/xbl/src/<br />
|url=http://www.mozilla.org/projects/xbl/<br />
|components=Core::XBL<br />
}}<br />
<br />
{{Module<br />
|name=XML<br />
|description=XML in Mozilla, including XML, XHTML, Namespaces in XML, Associating Style Sheets with XML Documents, XML Linking and XML Extras. XML-related things that are not covered by more specific projects.<br />
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:jonas@sicking.cc Jonas Sicking], [mailto:jst@mozilla.org Johnny Stenback]<br />
|group=dev-tech-xml<br />
|source_dirs=content/xml/, extensions/xmlextras/, parser/expat/<br />
|url=http://www.mozilla.org/newlayout/xml/<br />
|components=Core::XML<br />
}}<br />
<br />
{{Module<br />
|name=XPApps<br />
|description=Cross-Platform Applications, mostly Navigator front end and application shell.<br />
|owner=[mailto:neil@parkwaycc.co.uk Neil Rashbrook]<br />
|peers=[mailto:dean_tessman@hotmail.com Dean Tessman], [mailto:jag@tty.nl Peter Annema], [mailto:timeless@mozdev.org Josh 'timeless' Soref]<br />
|group=dev-apps-seamonkey<br />
|source_dirs=xpfe/<br />
|url=http://www.mozilla.org/xpapps/<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=XPCOM<br />
|description=The cross-platform object model and core data structures.<br />
|owner=[mailto:benjamin@smedbergs.us Benjamin Smedberg]<br />
|peers=[mailto:dougt@meer.net Doug Turner], [mailto:froydnj@mozilla.com Nathan Froyd]<br />
|group=dev-platform<br />
|source_dirs=startupcache/, xpcom/%, xpcom/base/, xpcom/build/, xpcom/components/, xpcom/ds/, xpcom/glue/, xpcom/proxy/, xpcom/sample/, xpcom/stub/, xpcom/tests/, xpcom/threads/, xpcom/tools/, xpcom/windbgdlg/<br />
|url=http://developer.mozilla.org/en/XPCOM<br />
|components=Core::XPCOM<br />
}}<br />
<br />
{{Module<br />
|name=XPConnect<br />
|description=Deep Magic<br />
|owner=[mailto:bobbyholley@gmail.com Bobby Holley]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:gal@uci.edu Andreas Gal], [mailto:jst@mozilla.org Johnny Stenback], [mailto:peterv@propagandism.org Peter Van der Beken], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:gkrizsanits@mozilla.com Gabor Krizsanits]<br />
|group=<br />
|source_dirs=js/xpconnect/<br />
|url=<br />
|components=Core::XPConnect<br />
}}<br />
<br />
{{Module<br />
|name=XPIDL<br />
|description=Cross-platform IDL compiler; produces .h C++ header files and .xpt runtime type description files from .idl interface description files.<br />
|owner=[mailto:me@kylehuey.com Kyle Huey]<br />
|peers=[mailto:shaver@mozilla.org Mike Shaver], [mailto:timeless@mozdev.org Josh 'timeless' Soref]<br />
|group=dev-tech-xpcom<br />
|source_dirs=xpcom/typelib/<br />
|url=http://www.mozilla.org/scriptable/xpidl<br />
http://www.mozilla.org/scriptable<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=XPInstall<br />
|description=<br />
|owner=[mailto:dveditz@cruzio.com Dan Veditz]<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg]<br />
|group=dev-tech-xpinstall<br />
|source_dirs=xpinstall/<br />
|url=<br />
|components=Core::Installer: XPInstall Engine<br />
}}<br />
<br />
{{Module<br />
|name=xptcall<br />
|description=XPTCall - platform-specific assembly for calling and implementing arbitrary XPCOM interfaces.<br />
|owner=[mailto:timeless@mozdev.org Josh 'timeless' Soref]<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:shaver@mozilla.org Mike Shaver]<br />
|group=dev-xpcom<br />
|source_dirs=xpcom/reflect/xptcall/<br />
|url=http://www.mozilla.org/scriptable/xptcall-faq.html<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=XPToolkit<br />
|description=Cross-platform user interface toolkit<br />
|owner=<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:hyatt@mozilla.org Dave Hyatt], [mailto:jag@tty.nl Peter Annema], [mailto:Jan.Varga@gmail.com Jan Varga]<br />
|group=dev-tech-xul<br />
|source_dirs=content/xul/, layout/xul/<br />
|url=http://www.mozilla.org/xpfe/<br />
|components=Core::XP Toolkit/Widgets: Menus, Core::XP Toolkit/Widgets: XUL<br />
}}<br />
<br />
{{Module<br />
|name=XSLT Processor<br />
|description=XSLT transformations processor<br />
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]<br />
|peers=[mailto:axel@pike.org Axel Hecht], [mailto:jonas@sicking.cc Jonas Sicking]<br />
|group=dev-tech-xslt<br />
|source_dirs=content/xslt/<br />
|url=http://www.mozilla.org/projects/xslt/, http://www.w3.org/TR/xslt.html<br />
|components=Core::XSLT<br />
}}<br />
<br />
{{Module<br />
|name=XTF<br />
|description=eXtensible Tag Framework<br />
|owner=<br />
|peers=[mailto:alex@croczilla.com alex@croczilla.com], [mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:jonas@sicking.cc Jonas Sicking]<br />
|group=dev-tech-xbl<br />
|source_dirs=content/xtf/, layout/xtf/<br />
|url=http://www.croczilla.com/bits_and_pieces/xtf/<br />
|components=Core::XTF<br />
}}<br />
<br />
===Submodules===<br />
{{Module<br />
|name=Build Config - Fennec<br />
|description=Submodule of the build config covering Fennec's build system in mobile/android.<br />
|owner=[mailto:gps@mozilla.com Gregory Szorc]<br />
|peers=Same as Build Config plus [mailto:nalexander@mozilla.com Nicholas Alexander].<br />
|group=dev-builds<br />
|components=Core::Build Config<br />
}}<br />
<br />
<noinclude><br />
<br />
===Unassigned Bugzilla Components===<br />
<br />
The following Bugzilla components in the Core project have not been assigned to a module (this list is not exhaustive):<br />
<br />
<pre><br />
Core::Event Handling<br />
Core::File Handling<br />
Core::Find Backend<br />
Core::Gecko Profiler<br />
Core::General<br />
Core::HTML: Form Submission<br />
Core::History: Global<br />
Core::Identity<br />
Core::Image Blocking<br />
Core::JavaScript Debugging APIs<br />
Core::Localization<br />
Core::Nanojit<br />
Core::Networking: Domain Lists<br />
Core::Print Preview<br />
Core::Printing: Output<br />
Core::Printing: Setup<br />
Core::Profile: BackEnd<br />
Core::Profile: Migration<br />
Core::Profile: Roaming<br />
Core::QuickLaunch (AKA turbo mode)<br />
Core::Rewriting and Analysis<br />
Core::Selection<br />
Core::Serializers<br />
Core::Spelling checker<br />
Core::Tracking<br />
Core::Video/Audio<br />
Core::Web Services<br />
Core::WebDAV<br />
Core::Widget: OS/2<br />
Core::Widget: Photon<br />
Core::X-remote<br />
Core::XForms<br />
Core::XUL<br />
Core::jemalloc<br />
</pre><br />
</noinclude></div>Sickinghttps://wiki.mozilla.org/index.php?title=WebAPI/WidgetAPI&diff=989082WebAPI/WidgetAPI2014-06-16T02:38:17Z<p>Sicking: </p>
<hr />
<div>== Goals ==<br />
The widget API allows privileged application have ability to embed other applications in their own iframe, e.g. homescreen, lockscreen ....etc.<br />
<br />
== Use case ==<br />
== Proposal ==<br />
=== extend manifest.webapp ===<br />
An application exposes its widget view via declaring details of widget in mainfest.<br />
<br />
{<br />
name: "MyApp2000",<br />
...<br />
widgets: {<br />
"mywidget1": {<br />
href: "widget.html",<br />
description: "This is my cool widget",<br />
screenshot: "foo.jpg"<br />
},<br />
"myotherwidget": { ... }<br />
}<br />
widgetPages: [<br />
"widget.html",<br />
"news_reader_settings.html",<br />
"some_other_page.html"<br />
]<br />
}<br />
<br />
=== embed-widgets {{bug|1005818}} ===<br />
In order to expose to privileged APPs and consider security issue.<br />
<br />
* "embed-widgets" is a new permission for "mozapp" attribute, it comes from [https://developer.mozilla.org/en-US/Apps/Build/App_permissions#embed-apps 'embed-apps'] but is more restricted. Please refer to [https://wiki.mozilla.org/WebAPI/WidgetAPI#Browser_API next section].<br />
* Set manifest entry in "widget" attribute. <br />
<iframe mozbrowser=“true" mozwidget="manifestURL" src=“widget.html” remote=“true”> <br />
<br />
=== permission requirements ===<br />
*embed-widgets<br />
*homescreen-webapp-manage ({{bug|899994}}, {{bug|1000313}})<br />
*browser-api (combine with embed-widget would be downgrade )<br />
<br />
==== Restriction ====<br />
*Disallow SRC attribute.<br />
*Disallow parts of security sensitive browser API<br />
*Ignore mozLockOrientation/mozUnlockOrientation<br />
==== examples ====<br />
*APP:<br />
<iframe mozbrowser=“true" mozapp=“manifestURL” remote=“true” src=“appURL”><br />
<br />
*Widget:<br />
**Disallow “src" attribute.<br />
<iframe mozbrowser=“true" mozapp=“manifestURL" widget=“widgetEntry” remote=“true”> <br />
<br />
*Open Bookmark:<br />
//browser (full-set)<br />
<iframe mozbrowser=“true" remote="true" src="http://example.com"><br />
<br />
==Issues under discussion==<br />
===[https://developer.mozilla.org/zh-TW/docs/WebAPI/Browser#.E5.AD.98.E5.8F.96_%28Navigation%29_.E5.87.BD.E5.BC.8F Browser API]===<br />
Need to clarify which methods/Events are safe or unsafe.<br />
<br />
==== Not security sensitive ====<br />
*Performance methods<br />
**setVisible()<br />
**getVisible()<br />
<br />
*Event methods<br />
**addNextPaintListener()<br />
**removeNextPaintListener()<br />
<br />
*Events<br />
**mozbrowserasyncscroll<br />
**mozbrowserclose<br />
**mozbrowsererror<br />
**mozbrowserloadend<br />
**mozbrowserloadstart<br />
<br />
==== Security sensitive ====<br />
*Event methods<br />
**sendMouseEvent() - cross-origin interaction, can cause unexpected actions in web apps<br />
**sendTouchEvent() - cross-origin interaction, can cause unexpected actions in web apps<br />
<br />
*getScreenshot()<br />
<br />
*Events<br />
**mozbrowserusernameandpasswordrequired - leaks host and realm<br />
**mozbrowseropenwindow (i.e. window.open)<br />
**mozbrowsershowmodalprompt (i.e. alert(), confirm(), prompt())<br />
**mozbrowsercontextmenu<br />
**mozbrowsersecuritychange - can tell is page is https or not<br />
**mozbrowserlocationchange - discloses URL (can contain secrets)<br />
**mozbrowsericonchange - discloses the icon URL. Might be a privacy issue.<br />
**mozbrowsertitlechange - discloses title, privacy issue.<br />
**mozbrowseropensearch - I assume this discloses the link value, maybe a privacy issue?<br />
<br />
=== no use case ===<br />
*Navigation methods <br />
**<strike>reload()</strike><br />
**<strike>stop()</strike><br />
**<strike>getCanGoBack()</strike><br />
**<strike>goBack()</strike><br />
**<strike>getCanGoForward()</strike><br />
**<strike>goForward()</strike><br />
*Performance methods<br />
**<strike>purgeHistory()</strike><br />
<br />
==Q&A==<br />
* Why we don't use 'src' to specify launch path?<br />
** A security concern: widget embedder may embed a file which is not allowed by widget to be opened in widget mode.<br />
<br />
* Why we need an app to explicitly expose its widget view? Is there any use case that an app doesn't want to be opened as a widget?<br />
** The app thinks its function can't be performed in widget mode, like lockscreen app or camera app.<br />
** Just doesn't want itself to be embeded by other apps for various concerns, like Facebook app or bank apps.<br />
<br />
* So I can't specify a 'src', how to open a bookmarked web page as a widget? Web pages don't have a manifest to expose its widget view.<br />
** No, you can't. We don't have a better solution for "initially" loading a 'http://' path within a widget. However, the topic is under discussion, we are trying to find out a solution.<br />
<br />
* Is it possible to navigate to an external link within a widget?<br />
** It should be fine to navigate an external link within a widget because window.location is changed by widget itself under its window context, not caused by the widget embedder.<br />
<br />
* May a widget request to enlarge itself to full screen as its app mode?<br />
** No, we don't have a better idea for this case now. Issues like how to force homescreen app to deal with the the resize event requested by widget, how to update mozbrowser iframe attributes to indicate the frame is in app mode...<br />
<br />
* Some apps want to app.launch() its app mode while user click its widget, but some want to be enlarged. Is there a way to specify?<br />
** We may introduce an attribute in manifest which tells widget embedder how to process the enlarging behavior. But we have to discuss it with Web API team.<br />
<br />
<br />
==Bugs==<br />
* {{bug|1005818}} A new 'embed-widgets' permission exposing to privileged apps for solving widget case.<br />
** Part1: Add permission "embed-widgets" and HTMLIFrameElement attribute "mozWidget"<br />
** Part2: Implementation of checking if a window is able to embed a specific widget.<br />
** Part3: Enable to embed a widget if preconditions hold<br />
** Part4: Only limited browser API are available to a widget</div>Sickinghttps://wiki.mozilla.org/index.php?title=WebAPI/WebActivities/LessonsLearned&diff=977861WebAPI/WebActivities/LessonsLearned2014-05-17T00:19:00Z<p>Sicking: /* Differences between "data sources" and activities/intents */</p>
<hr />
<div><br />
Based on internal experience, as well as experience talking with other partners like Google and Pocket, we have learned a lot about how to design the next iteration of WebActivities.<br />
<br />
Below I'll use the term 'app' not to refer to a Android/iOS installed app, but rather to the generic concept of a webapp.<br />
<br />
To simplify the discussion, here's two standard flows when using WebActivities<br />
<br />
'''Using an activity that returns a value'''<br />
# User launches facebook<br />
# User clicks "attach a picture"<br />
# Facebook launches the "pick" WebActivity<br />
# The activity picker comes up.<br />
# User chooses to use the camera app as activity handler<br />
# Camera app is launched<br />
# User takes a picture<br />
# Camera app returns the picture as result of the activity<br />
# Camera app is closed and user is back in facebook app.<br />
<br />
'''Using an activity that does not return a value'''<br />
# User goes to news website and finds an interesting article<br />
# User clicks "share" button<br />
# News website lauches the "share" WebActivity<br />
# The activity picker comes up.<br />
# User chooses to use the twitter app as activity handler<br />
# Twitter app is launched<br />
# Twitter app prefills URL of news article as tweet content<br />
# User writes short message to go along with the URL and submits the tweet<br />
<br />
== UX issues with activities that return a value ==<br />
<br />
In FirefoxOS, if the user in step 7 of the ''returns a value'' flow temporarily switches app, for example to look something up, or to answer an incoming phone call, then the activity is aborted and facebook receives an error message. We were forced to do this in order to deal with the situation when the user might switch back to the facebook app, in which case we didn't want to force facebook to deal with having to implement a sensible UI while the activity was still in progress. However aborting the activity just because the user looked something up is obviously bad.<br />
<br />
In Chrome's Web Intents, step 6 of ''returns a value'' flow launches the camera app in a separate tab in the browser. That creates an awkward relationship between the tab with the facebook app and the tab with camera app. In particular, if the user closes the facebook tab, then when the picture is taken, it's dropped on the floor since there is no facebook app to receive it.<br />
<br />
'''Recommended solutions'''<br />
<br />
For activities that return a value, the activity handler should be overlayed on top of the initiating app. I.e. in the example above the camera app should be rendered on top of the facebook app.<br />
<br />
In a small-screen device this means that the application switcher shouldn't display facebook and the camera as two separate apps currently running. Instead only the facebook app should be listed, though possibly the UI could somehow indicate that the facebook app is currently using the camera app or some such. Switching to the facebook app should render the camera app on top of it.<br />
<br />
On a large-screen device with a traditional tabbed browser UI, the camera app should be rendered in the same tab as the facebook app. I.e. the camera app would be on top of the facebook app.<br />
<br />
== UX issues with opening in activities in a new app/tab ==<br />
<br />
In FirefoxOS a webactivity always launches a new fullscreen app. This makes activities always have a fairly heavy flow since it involves two app switches, one to the activity handler, and one to switch back to the original app.<br />
<br />
Activity handlers that want to implement things like "save this for later" or "share on my photo stream" only needs to display minimal UI that doesn't take the user out of the current app.<br />
<br />
'''Recommended solutions'''<br />
<br />
We should implement a "disposition: 'inline'" like what Web Intents has. This is already specified for WebActivities but was never implemented. An inline handler would be rendered like a "dialog" on top of the current app.<br />
<br />
On large-screen devices this likely means that it sizes to content. On small-screen devices this might simply mean that it doesn't take up the full screen.<br />
<br />
Pocket also has dome some really great research [https://docs.google.com/a/readitlater.com/document/d/1S5TnrCMrtaYqPTSK3YUIE-6shWSvRONdEhm74rW7CrE/edit here].<br />
<br />
This research proposes even allowing overlays that render directly on top of the initiating app. This provides for some pretty awesome UI, but also exposes issues like clickjacking. Ideally disposition:inline can bring most of the benefits of this proposal, while still not exposing clickjacking risks.<br />
<br />
== UX issues if the handler app is already running when the activity is launched ==<br />
<br />
In FirefoxOS's implementation of WebActivities, if the twitter app was already running in the background when the ''does not return a value'' flow happens, we switch to the twitter app and send a message to it and ask it to handle the activity. However this means that the app has to leave it's current state in order to do so. So if the user was in the middle of some other task within the twitter app, that is now lost.<br />
<br />
'''Recommended solutions'''<br />
<br />
If we follow the recommendation above for [[#UX issues with activities that return a value|UX issues with activities that return a value]] that actually solves the problem for activities that return a value. A new page will always be opened and rendered on top of the app that initiated the activity.<br />
<br />
Likewise disposition:inline activities will also not suffer this problem since they open a new page inside the inline UI on top of the page that initiated the activity.<br />
<br />
For other activity handlers a good default is likely to always open a new tab to handle the activity.<br />
<br />
But we could also enable handing an activity using an existing page by allowing using a ServiceWorker as activity handler, and then allow the service worker to delegate to an already open page. Possibly we could even allow the ServiceWorker to open a disposition:inline activity.<br />
<br />
== Lack of ability to save intermediate results ==<br />
<br />
Consider a "Google Drive" app that uses an "edit" activity to launch a "photoshop" app in order to edit a picture file.<br />
<br />
In the current WebActivities and Web Intents implementations, the only way to accomplish this would be to have the photoshop "edit" activity handler return the edited image once the user was done editing, and then have the Google Drive app save the resulting file.<br />
<br />
There are a couple of issues with this flow though. First off given that the activity would be one returning a value, the photoshop app would have to be opened on top of Google Drive. This isn't always desirable.<br />
<br />
A bigger problem is that photoshop would not be able to save intermediate drafts to the Google Drive app. It would either not save them at all, which means risking more dataloss in case of a crash or accidentally closing the app, or it would have to save them somewhere in photoshop's storage area. In case of crash it would be awkward to get the edited data back into Google drive. The user would have to relaunch the edit activity and select photoshop again, and then photoshop would have to detect that the same file was being edited and offer to reuse the previously saved draft.<br />
<br />
A desired flow here is instead to enable Google Drive to launch the "edit" activity such that Photoshop could be opened in a new window. But also enable Photoshop to have an open communication channel back to Google Drive. However the user should be able to close the Google Drive tab while still enabling Photoshop to send data to Google Drive in order to save intermediate drafts.<br />
<br />
'''Recommended solutions'''<br />
<br />
When launching an activity, it should be possible to also provide "back channel" information. If provided, the activity handler would be able to postMessage arbitrary information back to the app that initiated the activity.<br />
<br />
These messages would likely need to be sent not to the execution context that initiated the activity, but rather to its Service Worker. This way messages can be sent even if the execution context that initiated the activity has been closed.<br />
<br />
The app initiating the activity would also need to provide some arbitrary data which is passed back any time messages are sent from the activity handler and which can't be altered by the activity handler. In the example above the Google Drive app could provide the filename of the file being edited.<br />
<br />
== Ability to switch from inline to full-window handler ==<br />
<br />
A disposition:inline handler might need to defer to a more complex UI depending on user actions. For example a facebook "share" handler might start as an inline handler, but need to switch to a more complex UI if the user wants to configure security settings or add complex data to the post.<br />
<br />
This gets especially tricky for activity handlers that return a value. In this case the full-window handler would need to be rendered on top of the current app, I.e. it couldn't be handled like a normal window.open with target=_blank. Additionally the new page needs to take over the responsibility of returning a value.<br />
<br />
'''Recommended solutions'''<br />
<br />
Sadly I don't have any recommendations here. Possibly simply not supporting this scenario is the right solution for now. Instead we can allow a display:inline handler to resize itself to handle the more complex UI.<br />
<br />
What might help is to force this scenario to be handled by allowing a ServiceWorker to handle the activity and then allowing the ServiceWorker to open inline or full-window handlers on top of the initiating app.<br />
<br />
Activity handlers that don't return a value can always open new pages using target=_blank links or window.open calls.<br />
<br />
== Should activity launcher have a say in the disposition of the handler? ==<br />
<br />
''This is mostly based on notes from a WebActivities/Web Intents discussion. I sadly don't remember all the details here.''<br />
<br />
For activities that do not return a value, the initiating app might want to treat launching the activity handler as either a "navigation" or as a "open in new tab".<br />
<br />
In the Google Drive/Photoshop example above, it seems like it should be the decision of the Google Drive app if Photoshop should replace the Google Drive app, or if opening Photoshop should be treated like opening a <tt>&lt;a target="_blank"&gt;</tt> link.<br />
<br />
'''Recommended solutions'''<br />
<br />
We could support a ''target'' attribute when initiating an activity. The target would be ignored for activities that return a value, and possibly also for disposition:inline activities. However I don't know of use cases which involve targeting named windows, so possibly a ''target'' attribute is too generic.<br />
<br />
Another question is if it should be possible to target _self if the current page is open in an iframe. I.e. should activity handlers need to worry about possibly being opened in a subframe?<br />
<br />
== Finding activity handlers that match a given activity request ==<br />
<br />
When an activity is initiated we want to fairly quickly bring up a list of apps that are able to handle the activity. In WebActivities we allow activity handlers to provide an object which describes a filter which the activity data is matched against.<br />
<br />
However it's proven pretty hard to find a format to express these filters. For example for the "pick" activity if an application asks for a picture it could do that either by specifying any of <tt>type: 'image/*'</tt>, <tt>type: 'image/gif'</tt> or <tt>type: 'image/jpg'</tt>. So any activity handler for the "pick" activity that can provide an picture has to enumerate at least all of those types. And it also has to make sure that its filter matches if no specific type is requested.<br />
<br />
Another problem is that if a contact-manager app provides a handler for the "pick" activity in order to allow the user to choose a contact when a contact is explicitly requested, but not come up when the "pick" activity is activated to select an arbitrary file, i.e. when no <tt>type</tt> is specified.<br />
<br />
'''Recommended solutions'''<br />
<br />
It's possible that WebActivities' current filter mechanism actually can handle most use cases. It currently supports features like "match any of the values in this array", regexps and optional vs. required attributes. However mimetype matching has been awkward and handler applications have forgotten to enumerate wildcard types like "image/*" which means that they don't always show up when they should.<br />
<br />
Possibly the situation can be improved by providing explicit features for mimetype matching.<br />
<br />
Another thing that we might ultimately want to do is to allow passing a javascript expression which is evaluated on the activity data and then returns true/false. However this is not something we'd be able to implement in FirefoxOS right now since we're trying to keep process separation between code from different apps.<br />
<br />
== UX Problems with activity picker ==<br />
<br />
Again, Pocket has done great research on problems with activity pickers, in particular in the Android Intent implementation. One of the main points is that in situation when there's a long list of candidates for handling an activity, making it easy to access the two or three most commonly used handlers is important. All handlers should not be treated equal.<br />
<br />
[https://docs.google.com/a/readitlater.com/document/d/1S5TnrCMrtaYqPTSK3YUIE-6shWSvRONdEhm74rW7CrE/edit Pocket recommendations].<br />
<br />
== Differences between "data sources" and activities/intents ==<br />
<br />
One of the things we looked at solving with WebActivities in FirefoxOS was access to "data sources". For example the list of contacts, the list of calendar events, the music library or the camera photo stream.<br />
<br />
However due to various complexities we found that "data sources" tend to be different enough from other WebActivity use cases that we'll likely need significantly different primitives. Though it might be possible to tie in with WebActivities somehow.<br />
<br />
When granting access to for example contacts to an app, you likely want that app to have access to ''all'' your contacts, not just the contacts from a specific other app. So you'd want to grant access to your gmail contacts, your facebook friends, your outlook address book and any "built in" contact address book.<br />
<br />
Getting contacts from many apps at the same time can be prohibitively expensive if you have to launch all those apps, even if they don't need to render UI. Each app runs in a separate process and starting multiple processes takes a lot of CPU and memory on mobile.<br />
<br />
Displaying a merged contact list from all your contacts sources will take too long if you have to get the full contact list from each source, then merge those lists, then sort them, then reformat to get just the data you want to display in HTML form.<br />
<br />
This is even more true for a photo stream where you also need to generate thumbnails.<br />
<br />
It needs to be possible to do some of that work ahead of time and then react to any changes in those data sources before the user launches the app. Potentially it could help if the application cached the previously generated list, then ask each data source provider for changes since last time, and then update once it has received those changes. However we still want to get those updates fairly quickly to avoid the risk of the user looking at old data for too long and then having it "snap" to show the new data.<br />
<br />
When a user grants access to a data source we need to indicate if permanent access is granted, or just a one-shot access. That indicates a somewhat different UI than we want for "share" and "pick".<br />
<br />
Similarly, the UI that comes up when an application tries to access "contacts" data sources, the user needs to be able to choose multiple applications that can provide that type of data. Normally for a WebActivity the user just picks a single application to handle the activity.<br />
<br />
'''Recommended solutions'''<br />
<br />
In FirefoxOS we have implemented a "shared indexeddb-like database" API which allows one application to write a database to disk which another application can then read without the need of starting the application that owns the data source.<br />
<br />
This enabled us to allow reading "contacts" databases from multiple apps without worrying about launching multiple processes. When access to "contacts" is requested, we plan to render a "data source" specific UI which enables the user to pick multiple applications as well as choose if read vs. readwrite access is granted.<br />
<br />
It also enables knowing when the data in a data source changes, and what changes were made. This way we can wake up applications that want to precompute thumbnails or do other heavy data operations. We can also enable the UA to provide applications with the list of changes that were made since last time they updated, without requiring that each data source needs to implement this algorithm.<br />
<br />
This solution is still very experimental, and we still haven't figured out all the aspects of this.<br />
<br />
We haven't figured out the security aspects of exposing write access to the "contacts" data sources, without worrying that a rouge app could simply delete or corrupt all the user's contacts. A simple yes/no security dialog doesn't feel like enough to protect the user. So for now we are sadly relying on similar mechanisms that we use to protect TCPSocket and SD-card access, i.e. signatures from a trusted party.<br />
<br />
We also haven't figured out how to ensure that an app that has write access to contacts follows whatever format a contact should have.<br />
<br />
For v1 my recommendation is to punt on the "data sources" use case.</div>Sickinghttps://wiki.mozilla.org/index.php?title=WebAPI/WebActivities/LessonsLearned&diff=977860WebAPI/WebActivities/LessonsLearned2014-05-17T00:18:25Z<p>Sicking: /* Differences between "data sources" and activities/intents */</p>
<hr />
<div><br />
Based on internal experience, as well as experience talking with other partners like Google and Pocket, we have learned a lot about how to design the next iteration of WebActivities.<br />
<br />
Below I'll use the term 'app' not to refer to a Android/iOS installed app, but rather to the generic concept of a webapp.<br />
<br />
To simplify the discussion, here's two standard flows when using WebActivities<br />
<br />
'''Using an activity that returns a value'''<br />
# User launches facebook<br />
# User clicks "attach a picture"<br />
# Facebook launches the "pick" WebActivity<br />
# The activity picker comes up.<br />
# User chooses to use the camera app as activity handler<br />
# Camera app is launched<br />
# User takes a picture<br />
# Camera app returns the picture as result of the activity<br />
# Camera app is closed and user is back in facebook app.<br />
<br />
'''Using an activity that does not return a value'''<br />
# User goes to news website and finds an interesting article<br />
# User clicks "share" button<br />
# News website lauches the "share" WebActivity<br />
# The activity picker comes up.<br />
# User chooses to use the twitter app as activity handler<br />
# Twitter app is launched<br />
# Twitter app prefills URL of news article as tweet content<br />
# User writes short message to go along with the URL and submits the tweet<br />
<br />
== UX issues with activities that return a value ==<br />
<br />
In FirefoxOS, if the user in step 7 of the ''returns a value'' flow temporarily switches app, for example to look something up, or to answer an incoming phone call, then the activity is aborted and facebook receives an error message. We were forced to do this in order to deal with the situation when the user might switch back to the facebook app, in which case we didn't want to force facebook to deal with having to implement a sensible UI while the activity was still in progress. However aborting the activity just because the user looked something up is obviously bad.<br />
<br />
In Chrome's Web Intents, step 6 of ''returns a value'' flow launches the camera app in a separate tab in the browser. That creates an awkward relationship between the tab with the facebook app and the tab with camera app. In particular, if the user closes the facebook tab, then when the picture is taken, it's dropped on the floor since there is no facebook app to receive it.<br />
<br />
'''Recommended solutions'''<br />
<br />
For activities that return a value, the activity handler should be overlayed on top of the initiating app. I.e. in the example above the camera app should be rendered on top of the facebook app.<br />
<br />
In a small-screen device this means that the application switcher shouldn't display facebook and the camera as two separate apps currently running. Instead only the facebook app should be listed, though possibly the UI could somehow indicate that the facebook app is currently using the camera app or some such. Switching to the facebook app should render the camera app on top of it.<br />
<br />
On a large-screen device with a traditional tabbed browser UI, the camera app should be rendered in the same tab as the facebook app. I.e. the camera app would be on top of the facebook app.<br />
<br />
== UX issues with opening in activities in a new app/tab ==<br />
<br />
In FirefoxOS a webactivity always launches a new fullscreen app. This makes activities always have a fairly heavy flow since it involves two app switches, one to the activity handler, and one to switch back to the original app.<br />
<br />
Activity handlers that want to implement things like "save this for later" or "share on my photo stream" only needs to display minimal UI that doesn't take the user out of the current app.<br />
<br />
'''Recommended solutions'''<br />
<br />
We should implement a "disposition: 'inline'" like what Web Intents has. This is already specified for WebActivities but was never implemented. An inline handler would be rendered like a "dialog" on top of the current app.<br />
<br />
On large-screen devices this likely means that it sizes to content. On small-screen devices this might simply mean that it doesn't take up the full screen.<br />
<br />
Pocket also has dome some really great research [https://docs.google.com/a/readitlater.com/document/d/1S5TnrCMrtaYqPTSK3YUIE-6shWSvRONdEhm74rW7CrE/edit here].<br />
<br />
This research proposes even allowing overlays that render directly on top of the initiating app. This provides for some pretty awesome UI, but also exposes issues like clickjacking. Ideally disposition:inline can bring most of the benefits of this proposal, while still not exposing clickjacking risks.<br />
<br />
== UX issues if the handler app is already running when the activity is launched ==<br />
<br />
In FirefoxOS's implementation of WebActivities, if the twitter app was already running in the background when the ''does not return a value'' flow happens, we switch to the twitter app and send a message to it and ask it to handle the activity. However this means that the app has to leave it's current state in order to do so. So if the user was in the middle of some other task within the twitter app, that is now lost.<br />
<br />
'''Recommended solutions'''<br />
<br />
If we follow the recommendation above for [[#UX issues with activities that return a value|UX issues with activities that return a value]] that actually solves the problem for activities that return a value. A new page will always be opened and rendered on top of the app that initiated the activity.<br />
<br />
Likewise disposition:inline activities will also not suffer this problem since they open a new page inside the inline UI on top of the page that initiated the activity.<br />
<br />
For other activity handlers a good default is likely to always open a new tab to handle the activity.<br />
<br />
But we could also enable handing an activity using an existing page by allowing using a ServiceWorker as activity handler, and then allow the service worker to delegate to an already open page. Possibly we could even allow the ServiceWorker to open a disposition:inline activity.<br />
<br />
== Lack of ability to save intermediate results ==<br />
<br />
Consider a "Google Drive" app that uses an "edit" activity to launch a "photoshop" app in order to edit a picture file.<br />
<br />
In the current WebActivities and Web Intents implementations, the only way to accomplish this would be to have the photoshop "edit" activity handler return the edited image once the user was done editing, and then have the Google Drive app save the resulting file.<br />
<br />
There are a couple of issues with this flow though. First off given that the activity would be one returning a value, the photoshop app would have to be opened on top of Google Drive. This isn't always desirable.<br />
<br />
A bigger problem is that photoshop would not be able to save intermediate drafts to the Google Drive app. It would either not save them at all, which means risking more dataloss in case of a crash or accidentally closing the app, or it would have to save them somewhere in photoshop's storage area. In case of crash it would be awkward to get the edited data back into Google drive. The user would have to relaunch the edit activity and select photoshop again, and then photoshop would have to detect that the same file was being edited and offer to reuse the previously saved draft.<br />
<br />
A desired flow here is instead to enable Google Drive to launch the "edit" activity such that Photoshop could be opened in a new window. But also enable Photoshop to have an open communication channel back to Google Drive. However the user should be able to close the Google Drive tab while still enabling Photoshop to send data to Google Drive in order to save intermediate drafts.<br />
<br />
'''Recommended solutions'''<br />
<br />
When launching an activity, it should be possible to also provide "back channel" information. If provided, the activity handler would be able to postMessage arbitrary information back to the app that initiated the activity.<br />
<br />
These messages would likely need to be sent not to the execution context that initiated the activity, but rather to its Service Worker. This way messages can be sent even if the execution context that initiated the activity has been closed.<br />
<br />
The app initiating the activity would also need to provide some arbitrary data which is passed back any time messages are sent from the activity handler and which can't be altered by the activity handler. In the example above the Google Drive app could provide the filename of the file being edited.<br />
<br />
== Ability to switch from inline to full-window handler ==<br />
<br />
A disposition:inline handler might need to defer to a more complex UI depending on user actions. For example a facebook "share" handler might start as an inline handler, but need to switch to a more complex UI if the user wants to configure security settings or add complex data to the post.<br />
<br />
This gets especially tricky for activity handlers that return a value. In this case the full-window handler would need to be rendered on top of the current app, I.e. it couldn't be handled like a normal window.open with target=_blank. Additionally the new page needs to take over the responsibility of returning a value.<br />
<br />
'''Recommended solutions'''<br />
<br />
Sadly I don't have any recommendations here. Possibly simply not supporting this scenario is the right solution for now. Instead we can allow a display:inline handler to resize itself to handle the more complex UI.<br />
<br />
What might help is to force this scenario to be handled by allowing a ServiceWorker to handle the activity and then allowing the ServiceWorker to open inline or full-window handlers on top of the initiating app.<br />
<br />
Activity handlers that don't return a value can always open new pages using target=_blank links or window.open calls.<br />
<br />
== Should activity launcher have a say in the disposition of the handler? ==<br />
<br />
''This is mostly based on notes from a WebActivities/Web Intents discussion. I sadly don't remember all the details here.''<br />
<br />
For activities that do not return a value, the initiating app might want to treat launching the activity handler as either a "navigation" or as a "open in new tab".<br />
<br />
In the Google Drive/Photoshop example above, it seems like it should be the decision of the Google Drive app if Photoshop should replace the Google Drive app, or if opening Photoshop should be treated like opening a <tt>&lt;a target="_blank"&gt;</tt> link.<br />
<br />
'''Recommended solutions'''<br />
<br />
We could support a ''target'' attribute when initiating an activity. The target would be ignored for activities that return a value, and possibly also for disposition:inline activities. However I don't know of use cases which involve targeting named windows, so possibly a ''target'' attribute is too generic.<br />
<br />
Another question is if it should be possible to target _self if the current page is open in an iframe. I.e. should activity handlers need to worry about possibly being opened in a subframe?<br />
<br />
== Finding activity handlers that match a given activity request ==<br />
<br />
When an activity is initiated we want to fairly quickly bring up a list of apps that are able to handle the activity. In WebActivities we allow activity handlers to provide an object which describes a filter which the activity data is matched against.<br />
<br />
However it's proven pretty hard to find a format to express these filters. For example for the "pick" activity if an application asks for a picture it could do that either by specifying any of <tt>type: 'image/*'</tt>, <tt>type: 'image/gif'</tt> or <tt>type: 'image/jpg'</tt>. So any activity handler for the "pick" activity that can provide an picture has to enumerate at least all of those types. And it also has to make sure that its filter matches if no specific type is requested.<br />
<br />
Another problem is that if a contact-manager app provides a handler for the "pick" activity in order to allow the user to choose a contact when a contact is explicitly requested, but not come up when the "pick" activity is activated to select an arbitrary file, i.e. when no <tt>type</tt> is specified.<br />
<br />
'''Recommended solutions'''<br />
<br />
It's possible that WebActivities' current filter mechanism actually can handle most use cases. It currently supports features like "match any of the values in this array", regexps and optional vs. required attributes. However mimetype matching has been awkward and handler applications have forgotten to enumerate wildcard types like "image/*" which means that they don't always show up when they should.<br />
<br />
Possibly the situation can be improved by providing explicit features for mimetype matching.<br />
<br />
Another thing that we might ultimately want to do is to allow passing a javascript expression which is evaluated on the activity data and then returns true/false. However this is not something we'd be able to implement in FirefoxOS right now since we're trying to keep process separation between code from different apps.<br />
<br />
== UX Problems with activity picker ==<br />
<br />
Again, Pocket has done great research on problems with activity pickers, in particular in the Android Intent implementation. One of the main points is that in situation when there's a long list of candidates for handling an activity, making it easy to access the two or three most commonly used handlers is important. All handlers should not be treated equal.<br />
<br />
[https://docs.google.com/a/readitlater.com/document/d/1S5TnrCMrtaYqPTSK3YUIE-6shWSvRONdEhm74rW7CrE/edit Pocket recommendations].<br />
<br />
== Differences between "data sources" and activities/intents ==<br />
<br />
One of the things we looked at solving with WebActivities in FirefoxOS was access to "data sources". For example the list of contacts, the list of calendar events, the music library or the camera photo stream.<br />
<br />
However due to various complexities we found that "data sources" tend to be different enough from other WebActivity use cases that we'll likely need significantly different primitives. Though there might be possible to tie in with WebActivities somehow.<br />
<br />
When granting access to for example contacts to an app, you likely want that app to have access to ''all'' your contacts, not just the contacts from a specific other app. So you'd want to grant access to your gmail contacts, your facebook friends, your outlook address book and any "built in" contact address book.<br />
<br />
Getting contacts from many apps at the same time can be prohibitively expensive if you have to launch all those apps, even if they don't need to render UI. Each app runs in a separate process and starting multiple processes takes a lot of CPU and memory on mobile.<br />
<br />
Displaying a merged contact list from all your contacts sources will take too long if you have to get the full contact list from each source, then merge those lists, then sort them, then reformat to get just the data you want to display in HTML form.<br />
<br />
This is even more true for a photo stream where you also need to generate thumbnails.<br />
<br />
It needs to be possible to do some of that work ahead of time and then react to any changes in those data sources before the user launches the app. Potentially it could help if the application cached the previously generated list, then ask each data source provider for changes since last time, and then update once it has received those changes. However we still want to get those updates fairly quickly to avoid the risk of the user looking at old data for too long and then having it "snap" to show the new data.<br />
<br />
When a user grants access to a data source we need to indicate if permanent access is granted, or just a one-shot access. That indicates a somewhat different UI than we want for "share" and "pick".<br />
<br />
Similarly, the UI that comes up when an application tries to access "contacts" data sources, the user needs to be able to choose multiple applications that can provide that type of data. Normally for a WebActivity the user just picks a single application to handle the activity.<br />
<br />
'''Recommended solutions'''<br />
<br />
In FirefoxOS we have implemented a "shared indexeddb-like database" API which allows one application to write a database to disk which another application can then read without the need of starting the application that owns the data source.<br />
<br />
This enabled us to allow reading "contacts" databases from multiple apps without worrying about launching multiple processes. When access to "contacts" is requested, we plan to render a "data source" specific UI which enables the user to pick multiple applications as well as choose if read vs. readwrite access is granted.<br />
<br />
It also enables knowing when the data in a data source changes, and what changes were made. This way we can wake up applications that want to precompute thumbnails or do other heavy data operations. We can also enable the UA to provide applications with the list of changes that were made since last time they updated, without requiring that each data source needs to implement this algorithm.<br />
<br />
This solution is still very experimental, and we still haven't figured out all the aspects of this.<br />
<br />
We haven't figured out the security aspects of exposing write access to the "contacts" data sources, without worrying that a rouge app could simply delete or corrupt all the user's contacts. A simple yes/no security dialog doesn't feel like enough to protect the user. So for now we are sadly relying on similar mechanisms that we use to protect TCPSocket and SD-card access, i.e. signatures from a trusted party.<br />
<br />
We also haven't figured out how to ensure that an app that has write access to contacts follows whatever format a contact should have.<br />
<br />
For v1 my recommendation is to punt on the "data sources" use case.</div>Sickinghttps://wiki.mozilla.org/index.php?title=WebAPI/WebActivities/LessonsLearned&diff=977855WebAPI/WebActivities/LessonsLearned2014-05-17T00:13:33Z<p>Sicking: /* Differences between "data sources" and activities/intents */</p>
<hr />
<div><br />
Based on internal experience, as well as experience talking with other partners like Google and Pocket, we have learned a lot about how to design the next iteration of WebActivities.<br />
<br />
Below I'll use the term 'app' not to refer to a Android/iOS installed app, but rather to the generic concept of a webapp.<br />
<br />
To simplify the discussion, here's two standard flows when using WebActivities<br />
<br />
'''Using an activity that returns a value'''<br />
# User launches facebook<br />
# User clicks "attach a picture"<br />
# Facebook launches the "pick" WebActivity<br />
# The activity picker comes up.<br />
# User chooses to use the camera app as activity handler<br />
# Camera app is launched<br />
# User takes a picture<br />
# Camera app returns the picture as result of the activity<br />
# Camera app is closed and user is back in facebook app.<br />
<br />
'''Using an activity that does not return a value'''<br />
# User goes to news website and finds an interesting article<br />
# User clicks "share" button<br />
# News website lauches the "share" WebActivity<br />
# The activity picker comes up.<br />
# User chooses to use the twitter app as activity handler<br />
# Twitter app is launched<br />
# Twitter app prefills URL of news article as tweet content<br />
# User writes short message to go along with the URL and submits the tweet<br />
<br />
== UX issues with activities that return a value ==<br />
<br />
In FirefoxOS, if the user in step 7 of the ''returns a value'' flow temporarily switches app, for example to look something up, or to answer an incoming phone call, then the activity is aborted and facebook receives an error message. We were forced to do this in order to deal with the situation when the user might switch back to the facebook app, in which case we didn't want to force facebook to deal with having to implement a sensible UI while the activity was still in progress. However aborting the activity just because the user looked something up is obviously bad.<br />
<br />
In Chrome's Web Intents, step 6 of ''returns a value'' flow launches the camera app in a separate tab in the browser. That creates an awkward relationship between the tab with the facebook app and the tab with camera app. In particular, if the user closes the facebook tab, then when the picture is taken, it's dropped on the floor since there is no facebook app to receive it.<br />
<br />
'''Recommended solutions'''<br />
<br />
For activities that return a value, the activity handler should be overlayed on top of the initiating app. I.e. in the example above the camera app should be rendered on top of the facebook app.<br />
<br />
In a small-screen device this means that the application switcher shouldn't display facebook and the camera as two separate apps currently running. Instead only the facebook app should be listed, though possibly the UI could somehow indicate that the facebook app is currently using the camera app or some such. Switching to the facebook app should render the camera app on top of it.<br />
<br />
On a large-screen device with a traditional tabbed browser UI, the camera app should be rendered in the same tab as the facebook app. I.e. the camera app would be on top of the facebook app.<br />
<br />
== UX issues with opening in activities in a new app/tab ==<br />
<br />
In FirefoxOS a webactivity always launches a new fullscreen app. This makes activities always have a fairly heavy flow since it involves two app switches, one to the activity handler, and one to switch back to the original app.<br />
<br />
Activity handlers that want to implement things like "save this for later" or "share on my photo stream" only needs to display minimal UI that doesn't take the user out of the current app.<br />
<br />
'''Recommended solutions'''<br />
<br />
We should implement a "disposition: 'inline'" like what Web Intents has. This is already specified for WebActivities but was never implemented. An inline handler would be rendered like a "dialog" on top of the current app.<br />
<br />
On large-screen devices this likely means that it sizes to content. On small-screen devices this might simply mean that it doesn't take up the full screen.<br />
<br />
Pocket also has dome some really great research [https://docs.google.com/a/readitlater.com/document/d/1S5TnrCMrtaYqPTSK3YUIE-6shWSvRONdEhm74rW7CrE/edit here].<br />
<br />
This research proposes even allowing overlays that render directly on top of the initiating app. This provides for some pretty awesome UI, but also exposes issues like clickjacking. Ideally disposition:inline can bring most of the benefits of this proposal, while still not exposing clickjacking risks.<br />
<br />
== UX issues if the handler app is already running when the activity is launched ==<br />
<br />
In FirefoxOS's implementation of WebActivities, if the twitter app was already running in the background when the ''does not return a value'' flow happens, we switch to the twitter app and send a message to it and ask it to handle the activity. However this means that the app has to leave it's current state in order to do so. So if the user was in the middle of some other task within the twitter app, that is now lost.<br />
<br />
'''Recommended solutions'''<br />
<br />
If we follow the recommendation above for [[#UX issues with activities that return a value|UX issues with activities that return a value]] that actually solves the problem for activities that return a value. A new page will always be opened and rendered on top of the app that initiated the activity.<br />
<br />
Likewise disposition:inline activities will also not suffer this problem since they open a new page inside the inline UI on top of the page that initiated the activity.<br />
<br />
For other activity handlers a good default is likely to always open a new tab to handle the activity.<br />
<br />
But we could also enable handing an activity using an existing page by allowing using a ServiceWorker as activity handler, and then allow the service worker to delegate to an already open page. Possibly we could even allow the ServiceWorker to open a disposition:inline activity.<br />
<br />
== Lack of ability to save intermediate results ==<br />
<br />
Consider a "Google Drive" app that uses an "edit" activity to launch a "photoshop" app in order to edit a picture file.<br />
<br />
In the current WebActivities and Web Intents implementations, the only way to accomplish this would be to have the photoshop "edit" activity handler return the edited image once the user was done editing, and then have the Google Drive app save the resulting file.<br />
<br />
There are a couple of issues with this flow though. First off given that the activity would be one returning a value, the photoshop app would have to be opened on top of Google Drive. This isn't always desirable.<br />
<br />
A bigger problem is that photoshop would not be able to save intermediate drafts to the Google Drive app. It would either not save them at all, which means risking more dataloss in case of a crash or accidentally closing the app, or it would have to save them somewhere in photoshop's storage area. In case of crash it would be awkward to get the edited data back into Google drive. The user would have to relaunch the edit activity and select photoshop again, and then photoshop would have to detect that the same file was being edited and offer to reuse the previously saved draft.<br />
<br />
A desired flow here is instead to enable Google Drive to launch the "edit" activity such that Photoshop could be opened in a new window. But also enable Photoshop to have an open communication channel back to Google Drive. However the user should be able to close the Google Drive tab while still enabling Photoshop to send data to Google Drive in order to save intermediate drafts.<br />
<br />
'''Recommended solutions'''<br />
<br />
When launching an activity, it should be possible to also provide "back channel" information. If provided, the activity handler would be able to postMessage arbitrary information back to the app that initiated the activity.<br />
<br />
These messages would likely need to be sent not to the execution context that initiated the activity, but rather to its Service Worker. This way messages can be sent even if the execution context that initiated the activity has been closed.<br />
<br />
The app initiating the activity would also need to provide some arbitrary data which is passed back any time messages are sent from the activity handler and which can't be altered by the activity handler. In the example above the Google Drive app could provide the filename of the file being edited.<br />
<br />
== Ability to switch from inline to full-window handler ==<br />
<br />
A disposition:inline handler might need to defer to a more complex UI depending on user actions. For example a facebook "share" handler might start as an inline handler, but need to switch to a more complex UI if the user wants to configure security settings or add complex data to the post.<br />
<br />
This gets especially tricky for activity handlers that return a value. In this case the full-window handler would need to be rendered on top of the current app, I.e. it couldn't be handled like a normal window.open with target=_blank. Additionally the new page needs to take over the responsibility of returning a value.<br />
<br />
'''Recommended solutions'''<br />
<br />
Sadly I don't have any recommendations here. Possibly simply not supporting this scenario is the right solution for now. Instead we can allow a display:inline handler to resize itself to handle the more complex UI.<br />
<br />
What might help is to force this scenario to be handled by allowing a ServiceWorker to handle the activity and then allowing the ServiceWorker to open inline or full-window handlers on top of the initiating app.<br />
<br />
Activity handlers that don't return a value can always open new pages using target=_blank links or window.open calls.<br />
<br />
== Should activity launcher have a say in the disposition of the handler? ==<br />
<br />
''This is mostly based on notes from a WebActivities/Web Intents discussion. I sadly don't remember all the details here.''<br />
<br />
For activities that do not return a value, the initiating app might want to treat launching the activity handler as either a "navigation" or as a "open in new tab".<br />
<br />
In the Google Drive/Photoshop example above, it seems like it should be the decision of the Google Drive app if Photoshop should replace the Google Drive app, or if opening Photoshop should be treated like opening a <tt>&lt;a target="_blank"&gt;</tt> link.<br />
<br />
'''Recommended solutions'''<br />
<br />
We could support a ''target'' attribute when initiating an activity. The target would be ignored for activities that return a value, and possibly also for disposition:inline activities. However I don't know of use cases which involve targeting named windows, so possibly a ''target'' attribute is too generic.<br />
<br />
Another question is if it should be possible to target _self if the current page is open in an iframe. I.e. should activity handlers need to worry about possibly being opened in a subframe?<br />
<br />
== Finding activity handlers that match a given activity request ==<br />
<br />
When an activity is initiated we want to fairly quickly bring up a list of apps that are able to handle the activity. In WebActivities we allow activity handlers to provide an object which describes a filter which the activity data is matched against.<br />
<br />
However it's proven pretty hard to find a format to express these filters. For example for the "pick" activity if an application asks for a picture it could do that either by specifying any of <tt>type: 'image/*'</tt>, <tt>type: 'image/gif'</tt> or <tt>type: 'image/jpg'</tt>. So any activity handler for the "pick" activity that can provide an picture has to enumerate at least all of those types. And it also has to make sure that its filter matches if no specific type is requested.<br />
<br />
Another problem is that if a contact-manager app provides a handler for the "pick" activity in order to allow the user to choose a contact when a contact is explicitly requested, but not come up when the "pick" activity is activated to select an arbitrary file, i.e. when no <tt>type</tt> is specified.<br />
<br />
'''Recommended solutions'''<br />
<br />
It's possible that WebActivities' current filter mechanism actually can handle most use cases. It currently supports features like "match any of the values in this array", regexps and optional vs. required attributes. However mimetype matching has been awkward and handler applications have forgotten to enumerate wildcard types like "image/*" which means that they don't always show up when they should.<br />
<br />
Possibly the situation can be improved by providing explicit features for mimetype matching.<br />
<br />
Another thing that we might ultimately want to do is to allow passing a javascript expression which is evaluated on the activity data and then returns true/false. However this is not something we'd be able to implement in FirefoxOS right now since we're trying to keep process separation between code from different apps.<br />
<br />
== UX Problems with activity picker ==<br />
<br />
Again, Pocket has done great research on problems with activity pickers, in particular in the Android Intent implementation. One of the main points is that in situation when there's a long list of candidates for handling an activity, making it easy to access the two or three most commonly used handlers is important. All handlers should not be treated equal.<br />
<br />
[https://docs.google.com/a/readitlater.com/document/d/1S5TnrCMrtaYqPTSK3YUIE-6shWSvRONdEhm74rW7CrE/edit Pocket recommendations].<br />
<br />
== Differences between "data sources" and activities/intents ==<br />
<br />
One of the things we looked at solving with WebActivities in FirefoxOS was access to "data sources". For example the list of contacts, the list of calendar events, the music library or the camera photo stream.<br />
<br />
However due to various complexities we found that "data sources" tend to be different enough from other WebActivity use cases that we'll likely need significantly different primitives. Though there might be possible to tie in with WebActivities somehow.<br />
<br />
When granting access to for example contacts to an app, you likely want that app to have access to ''all'' your contacts, not just the contacts from a specific other app. So you'd want to grant access to your gmail contacts, your facebook friends, your outlook address book and any "built in" contact address book.<br />
<br />
Getting contacts from many apps at the same time can be prohibitively expensive if you have to launch all those apps, even if they don't need to render UI. Each app runs in a separate process and starting multiple processes takes a lot of CPU and memory on mobile.<br />
<br />
Displaying a merged contact list from all your contacts sources will take too long if you have to get the full contact list from each source, then merge those lists, then sort them, then reformat to get just the data you want to display in HTML form.<br />
<br />
This is even more true for a photo stream where you also need to generate thumbnails.<br />
<br />
It needs to be possible to do some of that work ahead of time and then react to any changes in those data sources before the user launches the app. Potentially it could help if the application cached the previously generated list, then ask each data source provider for changes since last time, and then update once it has received those changes. However we still want to get those updates fairly quickly to avoid the risk of the user looking at old data for too long and then having it "snap" to show the new data.<br />
<br />
When a user grants access to a data source we need to indicate if permanent access is granted, or just a one-shot access. That indicates a somewhat different UI than we want for "share" and "pick".<br />
<br />
Similarly, the UI that comes up when an application tries to access "contacts" data sources, the user needs to be able to choose multiple applications that can provide that type of data. Normally for a WebActivity the user just picks a single application to handle the activity.<br />
<br />
'''Recommended solutions'''<br />
<br />
In FirefoxOS we have implemented a "shared indexeddb-like database" API which allows one application to write a database to disk which another application can then read without the need of starting the application that owns the data source.<br />
<br />
This enabled us to allow reading "contacts" databases from multiple apps without worrying about launching multiple processes. When access to "contacts" is requested, we plan to render a "data source" specific UI which enables the user to pick multiple applications as well as choose if read vs. readwrite access is granted.<br />
<br />
It also enables knowing when the data in a data source changes, and what changes were made. This way we can wake up applications that want to precompute thumbnails or do other heavy data operations. We can also enable the UA to provide applications with the list of changes that were made since last time they updated, without requiring that each data source needs to implement this algorithm.<br />
<br />
This solution is still very experimental, and we still haven't figured out all the aspects of this.<br />
<br />
We haven't figured out the security aspects of exposing write access to the "contacts" data sources, without worrying that a rouge app could simply delete or corrupt all the user's contacts. A simple yes/no security dialog doesn't feel like enough to protect the user. So for now we are sadly relying on similar mechanisms that we use to protect TCPSocket and SD-card access, i.e. signatures from a trusted party.<br />
<br />
We also haven't figured out how to ensure that an app that has write access to contacts follows whatever format a contact should have.<br />
<br />
So for v1 I would recommend to punt on "data sources".</div>Sickinghttps://wiki.mozilla.org/index.php?title=WebAPI/WebActivities/LessonsLearned&diff=977833WebAPI/WebActivities/LessonsLearned2014-05-16T22:49:01Z<p>Sicking: /* Differences between "data sources" and activities/intents */</p>
<hr />
<div><br />
Based on internal experience, as well as experience talking with other partners like Google and Pocket, we have learned a lot about how to design the next iteration of WebActivities.<br />
<br />
Below I'll use the term 'app' not to refer to a Android/iOS installed app, but rather to the generic concept of a webapp.<br />
<br />
To simplify the discussion, here's two standard flows when using WebActivities<br />
<br />
'''Using an activity that returns a value'''<br />
# User launches facebook<br />
# User clicks "attach a picture"<br />
# Facebook launches the "pick" WebActivity<br />
# The activity picker comes up.<br />
# User chooses to use the camera app as activity handler<br />
# Camera app is launched<br />
# User takes a picture<br />
# Camera app returns the picture as result of the activity<br />
# Camera app is closed and user is back in facebook app.<br />
<br />
'''Using an activity that does not return a value'''<br />
# User goes to news website and finds an interesting article<br />
# User clicks "share" button<br />
# News website lauches the "share" WebActivity<br />
# The activity picker comes up.<br />
# User chooses to use the twitter app as activity handler<br />
# Twitter app is launched<br />
# Twitter app prefills URL of news article as tweet content<br />
# User writes short message to go along with the URL and submits the tweet<br />
<br />
== UX issues with activities that return a value ==<br />
<br />
In FirefoxOS, if the user in step 7 of the ''returns a value'' flow temporarily switches app, for example to look something up, or to answer an incoming phone call, then the activity is aborted and facebook receives an error message. We were forced to do this in order to deal with the situation when the user might switch back to the facebook app, in which case we didn't want to force facebook to deal with having to implement a sensible UI while the activity was still in progress. However aborting the activity just because the user looked something up is obviously bad.<br />
<br />
In Chrome's Web Intents, step 6 of ''returns a value'' flow launches the camera app in a separate tab in the browser. That creates an awkward relationship between the tab with the facebook app and the tab with camera app. In particular, if the user closes the facebook tab, then when the picture is taken, it's dropped on the floor since there is no facebook app to receive it.<br />
<br />
'''Recommended solutions'''<br />
<br />
For activities that return a value, the activity handler should be overlayed on top of the initiating app. I.e. in the example above the camera app should be rendered on top of the facebook app.<br />
<br />
In a small-screen device this means that the application switcher shouldn't display facebook and the camera as two separate apps currently running. Instead only the facebook app should be listed, though possibly the UI could somehow indicate that the facebook app is currently using the camera app or some such. Switching to the facebook app should render the camera app on top of it.<br />
<br />
On a large-screen device with a traditional tabbed browser UI, the camera app should be rendered in the same tab as the facebook app. I.e. the camera app would be on top of the facebook app.<br />
<br />
== UX issues with opening in activities in a new app/tab ==<br />
<br />
In FirefoxOS a webactivity always launches a new fullscreen app. This makes activities always have a fairly heavy flow since it involves two app switches, one to the activity handler, and one to switch back to the original app.<br />
<br />
Activity handlers that want to implement things like "save this for later" or "share on my photo stream" only needs to display minimal UI that doesn't take the user out of the current app.<br />
<br />
'''Recommended solutions'''<br />
<br />
We should implement a "disposition: 'inline'" like what Web Intents has. This is already specified for WebActivities but was never implemented. An inline handler would be rendered like a "dialog" on top of the current app.<br />
<br />
On large-screen devices this likely means that it sizes to content. On small-screen devices this might simply mean that it doesn't take up the full screen.<br />
<br />
Pocket also has dome some really great research [https://docs.google.com/a/readitlater.com/document/d/1S5TnrCMrtaYqPTSK3YUIE-6shWSvRONdEhm74rW7CrE/edit here].<br />
<br />
This research proposes even allowing overlays that render directly on top of the initiating app. This provides for some pretty awesome UI, but also exposes issues like clickjacking. Ideally disposition:inline can bring most of the benefits of this proposal, while still not exposing clickjacking risks.<br />
<br />
== UX issues if the handler app is already running when the activity is launched ==<br />
<br />
In FirefoxOS's implementation of WebActivities, if the twitter app was already running in the background when the ''does not return a value'' flow happens, we switch to the twitter app and send a message to it and ask it to handle the activity. However this means that the app has to leave it's current state in order to do so. So if the user was in the middle of some other task within the twitter app, that is now lost.<br />
<br />
'''Recommended solutions'''<br />
<br />
If we follow the recommendation above for [[#UX issues with activities that return a value|UX issues with activities that return a value]] that actually solves the problem for activities that return a value. A new page will always be opened and rendered on top of the app that initiated the activity.<br />
<br />
Likewise disposition:inline activities will also not suffer this problem since they open a new page inside the inline UI on top of the page that initiated the activity.<br />
<br />
For other activity handlers a good default is likely to always open a new tab to handle the activity.<br />
<br />
But we could also enable handing an activity using an existing page by allowing using a ServiceWorker as activity handler, and then allow the service worker to delegate to an already open page. Possibly we could even allow the ServiceWorker to open a disposition:inline activity.<br />
<br />
== Lack of ability to save intermediate results ==<br />
<br />
Consider a "Google Drive" app that uses an "edit" activity to launch a "photoshop" app in order to edit a picture file.<br />
<br />
In the current WebActivities and Web Intents implementations, the only way to accomplish this would be to have the photoshop "edit" activity handler return the edited image once the user was done editing, and then have the Google Drive app save the resulting file.<br />
<br />
There are a couple of issues with this flow though. First off given that the activity would be one returning a value, the photoshop app would have to be opened on top of Google Drive. This isn't always desirable.<br />
<br />
A bigger problem is that photoshop would not be able to save intermediate drafts to the Google Drive app. It would either not save them at all, which means risking more dataloss in case of a crash or accidentally closing the app, or it would have to save them somewhere in photoshop's storage area. In case of crash it would be awkward to get the edited data back into Google drive. The user would have to relaunch the edit activity and select photoshop again, and then photoshop would have to detect that the same file was being edited and offer to reuse the previously saved draft.<br />
<br />
A desired flow here is instead to enable Google Drive to launch the "edit" activity such that Photoshop could be opened in a new window. But also enable Photoshop to have an open communication channel back to Google Drive. However the user should be able to close the Google Drive tab while still enabling Photoshop to send data to Google Drive in order to save intermediate drafts.<br />
<br />
'''Recommended solutions'''<br />
<br />
When launching an activity, it should be possible to also provide "back channel" information. If provided, the activity handler would be able to postMessage arbitrary information back to the app that initiated the activity.<br />
<br />
These messages would likely need to be sent not to the execution context that initiated the activity, but rather to its Service Worker. This way messages can be sent even if the execution context that initiated the activity has been closed.<br />
<br />
The app initiating the activity would also need to provide some arbitrary data which is passed back any time messages are sent from the activity handler and which can't be altered by the activity handler. In the example above the Google Drive app could provide the filename of the file being edited.<br />
<br />
== Ability to switch from inline to full-window handler ==<br />
<br />
A disposition:inline handler might need to defer to a more complex UI depending on user actions. For example a facebook "share" handler might start as an inline handler, but need to switch to a more complex UI if the user wants to configure security settings or add complex data to the post.<br />
<br />
This gets especially tricky for activity handlers that return a value. In this case the full-window handler would need to be rendered on top of the current app, I.e. it couldn't be handled like a normal window.open with target=_blank. Additionally the new page needs to take over the responsibility of returning a value.<br />
<br />
'''Recommended solutions'''<br />
<br />
Sadly I don't have any recommendations here. Possibly simply not supporting this scenario is the right solution for now. Instead we can allow a display:inline handler to resize itself to handle the more complex UI.<br />
<br />
What might help is to force this scenario to be handled by allowing a ServiceWorker to handle the activity and then allowing the ServiceWorker to open inline or full-window handlers on top of the initiating app.<br />
<br />
Activity handlers that don't return a value can always open new pages using target=_blank links or window.open calls.<br />
<br />
== Should activity launcher have a say in the disposition of the handler? ==<br />
<br />
''This is mostly based on notes from a WebActivities/Web Intents discussion. I sadly don't remember all the details here.''<br />
<br />
For activities that do not return a value, the initiating app might want to treat launching the activity handler as either a "navigation" or as a "open in new tab".<br />
<br />
In the Google Drive/Photoshop example above, it seems like it should be the decision of the Google Drive app if Photoshop should replace the Google Drive app, or if opening Photoshop should be treated like opening a <tt>&lt;a target="_blank"&gt;</tt> link.<br />
<br />
'''Recommended solutions'''<br />
<br />
We could support a ''target'' attribute when initiating an activity. The target would be ignored for activities that return a value, and possibly also for disposition:inline activities. However I don't know of use cases which involve targeting named windows, so possibly a ''target'' attribute is too generic.<br />
<br />
Another question is if it should be possible to target _self if the current page is open in an iframe. I.e. should activity handlers need to worry about possibly being opened in a subframe?<br />
<br />
== Finding activity handlers that match a given activity request ==<br />
<br />
When an activity is initiated we want to fairly quickly bring up a list of apps that are able to handle the activity. In WebActivities we allow activity handlers to provide an object which describes a filter which the activity data is matched against.<br />
<br />
However it's proven pretty hard to find a format to express these filters. For example for the "pick" activity if an application asks for a picture it could do that either by specifying any of <tt>type: 'image/*'</tt>, <tt>type: 'image/gif'</tt> or <tt>type: 'image/jpg'</tt>. So any activity handler for the "pick" activity that can provide an picture has to enumerate at least all of those types. And it also has to make sure that its filter matches if no specific type is requested.<br />
<br />
Another problem is that if a contact-manager app provides a handler for the "pick" activity in order to allow the user to choose a contact when a contact is explicitly requested, but not come up when the "pick" activity is activated to select an arbitrary file, i.e. when no <tt>type</tt> is specified.<br />
<br />
'''Recommended solutions'''<br />
<br />
It's possible that WebActivities' current filter mechanism actually can handle most use cases. It currently supports features like "match any of the values in this array", regexps and optional vs. required attributes. However mimetype matching has been awkward and handler applications have forgotten to enumerate wildcard types like "image/*" which means that they don't always show up when they should.<br />
<br />
Possibly the situation can be improved by providing explicit features for mimetype matching.<br />
<br />
Another thing that we might ultimately want to do is to allow passing a javascript expression which is evaluated on the activity data and then returns true/false. However this is not something we'd be able to implement in FirefoxOS right now since we're trying to keep process separation between code from different apps.<br />
<br />
== UX Problems with activity picker ==<br />
<br />
Again, Pocket has done great research on problems with activity pickers, in particular in the Android Intent implementation. One of the main points is that in situation when there's a long list of candidates for handling an activity, making it easy to access the two or three most commonly used handlers is important. All handlers should not be treated equal.<br />
<br />
[https://docs.google.com/a/readitlater.com/document/d/1S5TnrCMrtaYqPTSK3YUIE-6shWSvRONdEhm74rW7CrE/edit Pocket recommendations].<br />
<br />
== Differences between "data sources" and activities/intents ==<br />
<br />
One of the things we looked at solving with WebActivities in FirefoxOS was access to "data sources". For example the list of contacts, the list of calendar events, the music library or the camera photo stream.<br />
<br />
However due to various complexities we found that "data sources" tend to be different enough from other WebActivity use cases that we'll likely need significantly different primitives. Though there might be possible to tie in with WebActivities somehow.<br />
<br />
When granting access to for example contacts to an app, you likely want that app to have access to *all* your contacts, not just the contacts from a specific other app. So you'd want to grant access to your gmail contacts, your facebook friends, your outlook address book and any "built in" contact address book.<br />
<br />
Getting contacts from many apps at the same time can be prohibitively expensive if you have to launch all those apps, even if they don't need to render UI. Each app runs in a separate process and starting multiple processes takes a lot of CPU and memory on mobile.<br />
<br />
Displaying a merged contact list from all your contacts sources will take too long if you have to get the full contact list from each source, then merge those lists, then sort them, then reformat to get just the data you want to display in HTML form.<br />
<br />
This is even more true for a photo stream where you also need to generate thumbnails.<br />
<br />
It needs to be possible to do some of that work ahead of time and then react to any changes in those data sources before the user launches the app. Potentially it could help if the application cached the previously generated list, then ask each data source provider for changes since last time, and then update once it has received those changes. However we still want to get those updates fairly quickly to avoid the risk of the user looking at old data for too long and then having it "snap" to show the new data.<br />
<br />
When a user grants access to a data source we need to indicate if permanent access is granted, or just a one-shot access. That indicates a somewhat different UI than we want for "share" and "pick".<br />
<br />
Similarly, the UI that comes up when an application tries to access "contacts" data sources, the user needs to be able to choose multiple applications that can provide that type of data. Normally for a WebActivity the user just picks a single application to handle the activity.<br />
<br />
'''Recommended solutions'''<br />
<br />
In FirefoxOS we have implemented a "shared indexeddb-like database" API which allows one application to write a database to disk which another application can then read without the need of starting the application that owns the data source.<br />
<br />
This enabled us to allow reading "contacts" databases from multiple apps without worrying about launching multiple processes. When access to "contacts" is requested, we plan to render a "data source" specific UI which enables the user to pick multiple applications as well as choose if read vs. readwrite access is granted.<br />
<br />
It also enables knowing when the data in a data source changes, and what changes were made. This way we can wake up applications that want to precompute thumbnails or do other heavy data operations. We can also enable the UA to provide applications with the list of changes that were made since last time they updated, without requiring that each data source needs to implement this algorithm.<br />
<br />
This solution is still very experimental, and we still haven't figured out all the aspects of this.<br />
<br />
We haven't figured out the security aspects of exposing write access to the "contacts" data sources, without worrying that a rouge app could simply delete or corrupt all the user's contacts. A simple yes/no security dialog doesn't feel like enough to protect the user. So for now we are sadly relying on similar mechanisms that we use to protect TCPSocket and SD-card access, i.e. signatures from a trusted party.<br />
<br />
We also haven't figured out how to ensure that an app that has write access to contacts follows whatever format a contact should have.<br />
<br />
So for v1 I would recommend to punt on "data sources".</div>Sickinghttps://wiki.mozilla.org/index.php?title=WebAPI/WebActivities/LessonsLearned&diff=977808WebAPI/WebActivities/LessonsLearned2014-05-16T22:00:38Z<p>Sicking: /* Differences between "data sources" and activities/intents */</p>
<hr />
<div><br />
Based on internal experience, as well as experience talking with other partners like Google and Pocket, we have learned a lot about how to design the next iteration of WebActivities.<br />
<br />
Below I'll use the term 'app' not to refer to a Android/iOS installed app, but rather to the generic concept of a webapp.<br />
<br />
To simplify the discussion, here's two standard flows when using WebActivities<br />
<br />
'''Using an activity that returns a value'''<br />
# User launches facebook<br />
# User clicks "attach a picture"<br />
# Facebook launches the "pick" WebActivity<br />
# The activity picker comes up.<br />
# User chooses to use the camera app as activity handler<br />
# Camera app is launched<br />
# User takes a picture<br />
# Camera app returns the picture as result of the activity<br />
# Camera app is closed and user is back in facebook app.<br />
<br />
'''Using an activity that does not return a value'''<br />
# User goes to news website and finds an interesting article<br />
# User clicks "share" button<br />
# News website lauches the "share" WebActivity<br />
# The activity picker comes up.<br />
# User chooses to use the twitter app as activity handler<br />
# Twitter app is launched<br />
# Twitter app prefills URL of news article as tweet content<br />
# User writes short message to go along with the URL and submits the tweet<br />
<br />
== UX issues with activities that return a value ==<br />
<br />
In FirefoxOS, if the user in step 7 of the ''returns a value'' flow temporarily switches app, for example to look something up, or to answer an incoming phone call, then the activity is aborted and facebook receives an error message. We were forced to do this in order to deal with the situation when the user might switch back to the facebook app, in which case we didn't want to force facebook to deal with having to implement a sensible UI while the activity was still in progress. However aborting the activity just because the user looked something up is obviously bad.<br />
<br />
In Chrome's Web Intents, step 6 of ''returns a value'' flow launches the camera app in a separate tab in the browser. That creates an awkward relationship between the tab with the facebook app and the tab with camera app. In particular, if the user closes the facebook tab, then when the picture is taken, it's dropped on the floor since there is no facebook app to receive it.<br />
<br />
'''Recommended solutions'''<br />
<br />
For activities that return a value, the activity handler should be overlayed on top of the initiating app. I.e. in the example above the camera app should be rendered on top of the facebook app.<br />
<br />
In a small-screen device this means that the application switcher shouldn't display facebook and the camera as two separate apps currently running. Instead only the facebook app should be listed, though possibly the UI could somehow indicate that the facebook app is currently using the camera app or some such. Switching to the facebook app should render the camera app on top of it.<br />
<br />
On a large-screen device with a traditional tabbed browser UI, the camera app should be rendered in the same tab as the facebook app. I.e. the camera app would be on top of the facebook app.<br />
<br />
== UX issues with opening in activities in a new app/tab ==<br />
<br />
In FirefoxOS a webactivity always launches a new fullscreen app. This makes activities always have a fairly heavy flow since it involves two app switches, one to the activity handler, and one to switch back to the original app.<br />
<br />
Activity handlers that want to implement things like "save this for later" or "share on my photo stream" only needs to display minimal UI that doesn't take the user out of the current app.<br />
<br />
'''Recommended solutions'''<br />
<br />
We should implement a "disposition: 'inline'" like what Web Intents has. This is already specified for WebActivities but was never implemented. An inline handler would be rendered like a "dialog" on top of the current app.<br />
<br />
On large-screen devices this likely means that it sizes to content. On small-screen devices this might simply mean that it doesn't take up the full screen.<br />
<br />
Pocket also has dome some really great research [https://docs.google.com/a/readitlater.com/document/d/1S5TnrCMrtaYqPTSK3YUIE-6shWSvRONdEhm74rW7CrE/edit here].<br />
<br />
This research proposes even allowing overlays that render directly on top of the initiating app. This provides for some pretty awesome UI, but also exposes issues like clickjacking. Ideally disposition:inline can bring most of the benefits of this proposal, while still not exposing clickjacking risks.<br />
<br />
== UX issues if the handler app is already running when the activity is launched ==<br />
<br />
In FirefoxOS's implementation of WebActivities, if the twitter app was already running in the background when the ''does not return a value'' flow happens, we switch to the twitter app and send a message to it and ask it to handle the activity. However this means that the app has to leave it's current state in order to do so. So if the user was in the middle of some other task within the twitter app, that is now lost.<br />
<br />
'''Recommended solutions'''<br />
<br />
If we follow the recommendation above for [[#UX issues with activities that return a value|UX issues with activities that return a value]] that actually solves the problem for activities that return a value. A new page will always be opened and rendered on top of the app that initiated the activity.<br />
<br />
Likewise disposition:inline activities will also not suffer this problem since they open a new page inside the inline UI on top of the page that initiated the activity.<br />
<br />
For other activity handlers a good default is likely to always open a new tab to handle the activity.<br />
<br />
But we could also enable handing an activity using an existing page by allowing using a ServiceWorker as activity handler, and then allow the service worker to delegate to an already open page. Possibly we could even allow the ServiceWorker to open a disposition:inline activity.<br />
<br />
== Lack of ability to save intermediate results ==<br />
<br />
Consider a "Google Drive" app that uses an "edit" activity to launch a "photoshop" app in order to edit a picture file.<br />
<br />
In the current WebActivities and Web Intents implementations, the only way to accomplish this would be to have the photoshop "edit" activity handler return the edited image once the user was done editing, and then have the Google Drive app save the resulting file.<br />
<br />
There are a couple of issues with this flow though. First off given that the activity would be one returning a value, the photoshop app would have to be opened on top of Google Drive. This isn't always desirable.<br />
<br />
A bigger problem is that photoshop would not be able to save intermediate drafts to the Google Drive app. It would either not save them at all, which means risking more dataloss in case of a crash or accidentally closing the app, or it would have to save them somewhere in photoshop's storage area. In case of crash it would be awkward to get the edited data back into Google drive. The user would have to relaunch the edit activity and select photoshop again, and then photoshop would have to detect that the same file was being edited and offer to reuse the previously saved draft.<br />
<br />
A desired flow here is instead to enable Google Drive to launch the "edit" activity such that Photoshop could be opened in a new window. But also enable Photoshop to have an open communication channel back to Google Drive. However the user should be able to close the Google Drive tab while still enabling Photoshop to send data to Google Drive in order to save intermediate drafts.<br />
<br />
'''Recommended solutions'''<br />
<br />
When launching an activity, it should be possible to also provide "back channel" information. If provided, the activity handler would be able to postMessage arbitrary information back to the app that initiated the activity.<br />
<br />
These messages would likely need to be sent not to the execution context that initiated the activity, but rather to its Service Worker. This way messages can be sent even if the execution context that initiated the activity has been closed.<br />
<br />
The app initiating the activity would also need to provide some arbitrary data which is passed back any time messages are sent from the activity handler and which can't be altered by the activity handler. In the example above the Google Drive app could provide the filename of the file being edited.<br />
<br />
== Ability to switch from inline to full-window handler ==<br />
<br />
A disposition:inline handler might need to defer to a more complex UI depending on user actions. For example a facebook "share" handler might start as an inline handler, but need to switch to a more complex UI if the user wants to configure security settings or add complex data to the post.<br />
<br />
This gets especially tricky for activity handlers that return a value. In this case the full-window handler would need to be rendered on top of the current app, I.e. it couldn't be handled like a normal window.open with target=_blank. Additionally the new page needs to take over the responsibility of returning a value.<br />
<br />
'''Recommended solutions'''<br />
<br />
Sadly I don't have any recommendations here. Possibly simply not supporting this scenario is the right solution for now. Instead we can allow a display:inline handler to resize itself to handle the more complex UI.<br />
<br />
What might help is to force this scenario to be handled by allowing a ServiceWorker to handle the activity and then allowing the ServiceWorker to open inline or full-window handlers on top of the initiating app.<br />
<br />
Activity handlers that don't return a value can always open new pages using target=_blank links or window.open calls.<br />
<br />
== Should activity launcher have a say in the disposition of the handler? ==<br />
<br />
''This is mostly based on notes from a WebActivities/Web Intents discussion. I sadly don't remember all the details here.''<br />
<br />
For activities that do not return a value, the initiating app might want to treat launching the activity handler as either a "navigation" or as a "open in new tab".<br />
<br />
In the Google Drive/Photoshop example above, it seems like it should be the decision of the Google Drive app if Photoshop should replace the Google Drive app, or if opening Photoshop should be treated like opening a <tt>&lt;a target="_blank"&gt;</tt> link.<br />
<br />
'''Recommended solutions'''<br />
<br />
We could support a ''target'' attribute when initiating an activity. The target would be ignored for activities that return a value, and possibly also for disposition:inline activities. However I don't know of use cases which involve targeting named windows, so possibly a ''target'' attribute is too generic.<br />
<br />
Another question is if it should be possible to target _self if the current page is open in an iframe. I.e. should activity handlers need to worry about possibly being opened in a subframe?<br />
<br />
== Finding activity handlers that match a given activity request ==<br />
<br />
When an activity is initiated we want to fairly quickly bring up a list of apps that are able to handle the activity. In WebActivities we allow activity handlers to provide an object which describes a filter which the activity data is matched against.<br />
<br />
However it's proven pretty hard to find a format to express these filters. For example for the "pick" activity if an application asks for a picture it could do that either by specifying any of <tt>type: 'image/*'</tt>, <tt>type: 'image/gif'</tt> or <tt>type: 'image/jpg'</tt>. So any activity handler for the "pick" activity that can provide an picture has to enumerate at least all of those types. And it also has to make sure that its filter matches if no specific type is requested.<br />
<br />
Another problem is that if a contact-manager app provides a handler for the "pick" activity in order to allow the user to choose a contact when a contact is explicitly requested, but not come up when the "pick" activity is activated to select an arbitrary file, i.e. when no <tt>type</tt> is specified.<br />
<br />
'''Recommended solutions'''<br />
<br />
It's possible that WebActivities' current filter mechanism actually can handle most use cases. It currently supports features like "match any of the values in this array", regexps and optional vs. required attributes. However mimetype matching has been awkward and handler applications have forgotten to enumerate wildcard types like "image/*" which means that they don't always show up when they should.<br />
<br />
Possibly the situation can be improved by providing explicit features for mimetype matching.<br />
<br />
Another thing that we might ultimately want to do is to allow passing a javascript expression which is evaluated on the activity data and then returns true/false. However this is not something we'd be able to implement in FirefoxOS right now since we're trying to keep process separation between code from different apps.<br />
<br />
== UX Problems with activity picker ==<br />
<br />
Again, Pocket has done great research on problems with activity pickers, in particular in the Android Intent implementation. One of the main points is that in situation when there's a long list of candidates for handling an activity, making it easy to access the two or three most commonly used handlers is important. All handlers should not be treated equal.<br />
<br />
[https://docs.google.com/a/readitlater.com/document/d/1S5TnrCMrtaYqPTSK3YUIE-6shWSvRONdEhm74rW7CrE/edit Pocket recommendations].<br />
<br />
== Differences between "data sources" and activities/intents ==<br />
<br />
One of the things we looked at solving with WebActivities in FirefoxOS was access to "data sources". For example the list of contacts, the list of calendar events, the music library or the camera photo stream.<br />
<br />
However due to various complexities we found that "data sources" tend to be different enough from other WebActivity use cases that we'll likely need significantly different primitives. Though there might be possible to tie in with WebActivities somehow.<br />
<br />
When granting access to for example contacts to an app, you likely want that app to have access to *all* your contacts, not just the contacts from a specific other app. So you'd want to grant access to your gmail contacts, your facebook friends, your outlook address book and any "built in" contact address book.<br />
<br />
Getting contacts from many apps at the same time can be prohibitively expensive if you have to launch all those apps, even if they don't need to render UI. Each app runs in a separate process and starting multiple processes takes a lot of CPU and memory on mobile.<br />
<br />
Displaying a merged contact list from all your contacts sources will take too long if you have to get the full contact list from each source, then merge those lists, then sort them, then reformat to get just the data you want to display in HTML form.<br />
<br />
This is even more true for a photo stream where you also need to generate thumbnails.<br />
<br />
It needs to be possible to do some of that work ahead of time and then react to any changes in those data sources before the user launches the app. Potentially it could help if the application cached the previously generated list, then ask each data source provider for changes since last time, and then update once it has received those changes. However we still want to get those updates fairly quickly to avoid the risk of the user looking at old data for too long and then having it "snap" to show the new data.<br />
<br />
When a user grants access to a data source we need to indicate if permanent access is granted, or just a one-shot access. That indicates a somewhat different UI than we want for "share" and "pick".<br />
<br />
Similarly, the UI that comes up when an application tries to access "contacts" data sources, the user needs to be able to choose multiple applications that can provide that type of data. Normally for a WebActivity the user just picks a single application to handle the activity.<br />
<br />
'''Recommended solutions'''<br />
<br />
In FirefoxOS we have implemented a "shared indexeddb-like database" API which allows one application to write a database to disk which another application can then read without the need of starting the application that owns the data source.<br />
<br />
This enabled us to allow reading "contacts" databases from multiple apps without worrying about launching multiple processes. When access to "contacts" is requested, we plan to render a "data source" specific UI which enables the user to pick multiple applications as well as choose if read vs. readwrite access is granted.<br />
<br />
It also enables knowing when the data in a data source changes, and what changes were made. This way we can wake up applications that want to precompute thumbnails or do other heavy data operations. We can also enable the UA to provide applications with the list of changes that were made since last time they updated, without requiring that each data source needs to implement this algorithm.<br />
<br />
This solution is still very experimental, and we still haven't figured out all the aspects of this.<br />
<br />
We haven't figured out the security aspects of exposing write access to the "contacts" data sources, without worrying that a rouge app could simply delete or corrupt all the user's contacts. A simple yes/no security dialog doesn't feel like enough to protect the user. So for now we are sadly relying on similar mechanisms that we use to protect TCPSocket and SD-card access, i.e. signatures from a trusted party.<br />
<br />
We also haven't figured out to to ensure that an app that has write access to contacts follows whatever format a contact should have.<br />
<br />
So for v1 I would recommend to punt on "data sources".</div>Sickinghttps://wiki.mozilla.org/index.php?title=WebAPI/WebActivities/LessonsLearned&diff=977723WebAPI/WebActivities/LessonsLearned2014-05-16T20:16:43Z<p>Sicking: /* Differences between "data sources" and activities/intents */</p>
<hr />
<div><br />
Based on internal experience, as well as experience talking with other partners like Google and Pocket, we have learned a lot about how to design the next iteration of WebActivities.<br />
<br />
Below I'll use the term 'app' not to refer to a Android/iOS installed app, but rather to the generic concept of a webapp.<br />
<br />
To simplify the discussion, here's two standard flows when using WebActivities<br />
<br />
'''Using an activity that returns a value'''<br />
# User launches facebook<br />
# User clicks "attach a picture"<br />
# Facebook launches the "pick" WebActivity<br />
# The activity picker comes up.<br />
# User chooses to use the camera app as activity handler<br />
# Camera app is launched<br />
# User takes a picture<br />
# Camera app returns the picture as result of the activity<br />
# Camera app is closed and user is back in facebook app.<br />
<br />
'''Using an activity that does not return a value'''<br />
# User goes to news website and finds an interesting article<br />
# User clicks "share" button<br />
# News website lauches the "share" WebActivity<br />
# The activity picker comes up.<br />
# User chooses to use the twitter app as activity handler<br />
# Twitter app is launched<br />
# Twitter app prefills URL of news article as tweet content<br />
# User writes short message to go along with the URL and submits the tweet<br />
<br />
== UX issues with activities that return a value ==<br />
<br />
In FirefoxOS, if the user in step 7 of the ''returns a value'' flow temporarily switches app, for example to look something up, or to answer an incoming phone call, then the activity is aborted and facebook receives an error message. We were forced to do this in order to deal with the situation when the user might switch back to the facebook app, in which case we didn't want to force facebook to deal with having to implement a sensible UI while the activity was still in progress. However aborting the activity just because the user looked something up is obviously bad.<br />
<br />
In Chrome's Web Intents, step 6 of ''returns a value'' flow launches the camera app in a separate tab in the browser. That creates an awkward relationship between the tab with the facebook app and the tab with camera app. In particular, if the user closes the facebook tab, then when the picture is taken, it's dropped on the floor since there is no facebook app to receive it.<br />
<br />
'''Recommended solutions'''<br />
<br />
For activities that return a value, the activity handler should be overlayed on top of the initiating app. I.e. in the example above the camera app should be rendered on top of the facebook app.<br />
<br />
In a small-screen device this means that the application switcher shouldn't display facebook and the camera as two separate apps currently running. Instead only the facebook app should be listed, though possibly the UI could somehow indicate that the facebook app is currently using the camera app or some such. Switching to the facebook app should render the camera app on top of it.<br />
<br />
On a large-screen device with a traditional tabbed browser UI, the camera app should be rendered in the same tab as the facebook app. I.e. the camera app would be on top of the facebook app.<br />
<br />
== UX issues with opening in activities in a new app/tab ==<br />
<br />
In FirefoxOS a webactivity always launches a new fullscreen app. This makes activities always have a fairly heavy flow since it involves two app switches, one to the activity handler, and one to switch back to the original app.<br />
<br />
Activity handlers that want to implement things like "save this for later" or "share on my photo stream" only needs to display minimal UI that doesn't take the user out of the current app.<br />
<br />
'''Recommended solutions'''<br />
<br />
We should implement a "disposition: 'inline'" like what Web Intents has. This is already specified for WebActivities but was never implemented. An inline handler would be rendered like a "dialog" on top of the current app.<br />
<br />
On large-screen devices this likely means that it sizes to content. On small-screen devices this might simply mean that it doesn't take up the full screen.<br />
<br />
Pocket also has dome some really great research [https://docs.google.com/a/readitlater.com/document/d/1S5TnrCMrtaYqPTSK3YUIE-6shWSvRONdEhm74rW7CrE/edit here].<br />
<br />
This research proposes even allowing overlays that render directly on top of the initiating app. This provides for some pretty awesome UI, but also exposes issues like clickjacking. Ideally disposition:inline can bring most of the benefits of this proposal, while still not exposing clickjacking risks.<br />
<br />
== UX issues if the handler app is already running when the activity is launched ==<br />
<br />
In FirefoxOS's implementation of WebActivities, if the twitter app was already running in the background when the ''does not return a value'' flow happens, we switch to the twitter app and send a message to it and ask it to handle the activity. However this means that the app has to leave it's current state in order to do so. So if the user was in the middle of some other task within the twitter app, that is now lost.<br />
<br />
'''Recommended solutions'''<br />
<br />
If we follow the recommendation above for [[#UX issues with activities that return a value|UX issues with activities that return a value]] that actually solves the problem for activities that return a value. A new page will always be opened and rendered on top of the app that initiated the activity.<br />
<br />
Likewise disposition:inline activities will also not suffer this problem since they open a new page inside the inline UI on top of the page that initiated the activity.<br />
<br />
For other activity handlers a good default is likely to always open a new tab to handle the activity.<br />
<br />
But we could also enable handing an activity using an existing page by allowing using a ServiceWorker as activity handler, and then allow the service worker to delegate to an already open page. Possibly we could even allow the ServiceWorker to open a disposition:inline activity.<br />
<br />
== Lack of ability to save intermediate results ==<br />
<br />
Consider a "Google Drive" app that uses an "edit" activity to launch a "photoshop" app in order to edit a picture file.<br />
<br />
In the current WebActivities and Web Intents implementations, the only way to accomplish this would be to have the photoshop "edit" activity handler return the edited image once the user was done editing, and then have the Google Drive app save the resulting file.<br />
<br />
There are a couple of issues with this flow though. First off given that the activity would be one returning a value, the photoshop app would have to be opened on top of Google Drive. This isn't always desirable.<br />
<br />
A bigger problem is that photoshop would not be able to save intermediate drafts to the Google Drive app. It would either not save them at all, which means risking more dataloss in case of a crash or accidentally closing the app, or it would have to save them somewhere in photoshop's storage area. In case of crash it would be awkward to get the edited data back into Google drive. The user would have to relaunch the edit activity and select photoshop again, and then photoshop would have to detect that the same file was being edited and offer to reuse the previously saved draft.<br />
<br />
A desired flow here is instead to enable Google Drive to launch the "edit" activity such that Photoshop could be opened in a new window. But also enable Photoshop to have an open communication channel back to Google Drive. However the user should be able to close the Google Drive tab while still enabling Photoshop to send data to Google Drive in order to save intermediate drafts.<br />
<br />
'''Recommended solutions'''<br />
<br />
When launching an activity, it should be possible to also provide "back channel" information. If provided, the activity handler would be able to postMessage arbitrary information back to the app that initiated the activity.<br />
<br />
These messages would likely need to be sent not to the execution context that initiated the activity, but rather to its Service Worker. This way messages can be sent even if the execution context that initiated the activity has been closed.<br />
<br />
The app initiating the activity would also need to provide some arbitrary data which is passed back any time messages are sent from the activity handler and which can't be altered by the activity handler. In the example above the Google Drive app could provide the filename of the file being edited.<br />
<br />
== Ability to switch from inline to full-window handler ==<br />
<br />
A disposition:inline handler might need to defer to a more complex UI depending on user actions. For example a facebook "share" handler might start as an inline handler, but need to switch to a more complex UI if the user wants to configure security settings or add complex data to the post.<br />
<br />
This gets especially tricky for activity handlers that return a value. In this case the full-window handler would need to be rendered on top of the current app, I.e. it couldn't be handled like a normal window.open with target=_blank. Additionally the new page needs to take over the responsibility of returning a value.<br />
<br />
'''Recommended solutions'''<br />
<br />
Sadly I don't have any recommendations here. Possibly simply not supporting this scenario is the right solution for now. Instead we can allow a display:inline handler to resize itself to handle the more complex UI.<br />
<br />
What might help is to force this scenario to be handled by allowing a ServiceWorker to handle the activity and then allowing the ServiceWorker to open inline or full-window handlers on top of the initiating app.<br />
<br />
Activity handlers that don't return a value can always open new pages using target=_blank links or window.open calls.<br />
<br />
== Should activity launcher have a say in the disposition of the handler? ==<br />
<br />
''This is mostly based on notes from a WebActivities/Web Intents discussion. I sadly don't remember all the details here.''<br />
<br />
For activities that do not return a value, the initiating app might want to treat launching the activity handler as either a "navigation" or as a "open in new tab".<br />
<br />
In the Google Drive/Photoshop example above, it seems like it should be the decision of the Google Drive app if Photoshop should replace the Google Drive app, or if opening Photoshop should be treated like opening a <tt>&lt;a target="_blank"&gt;</tt> link.<br />
<br />
'''Recommended solutions'''<br />
<br />
We could support a ''target'' attribute when initiating an activity. The target would be ignored for activities that return a value, and possibly also for disposition:inline activities. However I don't know of use cases which involve targeting named windows, so possibly a ''target'' attribute is too generic.<br />
<br />
Another question is if it should be possible to target _self if the current page is open in an iframe. I.e. should activity handlers need to worry about possibly being opened in a subframe?<br />
<br />
== Finding activity handlers that match a given activity request ==<br />
<br />
When an activity is initiated we want to fairly quickly bring up a list of apps that are able to handle the activity. In WebActivities we allow activity handlers to provide an object which describes a filter which the activity data is matched against.<br />
<br />
However it's proven pretty hard to find a format to express these filters. For example for the "pick" activity if an application asks for a picture it could do that either by specifying any of <tt>type: 'image/*'</tt>, <tt>type: 'image/gif'</tt> or <tt>type: 'image/jpg'</tt>. So any activity handler for the "pick" activity that can provide an picture has to enumerate at least all of those types. And it also has to make sure that its filter matches if no specific type is requested.<br />
<br />
Another problem is that if a contact-manager app provides a handler for the "pick" activity in order to allow the user to choose a contact when a contact is explicitly requested, but not come up when the "pick" activity is activated to select an arbitrary file, i.e. when no <tt>type</tt> is specified.<br />
<br />
'''Recommended solutions'''<br />
<br />
It's possible that WebActivities' current filter mechanism actually can handle most use cases. It currently supports features like "match any of the values in this array", regexps and optional vs. required attributes. However mimetype matching has been awkward and handler applications have forgotten to enumerate wildcard types like "image/*" which means that they don't always show up when they should.<br />
<br />
Possibly the situation can be improved by providing explicit features for mimetype matching.<br />
<br />
Another thing that we might ultimately want to do is to allow passing a javascript expression which is evaluated on the activity data and then returns true/false. However this is not something we'd be able to implement in FirefoxOS right now since we're trying to keep process separation between code from different apps.<br />
<br />
== UX Problems with activity picker ==<br />
<br />
Again, Pocket has done great research on problems with activity pickers, in particular in the Android Intent implementation. One of the main points is that in situation when there's a long list of candidates for handling an activity, making it easy to access the two or three most commonly used handlers is important. All handlers should not be treated equal.<br />
<br />
[https://docs.google.com/a/readitlater.com/document/d/1S5TnrCMrtaYqPTSK3YUIE-6shWSvRONdEhm74rW7CrE/edit Pocket recommendations].<br />
<br />
== Differences between "data sources" and activities/intents ==<br />
<br />
One of the things we looked at solving with WebActivities in FirefoxOS was access to "data sources". For example the list of contacts, the list of calendar events, the music library or the camera photo stream.<br />
<br />
However due to various complexities we found that "data sources" tend to be different enough from other WebActivity use cases that we'll likely need significantly different primitives. Though there might be possible to tie in with WebActivities somehow.<br />
<br />
When granting access to for example contacts to an app, you likely want that app to have access to *all* your contacts, not just the contacts from a specific other app. So you'd want to grant access to your gmail contacts, your facebook friends, your outlook address book and any "built in" contact address book.<br />
<br />
Getting contacts from many apps at the same time can be prohibitively expensive if you have to launch all those apps, even if they don't need to render UI. Each app runs in a separate process and starting multiple processes takes a lot of CPU and memory on mobile.<br />
<br />
Displaying a merged contact list from all your contacts sources will take too long if you have to get the full contact list from each source, then merge those lists, then sort them, then reformat to get just the data you want to display in HTML form.<br />
<br />
This is even more true for a photo stream where you also need to generate thumbnails.<br />
<br />
It needs to be possible to do some of that work ahead of time and then react to any changes in those data sources before the user launches the app. Potentially it could help if the application cached the previously generated list, then ask each data source provider for changes since last time, and then update once it has received those changes. However we still want to get those updates fairly quickly to avoid the risk of the user looking at old data for too long and then having it "snap" to show the new data.<br />
<br />
When a user grants access to a data source we need to indicate if permanent access is granted, or just a one-shot access. That indicates a somewhat different UI than we want for "share" and "pick".<br />
<br />
Similarly, the UI that comes up when an application tries to access "contacts" data sources, the user needs to be able to choose multiple applications that can provide that type of data. Normally for a WebActivity the user just picks a single application to handle the activity.</div>Sickinghttps://wiki.mozilla.org/index.php?title=WebAPI/WebActivities/LessonsLearned&diff=977659WebAPI/WebActivities/LessonsLearned2014-05-16T17:21:16Z<p>Sicking: </p>
<hr />
<div><br />
Based on internal experience, as well as experience talking with other partners like Google and Pocket, we have learned a lot about how to design the next iteration of WebActivities.<br />
<br />
Below I'll use the term 'app' not to refer to a Android/iOS installed app, but rather to the generic concept of a webapp.<br />
<br />
To simplify the discussion, here's two standard flows when using WebActivities<br />
<br />
'''Using an activity that returns a value'''<br />
# User launches facebook<br />
# User clicks "attach a picture"<br />
# Facebook launches the "pick" WebActivity<br />
# The activity picker comes up.<br />
# User chooses to use the camera app as activity handler<br />
# Camera app is launched<br />
# User takes a picture<br />
# Camera app returns the picture as result of the activity<br />
# Camera app is closed and user is back in facebook app.<br />
<br />
'''Using an activity that does not return a value'''<br />
# User goes to news website and finds an interesting article<br />
# User clicks "share" button<br />
# News website lauches the "share" WebActivity<br />
# The activity picker comes up.<br />
# User chooses to use the twitter app as activity handler<br />
# Twitter app is launched<br />
# Twitter app prefills URL of news article as tweet content<br />
# User writes short message to go along with the URL and submits the tweet<br />
<br />
== UX issues with activities that return a value ==<br />
<br />
In FirefoxOS, if the user in step 7 of the ''returns a value'' flow temporarily switches app, for example to look something up, or to answer an incoming phone call, then the activity is aborted and facebook receives an error message. We were forced to do this in order to deal with the situation when the user might switch back to the facebook app, in which case we didn't want to force facebook to deal with having to implement a sensible UI while the activity was still in progress. However aborting the activity just because the user looked something up is obviously bad.<br />
<br />
In Chrome's Web Intents, step 6 of ''returns a value'' flow launches the camera app in a separate tab in the browser. That creates an awkward relationship between the tab with the facebook app and the tab with camera app. In particular, if the user closes the facebook tab, then when the picture is taken, it's dropped on the floor since there is no facebook app to receive it.<br />
<br />
'''Recommended solutions'''<br />
<br />
For activities that return a value, the activity handler should be overlayed on top of the initiating app. I.e. in the example above the camera app should be rendered on top of the facebook app.<br />
<br />
In a small-screen device this means that the application switcher shouldn't display facebook and the camera as two separate apps currently running. Instead only the facebook app should be listed, though possibly the UI could somehow indicate that the facebook app is currently using the camera app or some such. Switching to the facebook app should render the camera app on top of it.<br />
<br />
On a large-screen device with a traditional tabbed browser UI, the camera app should be rendered in the same tab as the facebook app. I.e. the camera app would be on top of the facebook app.<br />
<br />
== UX issues with opening in activities in a new app/tab ==<br />
<br />
In FirefoxOS a webactivity always launches a new fullscreen app. This makes activities always have a fairly heavy flow since it involves two app switches, one to the activity handler, and one to switch back to the original app.<br />
<br />
Activity handlers that want to implement things like "save this for later" or "share on my photo stream" only needs to display minimal UI that doesn't take the user out of the current app.<br />
<br />
'''Recommended solutions'''<br />
<br />
We should implement a "disposition: 'inline'" like what Web Intents has. This is already specified for WebActivities but was never implemented. An inline handler would be rendered like a "dialog" on top of the current app.<br />
<br />
On large-screen devices this likely means that it sizes to content. On small-screen devices this might simply mean that it doesn't take up the full screen.<br />
<br />
Pocket also has dome some really great research [https://docs.google.com/a/readitlater.com/document/d/1S5TnrCMrtaYqPTSK3YUIE-6shWSvRONdEhm74rW7CrE/edit here].<br />
<br />
This research proposes even allowing overlays that render directly on top of the initiating app. This provides for some pretty awesome UI, but also exposes issues like clickjacking. Ideally disposition:inline can bring most of the benefits of this proposal, while still not exposing clickjacking risks.<br />
<br />
== UX issues if the handler app is already running when the activity is launched ==<br />
<br />
In FirefoxOS's implementation of WebActivities, if the twitter app was already running in the background when the ''does not return a value'' flow happens, we switch to the twitter app and send a message to it and ask it to handle the activity. However this means that the app has to leave it's current state in order to do so. So if the user was in the middle of some other task within the twitter app, that is now lost.<br />
<br />
'''Recommended solutions'''<br />
<br />
If we follow the recommendation above for [[#UX issues with activities that return a value|UX issues with activities that return a value]] that actually solves the problem for activities that return a value. A new page will always be opened and rendered on top of the app that initiated the activity.<br />
<br />
Likewise disposition:inline activities will also not suffer this problem since they open a new page inside the inline UI on top of the page that initiated the activity.<br />
<br />
For other activity handlers a good default is likely to always open a new tab to handle the activity.<br />
<br />
But we could also enable handing an activity using an existing page by allowing using a ServiceWorker as activity handler, and then allow the service worker to delegate to an already open page. Possibly we could even allow the ServiceWorker to open a disposition:inline activity.<br />
<br />
== Lack of ability to save intermediate results ==<br />
<br />
Consider a "Google Drive" app that uses an "edit" activity to launch a "photoshop" app in order to edit a picture file.<br />
<br />
In the current WebActivities and Web Intents implementations, the only way to accomplish this would be to have the photoshop "edit" activity handler return the edited image once the user was done editing, and then have the Google Drive app save the resulting file.<br />
<br />
There are a couple of issues with this flow though. First off given that the activity would be one returning a value, the photoshop app would have to be opened on top of Google Drive. This isn't always desirable.<br />
<br />
A bigger problem is that photoshop would not be able to save intermediate drafts to the Google Drive app. It would either not save them at all, which means risking more dataloss in case of a crash or accidentally closing the app, or it would have to save them somewhere in photoshop's storage area. In case of crash it would be awkward to get the edited data back into Google drive. The user would have to relaunch the edit activity and select photoshop again, and then photoshop would have to detect that the same file was being edited and offer to reuse the previously saved draft.<br />
<br />
A desired flow here is instead to enable Google Drive to launch the "edit" activity such that Photoshop could be opened in a new window. But also enable Photoshop to have an open communication channel back to Google Drive. However the user should be able to close the Google Drive tab while still enabling Photoshop to send data to Google Drive in order to save intermediate drafts.<br />
<br />
'''Recommended solutions'''<br />
<br />
When launching an activity, it should be possible to also provide "back channel" information. If provided, the activity handler would be able to postMessage arbitrary information back to the app that initiated the activity.<br />
<br />
These messages would likely need to be sent not to the execution context that initiated the activity, but rather to its Service Worker. This way messages can be sent even if the execution context that initiated the activity has been closed.<br />
<br />
The app initiating the activity would also need to provide some arbitrary data which is passed back any time messages are sent from the activity handler and which can't be altered by the activity handler. In the example above the Google Drive app could provide the filename of the file being edited.<br />
<br />
== Ability to switch from inline to full-window handler ==<br />
<br />
A disposition:inline handler might need to defer to a more complex UI depending on user actions. For example a facebook "share" handler might start as an inline handler, but need to switch to a more complex UI if the user wants to configure security settings or add complex data to the post.<br />
<br />
This gets especially tricky for activity handlers that return a value. In this case the full-window handler would need to be rendered on top of the current app, I.e. it couldn't be handled like a normal window.open with target=_blank. Additionally the new page needs to take over the responsibility of returning a value.<br />
<br />
'''Recommended solutions'''<br />
<br />
Sadly I don't have any recommendations here. Possibly simply not supporting this scenario is the right solution for now. Instead we can allow a display:inline handler to resize itself to handle the more complex UI.<br />
<br />
What might help is to force this scenario to be handled by allowing a ServiceWorker to handle the activity and then allowing the ServiceWorker to open inline or full-window handlers on top of the initiating app.<br />
<br />
Activity handlers that don't return a value can always open new pages using target=_blank links or window.open calls.<br />
<br />
== Should activity launcher have a say in the disposition of the handler? ==<br />
<br />
''This is mostly based on notes from a WebActivities/Web Intents discussion. I sadly don't remember all the details here.''<br />
<br />
For activities that do not return a value, the initiating app might want to treat launching the activity handler as either a "navigation" or as a "open in new tab".<br />
<br />
In the Google Drive/Photoshop example above, it seems like it should be the decision of the Google Drive app if Photoshop should replace the Google Drive app, or if opening Photoshop should be treated like opening a <tt>&lt;a target="_blank"&gt;</tt> link.<br />
<br />
'''Recommended solutions'''<br />
<br />
We could support a ''target'' attribute when initiating an activity. The target would be ignored for activities that return a value, and possibly also for disposition:inline activities. However I don't know of use cases which involve targeting named windows, so possibly a ''target'' attribute is too generic.<br />
<br />
Another question is if it should be possible to target _self if the current page is open in an iframe. I.e. should activity handlers need to worry about possibly being opened in a subframe?<br />
<br />
== Finding activity handlers that match a given activity request ==<br />
<br />
When an activity is initiated we want to fairly quickly bring up a list of apps that are able to handle the activity. In WebActivities we allow activity handlers to provide an object which describes a filter which the activity data is matched against.<br />
<br />
However it's proven pretty hard to find a format to express these filters. For example for the "pick" activity if an application asks for a picture it could do that either by specifying any of <tt>type: 'image/*'</tt>, <tt>type: 'image/gif'</tt> or <tt>type: 'image/jpg'</tt>. So any activity handler for the "pick" activity that can provide an picture has to enumerate at least all of those types. And it also has to make sure that its filter matches if no specific type is requested.<br />
<br />
Another problem is that if a contact-manager app provides a handler for the "pick" activity in order to allow the user to choose a contact when a contact is explicitly requested, but not come up when the "pick" activity is activated to select an arbitrary file, i.e. when no <tt>type</tt> is specified.<br />
<br />
'''Recommended solutions'''<br />
<br />
It's possible that WebActivities' current filter mechanism actually can handle most use cases. It currently supports features like "match any of the values in this array", regexps and optional vs. required attributes. However mimetype matching has been awkward and handler applications have forgotten to enumerate wildcard types like "image/*" which means that they don't always show up when they should.<br />
<br />
Possibly the situation can be improved by providing explicit features for mimetype matching.<br />
<br />
Another thing that we might ultimately want to do is to allow passing a javascript expression which is evaluated on the activity data and then returns true/false. However this is not something we'd be able to implement in FirefoxOS right now since we're trying to keep process separation between code from different apps.<br />
<br />
== UX Problems with activity picker ==<br />
<br />
Again, Pocket has done great research on problems with activity pickers, in particular in the Android Intent implementation. One of the main points is that in situation when there's a long list of candidates for handling an activity, making it easy to access the two or three most commonly used handlers is important. All handlers should not be treated equal.<br />
<br />
[https://docs.google.com/a/readitlater.com/document/d/1S5TnrCMrtaYqPTSK3YUIE-6shWSvRONdEhm74rW7CrE/edit Pocket recommendations].<br />
<br />
== Differences between "data sources" and activities/intents ==<br />
<br />
One of the things we looked at solving with WebActivities in FirefoxOS was access to "data sources". For example the list of contacts, the list of calendar events, the music library or the camera photo stream.<br />
<br />
However due to various complexities we found that "data sources" tend to be different enough from other WebActivity use cases that we'll likely need significantly different primitives. Though there might be possible to tie in with WebActivities somehow.<br />
<br />
When granting access to for example contacts to an app, you likely want that app to have access to *all* your contacts, not just the contacts from a specific other app. So you'd want to grant access to your gmail contacts, your facebook friends, your outlook address book and any "built in" contact address book.<br />
<br />
Getting contacts from many apps at the same time can be prohibitevly expensive if you have to launch all those apps, even if they don't need to render UI. Each app runs in a separate process and starting g multiple processes takes too much CPU and memory on mobile.<br />
<br />
Displaying a merged contact list from all your contacts sources will take too long if you have to get the full contact list from each source, then merge those lists, then sort them, then reformat to get just the data you want to display in HTML form.<br />
<br />
This is even more true for a photo stream where you also need to generate thumbnails.<br />
<br />
It needs to be possible to do some of that work ahead of time and then react to any changes in those data sources before the user launches the app. Or at the very least you need to be able to cache the result from last time you generated the contact list, and then get a list of changes since last time a list was generated. Though for something like thumbnail generation (the size of which can be consumer-application specific) ahead-of-time is likely desired.<br />
<br />
When a user grants access to a data source we need to indicate if permanent access is granted, or just a one-shot access. That indicates a somewhat different UI than we want for "share" and "pick".<br />
<br />
Similarly, the UI that comes up when an application tries to access "contacts" data sources, the user needs to be able to choose multiple applications that can provide that type of data. Normally for a WebActivity the user just picks a single application to handle the activity.</div>Sickinghttps://wiki.mozilla.org/index.php?title=WebAPI/WebActivities/LessonsLearned&diff=975375WebAPI/WebActivities/LessonsLearned2014-05-09T17:43:56Z<p>Sicking: </p>
<hr />
<div><br />
Based on internal experience, as well as experience talking with other partners like Google and Pocket, we have learned a lot about how to design the next iteration of WebActivities.<br />
<br />
Below I'll use the term 'app' not to refer to a Android/iOS installed app, but rather to the generic concept of a webapp.<br />
<br />
To simplify the discussion, here's two standard flows when using WebActivities<br />
<br />
'''Using an activity that returns a value'''<br />
# User launches facebook<br />
# User clicks "attach a picture"<br />
# Facebook launches the "pick" WebActivity<br />
# The activity picker comes up.<br />
# User chooses to use the camera app as activity handler<br />
# Camera app is launched<br />
# User takes a picture<br />
# Camera app returns the picture as result of the activity<br />
# Camera app is closed and user is back in facebook app.<br />
<br />
'''Using an activity that does not return a value'''<br />
# User goes to news website and finds an interesting article<br />
# User clicks "share" button<br />
# News website lauches the "share" WebActivity<br />
# The activity picker comes up.<br />
# User chooses to use the twitter app as activity handler<br />
# Twitter app is launched<br />
# Twitter app prefills URL of news article as tweet content<br />
# User writes short message to go along with the URL and submits the tweet<br />
<br />
== UX issues with activities that return a value ==<br />
<br />
In FirefoxOS, if the user in step 7 of the ''returns a value'' flow temporarily switches app, for example to look something up, or to answer an incoming phone call, then the activity is aborted and facebook receives an error message. We were forced to do this in order to deal with the situation when the user might switch back to the facebook app, in which case we didn't want to force facebook to deal with having to implement a sensible UI while the activity was still in progress. However aborting the activity just because the user looked something up is obviously bad.<br />
<br />
In Chrome's Web Intents, step 6 of ''returns a value'' flow launches the camera app in a separate tab in the browser. That creates an awkward relationship between the tab with the facebook app and the tab with camera app. In particular, if the user closes the facebook tab, then when the picture is taken, it's dropped on the floor since there is no facebook app to receive it.<br />
<br />
'''Recommended solutions'''<br />
<br />
For activities that return a value, the activity handler should be overlayed on top of the initiating app. I.e. in the example above the camera app should be rendered on top of the facebook app.<br />
<br />
In a small-screen device this means that the application switcher shouldn't display facebook and the camera as two separate apps currently running. Instead only the facebook app should be listed, though possibly the UI could somehow indicate that the facebook app is currently using the camera app or some such. Switching to the facebook app should render the camera app on top of it.<br />
<br />
On a large-screen device with a traditional tabbed browser UI, the camera app should be rendered in the same tab as the facebook app. I.e. the camera app would be on top of the facebook app.<br />
<br />
== UX issues with opening in activities in a new app/tab ==<br />
<br />
In FirefoxOS a webactivity always launches a new fullscreen app. This makes activities always have a fairly heavy flow since it involves two app switches, one to the activity handler, and one to switch back to the original app.<br />
<br />
Activity handlers that want to implement things like "save this for later" or "share on my photo stream" only needs to display minimal UI that doesn't take the user out of the current app.<br />
<br />
'''Recommended solutions'''<br />
<br />
We should implement a "disposition: 'inline'" like what Web Intents has. This is already specified for WebActivities but was never implemented. An inline handler would be rendered like a "dialog" on top of the current app.<br />
<br />
On large-screen devices this likely means that it sizes to content. On small-screen devices this might simply mean that it doesn't take up the full screen.<br />
<br />
Pocket also has dome some really great research [https://docs.google.com/a/readitlater.com/document/d/1S5TnrCMrtaYqPTSK3YUIE-6shWSvRONdEhm74rW7CrE/edit here].<br />
<br />
This research proposes even allowing overlays that render directly on top of the initiating app. This provides for some pretty awesome UI, but also exposes issues like clickjacking. Ideally disposition:inline can bring most of the benefits of this proposal, while still not exposing clickjacking risks.<br />
<br />
== UX issues if the handler app is already running when the activity is launched ==<br />
<br />
In FirefoxOS's implementation of WebActivities, if the twitter app was already running in the background when the ''does not return a value'' flow happens, we switch to the twitter app and send a message to it and ask it to handle the activity. However this means that the app has to leave it's current state in order to do so. So if the user was in the middle of some other task within the twitter app, that is now lost.<br />
<br />
'''Recommended solutions'''<br />
<br />
If we follow the recommendation above for [[#UX issues with activities that return a value|UX issues with activities that return a value]] that actually solves the problem for activities that return a value. A new page will always be opened and rendered on top of the app that initiated the activity.<br />
<br />
Likewise disposition:inline activities will also not suffer this problem since they open a new page inside the inline UI on top of the page that initiated the activity.<br />
<br />
For other activity handlers a good default is likely to always open a new tab to handle the activity.<br />
<br />
But we could also enable handing an activity using an existing page by allowing using a ServiceWorker as activity handler, and then allow the service worker to delegate to an already open page. Possibly we could even allow the ServiceWorker to open a disposition:inline activity.<br />
<br />
== Lack of ability to save intermediate results ==<br />
<br />
Consider a "Google Drive" app that uses an "edit" activity to launch a "photoshop" app in order to edit a picture file.<br />
<br />
In the current WebActivities and Web Intents implementations, the only way to accomplish this would be to have the photoshop "edit" activity handler return the edited image once the user was done editing, and then have the Google Drive app save the resulting file.<br />
<br />
There are a couple of issues with this flow though. First off given that the activity would be one returning a value, the photoshop app would have to be opened on top of Google Drive. This isn't always desirable.<br />
<br />
A bigger problem is that photoshop would not be able to save intermediate drafts to the Google Drive app. It would either not save them at all, which means risking more dataloss in case of a crash or accidentally closing the app, or it would have to save them somewhere in photoshop's storage area. In case of crash it would be awkward to get the edited data back into Google drive. The user would have to relaunch the edit activity and select photoshop again, and then photoshop would have to detect that the same file was being edited and offer to reuse the previously saved draft.<br />
<br />
A desired flow here is instead to enable Google Drive to launch the "edit" activity such that Photoshop could be opened in a new window. But also enable Photoshop to have an open communication channel back to Google Drive. However the user should be able to close the Google Drive tab while still enabling Photoshop to send data to Google Drive in order to save intermediate drafts.<br />
<br />
'''Recommended solutions'''<br />
<br />
When launching an activity, it should be possible to also provide "back channel" information. If provided, the activity handler would be able to postMessage arbitrary information back to the app that initiated the activity.<br />
<br />
These messages would likely need to be sent not to the execution context that initiated the activity, but rather to its Service Worker. This way messages can be sent even if the execution context that initiated the activity has been closed.<br />
<br />
The app initiating the activity would also need to provide some arbitrary data which is passed back any time messages are sent from the activity handler and which can't be altered by the activity handler. In the example above the Google Drive app could provide the filename of the file being edited.<br />
<br />
== Ability to switch from inline to full-window handler ==<br />
<br />
A disposition:inline handler might need to defer to a more complex UI depending on user actions. For example a facebook "share" handler might start as an inline handler, but need to switch to a more complex UI if the user wants to configure security settings or add complex data to the post.<br />
<br />
This gets especially tricky for activity handlers that return a value. In this case the full-window handler would need to be rendered on top of the current app, I.e. it couldn't be handled like a normal window.open with target=_blank. Additionally the new page needs to take over the responsibility of returning a value.<br />
<br />
'''Recommended solutions'''<br />
<br />
Sadly I don't have any recommendations here. Possibly simply not supporting this scenario is the right solution for now. Instead we can allow a display:inline handler to resize itself to handle the more complex UI.<br />
<br />
What might help is to force this scenario to be handled by allowing a ServiceWorker to handle the activity and then allowing the ServiceWorker to open inline or full-window handlers on top of the initiating app.<br />
<br />
Activity handlers that don't return a value can always open new pages using target=_blank links or window.open calls.<br />
<br />
== Should activity launcher have a say in the disposition of the handler? ==<br />
<br />
''This is mostly based on notes from a WebActivities/Web Intents discussion. I sadly don't remember all the details here.''<br />
<br />
For activities that do not return a value, the initiating app might want to treat launching the activity handler as either a "navigation" or as a "open in new tab".<br />
<br />
In the Google Drive/Photoshop example above, it seems like it should be the decision of the Google Drive app if Photoshop should replace the Google Drive app, or if opening Photoshop should be treated like opening a <tt>&lt;a target="_blank"&gt;</tt> link.<br />
<br />
'''Recommended solutions'''<br />
<br />
We could support a ''target'' attribute when initiating an activity. The target would be ignored for activities that return a value, and possibly also for disposition:inline activities. However I don't know of use cases which involve targeting named windows, so possibly a ''target'' attribute is too generic.<br />
<br />
Another question is if it should be possible to target _self if the current page is open in an iframe. I.e. should activity handlers need to worry about possibly being opened in a subframe?<br />
<br />
== Finding activity handlers that match a given activity request ==<br />
<br />
When an activity is initiated we want to fairly quickly bring up a list of apps that are able to handle the activity. In WebActivities we allow activity handlers to provide an object which describes a filter which the activity data is matched against.<br />
<br />
However it's proven pretty hard to find a format to express these filters. For example for the "pick" activity if an application asks for a picture it could do that either by specifying any of <tt>type: 'image/*'</tt>, <tt>type: 'image/gif'</tt> or <tt>type: 'image/jpg'</tt>. So any activity handler for the "pick" activity that can provide an picture has to enumerate at least all of those types. And it also has to make sure that its filter matches if no specific type is requested.<br />
<br />
Another problem is that if a contact-manager app provides a handler for the "pick" activity in order to allow the user to choose a contact when a contact is explicitly requested, but not come up when the "pick" activity is activated to select an arbitrary file, i.e. when no <tt>type</tt> is specified.<br />
<br />
'''Recommended solutions'''<br />
<br />
It's possible that WebActivities' current filter mechanism actually can handle most use cases. It currently supports features like "match any of the values in this array", regexps and optional vs. required attributes. However mimetype matching has been awkward and handler applications have forgotten to enumerate wildcard types like "image/*" which means that they don't always show up when they should.<br />
<br />
Possibly the situation can be improved by providing explicit features for mimetype matching.<br />
<br />
Another thing that we might ultimately want to do is to allow passing a javascript expression which is evaluated on the activity data and then returns true/false. However this is not something we'd be able to implement in FirefoxOS right now since we're trying to keep process separation between code from different apps.<br />
<br />
== UX Problems with activity picker ==<br />
<br />
Again, Pocket has done great research on problems with activity pickers, in particular in the Android Intent implementation. One of the main points is that in situation when there's a long list of candidates for handling an activity, making it easy to access the two or three most commonly used handlers is important. All handlers should not be treated equal.<br />
<br />
[https://docs.google.com/a/readitlater.com/document/d/1S5TnrCMrtaYqPTSK3YUIE-6shWSvRONdEhm74rW7CrE/edit Pocket recommendations].</div>Sickinghttps://wiki.mozilla.org/index.php?title=WebAPI/WebActivities/LessonsLearned&diff=975182WebAPI/WebActivities/LessonsLearned2014-05-09T09:55:16Z<p>Sicking: </p>
<hr />
<div><br />
Based on internal experience, as well as experience talking with other partners like Google and Pocket, we have learned a lot about how to design the next iteration of WebActivities.<br />
<br />
Below I'll use the term 'app' not to refer to a Android/iOS installed app, but rather to the generic concept of a webapp.<br />
<br />
To simplify the discussion, here's two standard flows when using WebActivities<br />
<br />
'''Using an activity that returns a value'''<br />
# User launches facebook<br />
# User clicks "attach a picture"<br />
# Facebook launches the "pick" WebActivity<br />
# The activity picker comes up.<br />
# User chooses to use the camera app as activity handler<br />
# Camera app is launched<br />
# User takes a picture<br />
# Camera app returns the picture as result of the activity<br />
# Camera app is closed and user is back in facebook app.<br />
<br />
'''Using an activity that does not return a value'''<br />
# User goes to news website and finds an interesting article<br />
# User clicks "share" button<br />
# News website lauches the "share" WebActivity<br />
# The activity picker comes up.<br />
# User chooses to use the twitter app as activity handler<br />
# Twitter app is launched<br />
# Twitter app prefills URL of news article as tweet content<br />
# User writes short message to go along with the URL and submits the tweet<br />
<br />
== UX issues with activities that return a value ==<br />
<br />
In FirefoxOS, if the user in step 7 of the ''returns a value'' flow temporarily switches app, for example to look something up, or to answer an incoming phone call, then the activity is aborted and facebook receives an error message. We were forced to do this in order to deal with the situation when the user might switch back to the facebook app, in which case we didn't want to force facebook to deal with having to implement a sensible UI while the activity was still in progress. However aborting the activity just because the user looked something up is obviously bad.<br />
<br />
In Chrome's Web Intents, step 6 of ''returns a value'' flow launches the camera app in a separate tab in the browser. That creates an awkward relationship between the tab with the facebook app and the tab with camera app. In particular, if the user closes the facebook tab, then when the picture is taken, it's dropped on the floor since there is no facebook app to receive it.<br />
<br />
'''Recommended solutions'''<br />
<br />
For activities that return a value, the activity handler should be overlayed on top of the initiating app. I.e. in the example above the camera app should be rendered on top of the facebook app.<br />
<br />
In a small-screen device this means that the application switcher shouldn't display facebook and the camera as two separate apps currently running. Instead only the facebook app should be listed, though possibly the UI could somehow indicate that the facebook app is currently using the camera app or some such. Switching to the facebook app should render the camera app on top of it.<br />
<br />
On a large-screen device with a traditional tabbed browser UI, the camera app should be rendered in the same tab as the facebook app. I.e. the camera app would be on top of the facebook app.<br />
<br />
== UX issues with opening in activities in a new app/tab ==<br />
<br />
In FirefoxOS a webactivity always launches a new fullscreen app. This makes activities always have a fairly heavy flow since it involves two app switches, one to the activity handler, and one to switch back to the original app.<br />
<br />
Activity handlers that want to implement things like "save this for later" or "share on my photo stream" only needs to display minimal UI that doesn't take the user out of the current app.<br />
<br />
'''Recommended solutions'''<br />
<br />
We should implement a "disposition: 'inline'" like what Web Intents has. This is already specified for WebActivities but was never implemented. An inline handler would be rendered like a "dialog" on top of the current app.<br />
<br />
On large-screen devices this likely means that it sizes to content. On small-screen devices this might simply mean that it doesn't take up the full screen.<br />
<br />
Pocket also has dome some really great research [https://docs.google.com/a/readitlater.com/document/d/1S5TnrCMrtaYqPTSK3YUIE-6shWSvRONdEhm74rW7CrE/edit here].<br />
<br />
This research proposes even allowing overlays that render directly on top of the initiating app. This provides for some pretty awesome UI, but also exposes issues like clickjacking. Ideally disposition:inline can bring most of the benefits of this proposal, while still not exposing clickjacking risks.<br />
<br />
== UX issues if the handler app is already running when the activity is launched ==<br />
<br />
In FirefoxOS's implementation of WebActivities, if the twitter app was already running in the background when the ''does not return a value'' flow happens, we switch to the twitter app and send a message to it and ask it to handle the activity. However this means that the app has to leave it's current state in order to do so. So if the user was in the middle of some other task within the twitter app, that is now lost.<br />
<br />
'''Recommended solutions'''<br />
<br />
If we follow the recommendation above for [[#UX issues with activities that return a value|UX issues with activities that return a value]] that actually solves the problem for activities that return a value. A new page will always be opened and rendered on top of the app that initiated the activity.<br />
<br />
Likewise disposition:inline activities will also not suffer this problem since they open a new page inside the inline UI on top of the page that initiated the activity.<br />
<br />
For other activity handlers a good default is likely to always open a new tab to handle the activity.<br />
<br />
But we could also enable handing an activity using an existing page by allowing using a ServiceWorker as activity handler, and then allow the service worker to delegate to an already open page. Possibly we could even allow the ServiceWorker to open a disposition:inline activity.<br />
<br />
== Lack of ability to save intermediate results ==<br />
<br />
Consider a "Google Drive" app that uses an "edit" activity to launch a "photoshop" app in order to edit a picture file.<br />
<br />
In the current WebActivities and Web Intents implementations, the only way to accomplish this would be to have the photoshop "edit" activity handler return the edited image once the user was done editing, and then have the Google Drive app save the resulting file.<br />
<br />
There are a couple of issues with this flow though. First off given that the activity would be one returning a value, the photoshop app would have to be opened on top of Google Drive. This isn't always desirable.<br />
<br />
A bigger problem is that photoshop would not be able to save intermediate drafts to the Google Drive app. It would either not save them at all, which means risking more dataloss in case of a crash or accidentally closing the app, or it would have to save them somewhere in photoshop's storage area. In case of crash it would be awkward to get the edited data back into Google drive. The user would have to relaunch the edit activity and select photoshop again, and then photoshop would have to detect that the same file was being edited and offer to reuse the previously saved draft.<br />
<br />
A desired flow here is instead to enable Google Drive to launch the "edit" activity such that Photoshop could be opened in a new window. But also enable Photoshop to have an open communication channel back to Google Drive. However the user should be able to close the Google Drive tab while still enabling Photoshop to send data to Google Drive in order to save intermediate drafts.<br />
<br />
'''Recommended solutions'''<br />
<br />
When launching an activity, it should be possible to also provide "back channel" information. If provided, the activity handler would be able to postMessage arbitrary information back to the app that initiated the activity.<br />
<br />
These messages would likely need to be sent not to the execution context that initiated the activity, but rather to its Service Worker. This way messages can be sent even if the execution context that initiated the activity has been closed.<br />
<br />
The app initiating the activity would also need to provide some arbitrary data which is passed back any time messages are sent from the activity handler and which can't be altered by the activity handler. In the example above the Google Drive app could provide the filename of the file being edited.<br />
<br />
== Ability to switch from inline to full-window handler ==<br />
<br />
A disposition:inline handler might need to defer to a more complex UI depending on user actions. For example a facebook "share" handler might start as an inline handler, but need to switch to a more complex UI if the user wants to configure security settings or add complex data to the post.<br />
<br />
This gets especially tricky for activity handlers that return a value. In this case the full-window handler would need to be rendered on top of the current app, I.e. it couldn't be handled like a normal window.open with target=_blank. Additionally the new page needs to take over the responsibility of returning a value.<br />
<br />
'''Recommended solutions'''<br />
<br />
Sadly I don't have any recommendations here. Possibly simply not supporting this scenario is the right solution for now. Instead we can allow a display:inline handler to resize itself to handle the more complex UI.<br />
<br />
What might help is to force this scenario to be handled by allowing a ServiceWorker to handle the activity and then allowing the ServiceWorker to open inline or full-window handlers on top of the initiating app.<br />
<br />
Activity handlers that don't return a value can always open new pages using target=_blank links or window.open calls.<br />
<br />
== Should activity launcher have a say in the disposition of the handler? ==<br />
<br />
''This is mostly based on notes from a WebActivities/Web Intents discussion. I sadly don't remember all the details here.''<br />
<br />
For activities that do not return a value, the initiating app might want to treat launching the activity handler as either a "navigation" or as a "open in new tab".<br />
<br />
In the Google Drive/Photoshop example above, it seems like it should be the decision of the Google Drive app if Photoshop should replace the Google Drive app, or if opening Photoshop should be treated like opening a <tt>&lt;a target="_blank"&gt;</tt> link.<br />
<br />
'''Recommended solutions'''<br />
<br />
We could support a ''target'' attribute when initiating an activity. The target would be ignored for activities that return a value, and possibly also for disposition:inline activities. However I don't know of use cases which involve targeting named windows, so possibly a ''target'' attribute is too generic.<br />
<br />
Another question is if it should be possible to target _self if the current page is open in an iframe. I.e. should activity handlers need to worry about possibly being opened in a subframe?<br />
<br />
== Finding activity handlers that match a given activity request ==<br />
<br />
When an activity is initiated we want to fairly quickly bring up a list of apps that are able to handle the activity. In WebActivities we allow activity handlers to provide an object which describes a filter which the activity data is matched against.<br />
<br />
However it's proven pretty hard to find a format to express these filters. For example for the "pick" activity if an application asks for a picture it could do that either by specifying any of <tt>type: 'image/*'</tt>, <tt>type: 'image/gif'</tt> or <tt>type: 'image/jpg'</tt>. So any activity handler for the "pick" activity that can provide an picture has to enumerate at least all of those types. And it also has to make sure that its filter matches if no specific type is requested.<br />
<br />
Another problem is that if a contact-manager app provides a handler for the "pick" activity in order to allow the user to choose a contact when a contact is explicitly requested, but not come up when the "pick" activity is activated to select an arbitrary file, i.e. when no <tt>type</tt> is specified.<br />
<br />
'''Recommended solutions'''<br />
<br />
It's possible that WebActivities' current filter mechanism actually can handle most use cases. It currently supports features like "match any of the values in this array", regexps and optional vs. required attributes. However mimetype matching has been awkward and handler applications have forgotten to enumerate wildcard types like "image/*" which means that they don't always show up when they should.<br />
<br />
Possibly the situation can be improved by providing explicit features for mimetype matching.<br />
<br />
Another thing that we might ultimately want to do is to allow passing a javascript expression which is evaluated on the activity data and then returns true/false. However this is not something we'd be able to implement in FirefoxOS right now since we're trying to keep process separation between code from different apps.</div>Sickinghttps://wiki.mozilla.org/index.php?title=WebAPI/WebActivities/LessonsLearned&diff=975168WebAPI/WebActivities/LessonsLearned2014-05-09T08:22:31Z<p>Sicking: </p>
<hr />
<div><br />
Based on internal experience, as well as experience talking with other partners like Google and Pocket, we have learned a lot about how to design the next iteration of WebActivities.<br />
<br />
Below I'll use the term 'app' not to refer to a Android/iOS installed app, but rather to the generic concept of a webapp.<br />
<br />
To simplify the discussion, here's two standard flows when using WebActivities<br />
<br />
'''Using an activity that returns a value'''<br />
# User launches facebook<br />
# User clicks "attach a picture"<br />
# Facebook launches the "pick" WebActivity<br />
# The activity picker comes up.<br />
# User chooses to use the camera app as activity handler<br />
# Camera app is launched<br />
# User takes a picture<br />
# Camera app returns the picture as result of the activity<br />
# Camera app is closed and user is back in facebook app.<br />
<br />
'''Using an activity that does not return a value'''<br />
# User goes to news website and finds an interesting article<br />
# User clicks "share" button<br />
# News website lauches the "share" WebActivity<br />
# The activity picker comes up.<br />
# User chooses to use the twitter app as activity handler<br />
# Twitter app is launched<br />
# Twitter app prefills URL of news article as tweet content<br />
# User writes short message to go along with the URL and submits the tweet<br />
<br />
== UX issues with activities that return a value ==<br />
<br />
In FirefoxOS, if the user in step 7 of the ''returns a value'' flow temporarily switches app, for example to look something up, or to answer an incoming phone call, then the activity is aborted and facebook receives an error message. We were forced to do this in order to deal with the situation when the user might switch back to the facebook app, in which case we didn't want to force facebook to deal with having to implement a sensible UI while the activity was still in progress. However aborting the activity just because the user looked something up is obviously bad.<br />
<br />
In Chrome's Web Intents, step 6 of ''returns a value'' flow launches the camera app in a separate tab in the browser. That creates an awkward relationship between the tab with the facebook app and the tab with camera app. In particular, if the user closes the facebook tab, then when the picture is taken, it's dropped on the floor since there is no facebook app to receive it.<br />
<br />
'''Recommended solutions'''<br />
<br />
For activities that return a value, the activity handler should be overlayed on top of the initiating app. I.e. in the example above the camera app should be rendered on top of the facebook app.<br />
<br />
In a small-screen device this means that the application switcher shouldn't display facebook and the camera as two separate apps currently running. Instead only the facebook app should be listed, though possibly the UI could somehow indicate that the facebook app is currently using the camera app or some such. Switching to the facebook app should render the camera app on top of it.<br />
<br />
On a large-screen device with a traditional tabbed browser UI, the camera app should be rendered in the same tab as the facebook app. I.e. the camera app would be on top of the facebook app.<br />
<br />
== UX issues with opening in activities in a new app/tab ==<br />
<br />
In FirefoxOS a webactivity always launches a new fullscreen app. This makes activities always have a fairly heavy flow since it involves two app switches, one to the activity handler, and one to switch back to the original app.<br />
<br />
Activity handlers that want to implement things like "save this for later" or "share on my photo stream" only needs to display minimal UI that doesn't take the user out of the current app.<br />
<br />
'''Recommended solutions'''<br />
<br />
We should implement a "disposition: 'inline'" like what Web Intents has. This is already specified for WebActivities but was never implemented. An inline handler would be rendered like a "dialog" on top of the current app.<br />
<br />
On large-screen devices this likely means that it sizes to content. On small-screen devices this might simply mean that it doesn't take up the full screen.<br />
<br />
Pocket also has dome some really great research [https://docs.google.com/a/readitlater.com/document/d/1S5TnrCMrtaYqPTSK3YUIE-6shWSvRONdEhm74rW7CrE/edit here].<br />
<br />
This research proposes even allowing overlays that render directly on top of the initiating app. This provides for some pretty awesome UI, but also exposes issues like clickjacking. Ideally disposition:inline can bring most of the benefits of this proposal, while still not exposing clickjacking risks.<br />
<br />
== UX issues if the handler app is already running when the activity is launched ==<br />
<br />
In FirefoxOS's implementation of WebActivities, if the twitter app was already running in the background when the ''does not return a value'' flow happens, we switch to the twitter app and send a message to it and ask it to handle the activity. However this means that the app has to leave it's current state in order to do so. So if the user was in the middle of some other task within the twitter app, that is now lost.<br />
<br />
'''Recommended solutions'''<br />
<br />
If we follow the recommendation above for [[#UX issues with activities that return a value|UX issues with activities that return a value]] that actually solves the problem for activities that return a value. A new page will always be opened and rendered on top of the app that initiated the activity.<br />
<br />
Likewise disposition:inline activities will also not suffer this problem since they open a new page inside the inline UI on top of the page that initiated the activity.<br />
<br />
For other activity handlers a good default is likely to always open a new tab to handle the activity.<br />
<br />
But we could also enable handing an activity using an existing page by allowing using a ServiceWorker as activity handler, and then allow the service worker to delegate to an already open page. Possibly we could even allow the ServiceWorker to open a disposition:inline activity.<br />
<br />
== Lack of ability to save intermediate results ==<br />
<br />
Consider a "Google Drive" app that uses an "edit" activity to launch a "photoshop" app in order to edit a picture file.<br />
<br />
In the current WebActivities and Web Intents implementations, the only way to accomplish this would be to have the photoshop "edit" activity handler return the edited image once the user was done editing, and then have the Google Drive app save the resulting file.<br />
<br />
There are a couple of issues with this flow though. First off given that the activity would be one returning a value, the photoshop app would have to be opened on top of Google Drive. This isn't always desirable.<br />
<br />
A bigger problem is that photoshop would not be able to save intermediate drafts to the Google Drive app. It would either not save them at all, which means risking more dataloss in case of a crash or accidentally closing the app, or it would have to save them somewhere in photoshop's storage area. In case of crash it would be awkward to get the edited data back into Google drive. The user would have to relaunch the edit activity and select photoshop again, and then photoshop would have to detect that the same file was being edited and offer to reuse the previously saved draft.<br />
<br />
A desired flow here is instead to enable Google Drive to launch the "edit" activity such that Photoshop could be opened in a new window. But also enable Photoshop to have an open communication channel back to Google Drive. However the user should be able to close the Google Drive tab while still enabling Photoshop to send data to Google Drive in order to save intermediate drafts.<br />
<br />
'''Recommended solutions'''<br />
<br />
When launching an activity, it should be possible to also provide "back channel" information. If provided, the activity handler would be able to postMessage arbitrary information back to the app that initiated the activity.<br />
<br />
These messages would likely need to be sent not to the execution context that initiated the activity, but rather to its Service Worker. This way messages can be sent even if the execution context that initiated the activity has been closed.<br />
<br />
The app initiating the activity would also need to provide some arbitrary data which is passed back any time messages are sent from the activity handler and which can't be altered by the activity handler. In the example above the Google Drive app could provide the filename of the file being edited.<br />
<br />
== Ability to switch from inline to full-window handler ==<br />
<br />
A disposition:inline handler might need to defer to a more complex UI depending on user actions. For example a facebook "share" handler might start as an inline handler, but need to switch to a more complex UI if the user wants to configure security settings or add complex data to the post.<br />
<br />
This gets especially tricky for activity handlers that return a value. In this case the full-window handler would need to be rendered on top of the current app, I.e. it couldn't be handled like a normal window.open with target=_blank. Additionally the new page needs to take over the responsibility of returning a value.<br />
<br />
'''Recommended solutions'''<br />
<br />
Sadly I don't have any recommendations here. Possibly simply not supporting this scenario is the right solution for now. Instead we can allow a display:inline handler to resize itself to handle the more complex UI.<br />
<br />
What might help is to force this scenario to be handled by allowing a ServiceWorker to handle the activity and then allowing the ServiceWorker to open inline or full-window handlers on top of the initiating app.<br />
<br />
Activity handlers that don't return a value can always open new pages using target=_blank links or window.open calls.<br />
<br />
== Should activity launcher have a say in the disposition of the handler? ==<br />
<br />
''This is mostly based on notes from a WebActivities/Web Intents discussion. I sadly don't remember all the details here.''<br />
<br />
For activities that do not return a value, the initiating app might want to treat launching the activity handler as either a "navigation" or as a "open in new tab".<br />
<br />
In the Google Drive/Photoshop example above, it seems like it should be the decision of the Google Drive app if Photoshop should replace the Google Drive app, or if opening Photoshop should be treated like opening a <tt>&lt;a target="_blank"&gt;</tt> link.<br />
<br />
'''Recommended solutions'''<br />
<br />
We could support a ''target'' attribute when initiating an activity. The target would be ignored for activities that return a value, and possibly also for disposition:inline activities. However I don't know of use cases which involve targeting named windows, so possibly a ''target'' attribute is too generic.<br />
<br />
Another question is if it should be possible to target _self if the current page is open in an iframe. I.e. should activity handlers need to worry about possibly being opened in a subframe?</div>Sickinghttps://wiki.mozilla.org/index.php?title=WebAPI/WebActivities/LessonsLearned&diff=975163WebAPI/WebActivities/LessonsLearned2014-05-09T07:14:40Z<p>Sicking: /* Lessons Learned */</p>
<hr />
<div><br />
Based on internal experience, as well as experience talking with other partners like Google and Pocket, we have learned a lot about how to design the next iteration of WebActivities.<br />
<br />
To simplify the discussion, here's two standard flows when using WebActivities<br />
<br />
'''Using an activity that returns a value'''<br />
# User launches facebook<br />
# User clicks "attach a picture"<br />
# Facebook launches the "pick" WebActivity<br />
# The activity picker comes up.<br />
# User chooses to use the camera app as activity handler<br />
# Camera app is launched<br />
# User takes a picture<br />
# Camera app returns the picture as result of the activity<br />
# Camera app is closed and user is back in facebook app.<br />
<br />
'''Using an activity that does not return a value'''<br />
# User goes to news website and finds an interesting article<br />
# User clicks "share" button<br />
# News website lauches the "share" WebActivity<br />
# The activity picker comes up.<br />
# User chooses to use the twitter app as activity handler<br />
# Twitter app is launched<br />
# Twitter app prefills URL of news article as tweet content<br />
# User writes short message to go along with the URL and submits the tweet<br />
<br />
== UX issues with activities that return a value ==<br />
<br />
In FirefoxOS, if the user in step 7 of the ''returns a value'' flow temporarily switches app, for example to look something up, or to answer an incoming phone call, then the activity is aborted and facebook receives an error message. We were forced to do this in order to deal with the situation when the user might switch back to the facebook app, in which case we didn't want to force facebook to deal with having to implement a sensible UI while the activity was still in progress. However aborting the activity just because the user looked something up is obviously bad.<br />
<br />
In Chrome's Web Intents, step 6 of ''returns a value'' flow launches the camera app in a separate tab in the browser. That creates an awkward relationship between the tab with the facebook app and the tab with camera app. In particular, if the user closes the facebook tab, then when the picture is taken, it's dropped on the floor since there is no facebook app to receive it.<br />
<br />
'''Recommended solutions'''<br />
<br />
For activities that return a value, the activity handler should be overlayed on top of the initiating app. I.e. in the example above the camera app should be rendered on top of the facebook app.<br />
<br />
In a small-screen device this means that the application switcher shouldn't display facebook and the camera as two separate apps currently running. Instead only the facebook app should be listed, though possibly the UI could somehow indicate that the facebook app is currently using the camera app or some such. Switching to the facebook app should render the camera app on top of it.<br />
<br />
On a large-screen device with a traditional tabbed browser UI, the camera app should be rendered in the same tab as the facebook app. I.e. the camera app would be on top of the facebook app.<br />
<br />
== UX issues with opening in activities in a new app/tab ==<br />
<br />
In FirefoxOS a webactivity always launches a new fullpage app. This makes activities always have a fairly heavy flow since it involves two app switches, one to the activity handler, and one to switch back to the original app.<br />
<br />
Activity handlers that want to implement things like "save this for later" or "share on my photo stream" only needs to display minimal UI that doesn't take the user out of the current app.<br />
<br />
'''Recommended solutions'''<br />
<br />
We should implement a "disposition: 'inline'" like what Web Intents has. This is already specified for WebActivities but was never implemented. An inline handler would be rendered like a "dialog" on top of the current app.<br />
<br />
On large-screen devices this likely means that it sizes to content. On small-screen devices this might simply mean that it doesn't take up the full screen.<br />
<br />
Pocket also has dome some really great research [https://docs.google.com/a/readitlater.com/document/d/1S5TnrCMrtaYqPTSK3YUIE-6shWSvRONdEhm74rW7CrE/edit here].<br />
<br />
This research proposes even allowing overlays that render directly on top of the initiating app. This provides for some pretty awesome UI, but also exposes issues like clickjacking. Ideally disposition:inline can bring most of the benefits of this proposal, while still not exposing clickjacking risks.<br />
<br />
== UX issues if the handler app is already running when the activity is launched ==<br />
<br />
In FirefoxOS's implementation of WebActivities, if the twitter app was already running in the background when the ''does not return a value'' flow happens, we switch to the twitter app and send a message to it and ask it to handle the activity. However this means that the app has to leave it's current state in order to do so. So if the user was in the middle of some other task within the twitter app, that is now lost.<br />
<br />
'''Recommended solutions'''<br />
<br />
If we follow the recommendation above for [[#UX issues with activities that return a value|UX issues with activities that return a value]] that actually solves the problem for activities that return a value. A new page will always be opened and rendered on top of the app that initiated the activity.<br />
<br />
Likewise disposition:inline activities will also not suffer this problem since they open a new page inside the inline UI on top of the page that initiated the activity.<br />
<br />
For other activity handlers a good default is likely to always open a new tab to handle the activity.<br />
<br />
We could also allow using a ServiceWorker as activity handler, and then allow the service worker to decide if a new page or an existing page should handle the activity. Possibly we could even allow the ServiceWorker to open a disposition:inline activity.<br />
<br />
== Lack of ability to save intermediate results ==<br />
<br />
Consider a "Google Drive" page that uses an "edit" activity to launch a "photoshop" page in order to edit a picture file.<br />
<br />
In the current WebActivities and Web Intents implementations, the only way to accomplish this would be to have the photoshop "edit" activity handler return the edited image once the user was done editing, and then have the Google Drive page save the resulting file.<br />
<br />
There are a couple of issues with this flow though. First off given that the activity would be one returning a value, the photoshop app would have to be opened on top of Google Drive. This isn't always desirable.<br />
<br />
A bigger problem is that photoshop would not be able to save intermediate drafts to the Google Drive page. It would either not save them at all, which means risking more dataloss in case of a crash or accidentally closing the page, or it would have to save them somewhere in photoshop's storage area. In case of crash it would be awkward to get the edited data back into Google drive. The user would have to relaunch the edit activity and select photoshop again, and then photoshop would have to detect that the same file was being edited and offer to reuse the previously saved draft.<br />
<br />
A desired flow here is instead to enable Google Drive to launch the "edit" activity such that Photoshop could be opened in a new window. But also enable Photoshop to have an open communication channel back to Google Drive. However the user should be able to close the Google Drive tab while still enabling Photoshop to send data to Google Drive in order to save intermediate drafts.<br />
<br />
'''Recommended solutions'''<br />
<br />
When launching an activity, it should be possible to also provide "back channel" information. If provided, the activity handler would be able to postMessage arbitrary information back to the app that initiated the activity.<br />
<br />
These messages would likely need to be sent not to the execution context that initiated the activity, but rather to its Service Worker. This way messages can be sent even if the execution context that initiated the activity has been closed.<br />
<br />
The app initiating the activity would also need to provide some arbitrary data which is passed back any time messages are sent from the activity handler and which can't be altered by the activity handler. In the example above the Google Drive app could provide the filename of the file being edited.<br />
<br />
== Ability to switch from inline to full-page handler ==<br />
<br />
A disposition:inline handler might need to defer to a more complex UI depending on user actions. For example a facebook "share" handler might start as an inline handler, but need to switch to a more complex UI if the user wants to configure security settings or add complex data to the post.<br />
<br />
This gets especially tricky for activity handlers that return a value. In this case the full-page handler would need to be rendered on top of the current page, I.e. it couldn't be handled like a normal window.open with target=_blank. Additionally the new page needs to take over the responsibility of returning a value.<br />
<br />
'''Recommended solutions'''<br />
<br />
Sadly I don't have any recommendations here. Possibly simply not supporting this scenario is the right solution for now. Instead we can allow a display:inline handler to resize itself to handle the more complex UI.<br />
<br />
And activity handlers that don't return a value can always open new tabs using target=_blank links or window.open calls.<br />
<br />
== Should activity launcher have a say in the disposition of the handler? ==<br />
<br />
''This is mostly based on notes from a WebActivities/Web Intents discussion. I sadly don't remember all the details here.''<br />
<br />
For activities that does not return a value, the initiating page might want to treat launching the activity handler as either a "navigation" or as a "open in new tab".<br />
<br />
In the Google Drive/Photoshop example above, it seems like it should be the decision of the Google Drive app if Photoshop should replace the Google Drive page, or if opening Photoshop should be treated like opening a <tt>&lt;a target="_blank"&gt;</tt> link.<br />
<br />
'''Recommended solutions'''<br />
<br />
We could support a ''target'' attribute when initiating an activity. The target would be ignored for activities that return a value, and possibly also for disposition:inline activities. However I don't know of use cases which involve targeting named windows.<br />
<br />
Another question is if it should be possible to target _self if the current page is open in an iframe. I.e. should activity handlers need to worry about possibly being opened in a subframe?</div>Sickinghttps://wiki.mozilla.org/index.php?title=WebAPI/WebActivities/LessonsLearned&diff=975159WebAPI/WebActivities/LessonsLearned2014-05-09T07:12:39Z<p>Sicking: </p>
<hr />
<div>== Lessons Learned ==<br />
<br />
Based on internal experience, as well as experience talking with other partners like Google and Pocket, we have learned a lot about how to design the next iteration of WebActivities.<br />
<br />
To simplify the discussion, here's two standard flows when using WebActivities<br />
<br />
'''Using an activity that returns a value'''<br />
# User launches facebook<br />
# User clicks "attach a picture"<br />
# Facebook launches the "pick" WebActivity<br />
# The activity picker comes up.<br />
# User chooses to use the camera app as activity handler<br />
# Camera app is launched<br />
# User takes a picture<br />
# Camera app returns the picture as result of the activity<br />
# Camera app is closed and user is back in facebook app.<br />
<br />
'''Using an activity that does not return a value'''<br />
# User goes to news website and finds an interesting article<br />
# User clicks "share" button<br />
# News website lauches the "share" WebActivity<br />
# The activity picker comes up.<br />
# User chooses to use the twitter app as activity handler<br />
# Twitter app is launched<br />
# Twitter app prefills URL of news article as tweet content<br />
# User writes short message to go along with the URL and submits the tweet<br />
<br />
=== UX issues with activities that return a value ===<br />
<br />
In FirefoxOS, if the user in step 7 of the ''returns a value'' flow temporarily switches app, for example to look something up, or to answer an incoming phone call, then the activity is aborted and facebook receives an error message. We were forced to do this in order to deal with the situation when the user might switch back to the facebook app, in which case we didn't want to force facebook to deal with having to implement a sensible UI while the activity was still in progress. However aborting the activity just because the user looked something up is obviously bad.<br />
<br />
In Chrome's Web Intents, step 6 of ''returns a value'' flow launches the camera app in a separate tab in the browser. That creates an awkward relationship between the tab with the facebook app and the tab with camera app. In particular, if the user closes the facebook tab, then when the picture is taken, it's dropped on the floor since there is no facebook app to receive it.<br />
<br />
'''Recommended solutions'''<br />
<br />
For activities that return a value, the activity handler should be overlayed on top of the initiating app. I.e. in the example above the camera app should be rendered on top of the facebook app.<br />
<br />
In a small-screen device this means that the application switcher shouldn't display facebook and the camera as two separate apps currently running. Instead only the facebook app should be listed, though possibly the UI could somehow indicate that the facebook app is currently using the camera app or some such. Switching to the facebook app should render the camera app on top of it.<br />
<br />
On a large-screen device with a traditional tabbed browser UI, the camera app should be rendered in the same tab as the facebook app. I.e. the camera app would be on top of the facebook app.<br />
<br />
=== UX issues with opening in activities in a new app/tab ===<br />
<br />
In FirefoxOS a webactivity always launches a new fullpage app. This makes activities always have a fairly heavy flow since it involves two app switches, one to the activity handler, and one to switch back to the original app.<br />
<br />
Activity handlers that want to implement things like "save this for later" or "share on my photo stream" only needs to display minimal UI that doesn't take the user out of the current app.<br />
<br />
'''Recommended solutions'''<br />
<br />
We should implement a "disposition: 'inline'" like what Web Intents has. This is already specified for WebActivities but was never implemented. An inline handler would be rendered like a "dialog" on top of the current app.<br />
<br />
On large-screen devices this likely means that it sizes to content. On small-screen devices this might simply mean that it doesn't take up the full screen.<br />
<br />
Pocket also has dome some really great research [https://docs.google.com/a/readitlater.com/document/d/1S5TnrCMrtaYqPTSK3YUIE-6shWSvRONdEhm74rW7CrE/edit here].<br />
<br />
This research proposes even allowing overlays that render directly on top of the initiating app. This provides for some pretty awesome UI, but also exposes issues like clickjacking. Ideally disposition:inline can bring most of the benefits of this proposal, while still not exposing clickjacking risks.<br />
<br />
=== UX issues if the handler app is already running when the activity is launched ===<br />
<br />
In FirefoxOS's implementation of WebActivities, if the twitter app was already running in the background when the ''does not return a value'' flow happens, we switch to the twitter app and send a message to it and ask it to handle the activity. However this means that the app has to leave it's current state in order to do so. So if the user was in the middle of some other task within the twitter app, that is now lost.<br />
<br />
'''Recommended solutions'''<br />
<br />
If we follow the recommendation above for [[#UX issues with activities that return a value|UX issues with activities that return a value]] that actually solves the problem for activities that return a value. A new page will always be opened and rendered on top of the app that initiated the activity.<br />
<br />
Likewise disposition:inline activities will also not suffer this problem since they open a new page inside the inline UI on top of the page that initiated the activity.<br />
<br />
For other activity handlers a good default is likely to always open a new tab to handle the activity.<br />
<br />
We could also allow using a ServiceWorker as activity handler, and then allow the service worker to decide if a new page or an existing page should handle the activity. Possibly we could even allow the ServiceWorker to open a disposition:inline activity.<br />
<br />
=== Lack of ability to save intermediate results ===<br />
<br />
Consider a "Google Drive" page that uses an "edit" activity to launch a "photoshop" page in order to edit a picture file.<br />
<br />
In the current WebActivities and Web Intents implementations, the only way to accomplish this would be to have the photoshop "edit" activity handler return the edited image once the user was done editing, and then have the Google Drive page save the resulting file.<br />
<br />
There are a couple of issues with this flow though. First off given that the activity would be one returning a value, the photoshop app would have to be opened on top of Google Drive. This isn't always desirable.<br />
<br />
A bigger problem is that photoshop would not be able to save intermediate drafts to the Google Drive page. It would either not save them at all, which means risking more dataloss in case of a crash or accidentally closing the page, or it would have to save them somewhere in photoshop's storage area. In case of crash it would be awkward to get the edited data back into Google drive. The user would have to relaunch the edit activity and select photoshop again, and then photoshop would have to detect that the same file was being edited and offer to reuse the previously saved draft.<br />
<br />
A desired flow here is instead to enable Google Drive to launch the "edit" activity such that Photoshop could be opened in a new window. But also enable Photoshop to have an open communication channel back to Google Drive. However the user should be able to close the Google Drive tab while still enabling Photoshop to send data to Google Drive in order to save intermediate drafts.<br />
<br />
'''Recommended solutions'''<br />
<br />
When launching an activity, it should be possible to also provide "back channel" information. If provided, the activity handler would be able to postMessage arbitrary information back to the app that initiated the activity.<br />
<br />
These messages would likely need to be sent not to the execution context that initiated the activity, but rather to its Service Worker. This way messages can be sent even if the execution context that initiated the activity has been closed.<br />
<br />
The app initiating the activity would also need to provide some arbitrary data which is passed back any time messages are sent from the activity handler and which can't be altered by the activity handler. In the example above the Google Drive app could provide the filename of the file being edited.<br />
<br />
=== Ability to switch from inline to full-page handler ===<br />
<br />
A disposition:inline handler might need to defer to a more complex UI depending on user actions. For example a facebook "share" handler might start as an inline handler, but need to switch to a more complex UI if the user wants to configure security settings or add complex data to the post.<br />
<br />
This gets especially tricky for activity handlers that return a value. In this case the full-page handler would need to be rendered on top of the current page, I.e. it couldn't be handled like a normal window.open with target=_blank. Additionally the new page needs to take over the responsibility of returning a value.<br />
<br />
'''Recommended solutions'''<br />
<br />
Sadly I don't have any recommendations here. Possibly simply not supporting this scenario is the right solution for now. Instead we can allow a display:inline handler to resize itself to handle the more complex UI.<br />
<br />
And activity handlers that don't return a value can always open new tabs using target=_blank links or window.open calls.<br />
<br />
=== Should activity launcher have a say in disposition of the handler? ===<br />
<br />
''This is mostly based on notes from a WebActivities/Web Intents discussion. I sadly don't remember all the details here.''<br />
<br />
For activities that does not return a value, the initiating page might want to treat launching the activity handler as either a "navigation" or as a "open in new tab".<br />
<br />
In the Google Drive/Photoshop example above, it seems like it should be the decision of the Google Drive app if Photoshop should replace the Google Drive page, or if opening Photoshop should be treated like opening a <tt>&lt;a target="_blank"&gt;</tt> link.<br />
<br />
'''Recommended solutions'''<br />
<br />
We could support a ''target'' attribute when initiating an activity. The target would be ignored for activities that return a value, and possibly also for disposition:inline activities. However I don't know of use cases which involve targeting named windows.<br />
<br />
Another question is if it should be possible to target _self if the current page is open in an iframe. I.e. should activity handlers need to worry about possibly being opened in a subframe?</div>Sickinghttps://wiki.mozilla.org/index.php?title=WebAPI/WebActivities/LessonsLearned&diff=975141WebAPI/WebActivities/LessonsLearned2014-05-09T04:30:26Z<p>Sicking: </p>
<hr />
<div>== Lessons Learned ==<br />
<br />
Based on internal experience, as well as experience talking with other partners like Google and Pocket, we have learned a lot about how to design the next iteration of WebActivities.<br />
<br />
To simplify the discussion, here's two standard flows when using WebActivities<br />
<br />
'''Using an activity that returns a value'''<br />
# User launches facebook<br />
# User clicks "attach a picture"<br />
# Facebook launches the "pick" WebActivity<br />
# The activity picker comes up.<br />
# User chooses to use the camera app as activity handler<br />
# Camera app is launched<br />
# User takes a picture<br />
# Camera app returns the picture as result of the activity<br />
# Camera app is closed and user is back in facebook app.<br />
<br />
'''Using an activity that does not return a value'''<br />
# User goes to news website and finds an interesting article<br />
# User clicks "share" button<br />
# News website lauches the "share" WebActivity<br />
# The activity picker comes up.<br />
# User chooses to use the twitter app as activity handler<br />
# Twitter app is launched<br />
# Twitter app prefills URL of news article as tweet content<br />
# User writes short message to go along with the URL and submits the tweet<br />
<br />
=== UX issues with activities that return a value ===<br />
<br />
In FirefoxOS, if the user in step 7 of the ''returns a value'' flow temporarily switches app, for example to look something up, or to answer an incoming phone call, then the activity is aborted and facebook receives an error message. We were forced to do this in order to deal with the situation when the user might switch back to the facebook app, in which case we didn't want to force facebook to deal with having to implement a sensible UI while the activity was still in progress. However aborting the activity just because the user looked something up is obviously bad.<br />
<br />
In Chrome's Web Intents, step 6 of ''returns a value'' flow launches the camera app in a separate tab in the browser. That creates an awkward relationship between the tab with the facebook app and the tab with camera app. In particular, if the user closes the facebook tab, then when the picture is taken, it's dropped on the floor since there is no facebook app to receive it.<br />
<br />
'''Recommended solutions'''<br />
For activities that return a value, the activity handler should be overlayed on top of the initiating app. I.e. in the example above the camera app should be rendered on top of the facebook app.<br />
<br />
In a small-screen device this means that when the application switcher shouldn't display facebook and the camera as two separate apps currently running. Instead only the facebook app should be listed, though possibly the UI could somehow indicate that the facebook app is currently using the camera app or some such. Switching to the facebook app should render the camera app on top of it.<br />
<br />
On a large-screen device with a traditional tabbed browser UI, the camera app should be rendered in the same tab as the facebook app. I.e. the camera app would be on top of the facebook app.<br />
<br />
=== UX issues with opening in activities in a new app/tab ===<br />
<br />
In FirefoxOS a webactivity always launches a new fullpage app. This makes activities always have a fairly heavy flow since it involves two app switches, one to the activity handler, and one to switch back to the original app.<br />
<br />
Activity handlers that want to implement things like "save this for later" or "share on my photo stream" only needs to display minimal UI that doesn't take the user out of the current app.<br />
<br />
'''Recommended solutions'''<br />
We should implement a "disposition: 'inline'" like what Web Intents has. This is already specified for WebActivities but was never implemented. An inline handler would be rendered like a "dialog" on top of the current app.<br />
<br />
On large-screen devices this likely means that it sizes to content. On small-screen devices this might simply mean that it doesn't take up the full screen.<br />
<br />
Pocket also has dome some really great research [https://docs.google.com/a/readitlater.com/document/d/1S5TnrCMrtaYqPTSK3YUIE-6shWSvRONdEhm74rW7CrE/edit here].<br />
<br />
This research proposes even allowing overlays that render directly on top of the initiating app. This provides for some pretty awesome UI, but also exposes issues like clickjacking. Ideally disposition:inline can bring most of the benefits of this proposal, while still not exposing clickjacking risks.<br />
<br />
=== UX issues if the handler app is already running when the activity is launched ===<br />
<br />
In FirefoxOS's implementation of WebActivities, if the twitter app was already running in the background when the ''does not return a value'' flow happens, we switch to the twitter app and send a message to it and ask it to handle the activity. However this means that the app has to leave it's current state in order to do so. So if the user was in the middle of some other task within the twitter app, that is now lost.<br />
<br />
'''Recommended solutions'''<br />
<br />
If we follow the recommendation above for [[#UX issues with activities that return a value|UX issues with activities that return a value]] that actually solves the problem for activities that return a value. A new page will always be opened and rendered on top of the app that initiated the activity.<br />
<br />
Likewise disposition:inline activities will also not suffer this problem since they open a new page inside the inline UI on top of the page that initiated the activity.<br />
<br />
For other activity handlers a good solution might be to fire an event in the handlers ServiceWorker and let the worker decide if a new page should be opened, or if an existing page could be used. But a reasonable default seems like always opening activity handlers in a new context. I.e. only allow reusing an existing context by registering a ServiceWorker as the handler.<br />
<br />
=== Lack of ability to save intermediate results ===<br />
<br />
Consider a "Google Drive" page that uses an "edit" activity to launch a "photoshop" page in order to edit a picture file.<br />
<br />
In the current WebActivities and Web Intents implementations, the only way to accomplish this would be to have the photoshop "edit" activity handler return the edited image once the user was done editing, and then have the Google Drive page save the resulting file.<br />
<br />
There are a couple of issues with this flow though. First off given that the activity would be one returning a value, the photoshop app would have to be opened on top of Google Drive. This isn't always desirable.<br />
<br />
A bigger problem is that photoshop would not be able to save intermediate drafts to the Google Drive page. It would either not save them at all, which means risking more dataloss in case of a crash or accidentally closing the page, or it would have to save them somewhere in photoshop's storage area. In case of crash it would be awkward to get the edited data back into Google drive. The user would have to relaunch the edit activity and select photoshop again, and then photoshop would have to detect that the same file was being edited and offer to reuse the previously saved draft.<br />
<br />
A desired flow here is instead to enable Google Drive to launch the "edit" activity such that Photoshop could be opened in a new window. But also enable Photoshop to have an open communication channel back to Google Drive. However the user should be able to close the Google Drive tab while still enabling Photoshop to send data to Google Drive in order to save intermediate drafts.<br />
<br />
'''Recommended solutions'''<br />
When launching an activity, it should be possible to also provide "back channel" information. If provided, the activity handler would be able to postMessage arbitrary information back to the app that initiated the activity.<br />
<br />
These messages would likely need to be sent not to the execution context that initiated the activity, but rather to its Service Worker. This way messages can be sent even if the execution context that initiated the activity has been closed.<br />
<br />
The app initiating the activity would also need to provide some arbitrary data which is passed back any time messages are sent from the activity handler and which can't be altered by the activity handler. In the example above the Google Drive app could provide the filename of the file being edited.<br />
<br />
=== Ability to switch from inline to full-page handler ===<br />
<br />
A disposition:inline handler might need to defer to a more complex UI depending on user actions. For example a facebook "share" handler might start as an inline handler, but need to switch to a more complex UI if the user wants to configure security settings or add complex data to the post.<br />
<br />
This gets especially tricky for activity handlers that return a value. In this case the full-page handler would need to be rendered on top of the current page, I.e. it couldn't be handled like a normal window.open with target=_blank. Additionally the new page needs to take over the responsibility of returning a value.<br />
<br />
'''Recommended solution'''<br />
<br />
Sadly I don't have any recommendations here. Possibly simply not supporting this scenario is the right solution for now. Instead we can allow a display:inline handler to resize itself to handle the more complex UI.<br />
<br />
And activity handlers that don't return a value can always open new tabs using target=_blank links or window.open calls.<br />
<br />
=== Should activity launcher have a say in disposition of the handler? ===<br />
<br />
''This is mostly based on notes from a WebActivities/Web Intents discussion. I sadly don't remember all the details here.''<br />
<br />
For activities that does not return a value, the initiating page might want to treat launching the activity handler as either a "navigation" or as a "open in new tab".<br />
<br />
In the Google Drive/Photoshop example above, it seems like it should be the decision of the Google Drive app if Photoshop should replace the Google Drive page, or if opening Photoshop should be treated like opening a <tt>&lt;a target="_blank"&gt;</tt> link.<br />
<br />
'''Recommended solution'''<br />
Potentially we could support a ''target'' attribute when initiating an activity. However I don't know of use cases which would involve targeting named windows.<br />
<br />
Another question is if it should be possible to target _self if the current page is open in an iframe. I.e. should activity handlers need to worry about possibly being opened in a subframe?</div>Sickinghttps://wiki.mozilla.org/index.php?title=WebAPI/WebActivities/LessonsLearned&diff=975100WebAPI/WebActivities/LessonsLearned2014-05-09T01:43:49Z<p>Sicking: /* Lessons Learned */</p>
<hr />
<div>== Lessons Learned ==<br />
<br />
Based on internal experience, as well as experience talking with other partners like Google and Pocket, we have learned a lot about how to design the next iteration of WebActivities.<br />
<br />
To simplify the discussion, here's two standard flows when using WebActivities<br />
<br />
'''Using an activity that returns a value'''<br />
# User launches facebook<br />
# User clicks "attach a picture"<br />
# Facebook launches the "pick" WebActivity<br />
# The activity picker comes up.<br />
# User chooses to use the camera app as activity handler<br />
# Camera app is launched<br />
# User takes a picture<br />
# Camera app returns the picture as result of the activity<br />
# Camera app is closed and user is back in facebook app.<br />
<br />
'''Using an activity that does not return a value'''<br />
# User goes to news website and finds an interesting article<br />
# User clicks "share" button<br />
# News website lauches the "share" WebActivity<br />
# The activity picker comes up.<br />
# User chooses to use the twitter app as activity handler<br />
# Twitter app is launched<br />
# Twitter app prefills URL of news article as tweet content<br />
# User writes short message to go along with the URL and submits the tweet<br />
<br />
=== UX issues with activities that return a value ===<br />
<br />
In FirefoxOS, if the user in step 7 of the ''returns a value'' flow temporarily switches app, for example to look something up, or to answer an incoming phone call, then the activity is aborted and facebook receives an error message. We were forced to do this in order to deal with the situation when the user might switch back to the facebook app, in which case we didn't want to force facebook to deal with having to implement a sensible UI while the activity was still in progress. However aborting the activity just because the user looked something up is obviously bad.<br />
<br />
In Chrome's Web Intents, step 6 of ''returns a value'' flow launches the camera app in a separate tab in the browser. That creates an awkward relationship between the tab with the facebook app and the tab with camera app. In particular, if the user closes the facebook tab, then when the picture is taken, it's dropped on the floor since there is no facebook app to receive it.<br />
<br />
'''Recommended solutions'''<br />
For activities that return a value, the activity handler should be overlayed on top of the initiating app. I.e. in the example above the camera app should be rendered on top of the facebook app.<br />
<br />
In a small-screen device this means that when the application switcher shouldn't display facebook and the camera as two separate apps currently running. Instead only the facebook app should be listed, though possibly the UI could somehow indicate that the facebook app is currently using the camera app or some such. Switching to the facebook app should render the camera app on top of it.<br />
<br />
On a large-screen device with a traditional tabbed browser UI, the camera app should be rendered in the same tab as the facebook app. I.e. the camera app would be on top of the facebook app.<br />
<br />
=== UX issues with opening in activities in a new app/tab ===<br />
<br />
In FirefoxOS a webactivity always launches a new fullpage app. This makes activities always have a fairly heavy flow since it involves two app switches, one to the activity handler, and one to switch back to the original app.<br />
<br />
Activity handlers that want to implement things like "save this for later" or "share on my photo stream" only needs to display minimal UI that doesn't take the user out of the current app.<br />
<br />
'''Recommended solutions'''<br />
We should implement a "disposition: 'inline'" like what Web Intents has. This is already specified for WebActivities but was never implemented. An inline handler would be rendered like a "dialog" on top of the current app.<br />
<br />
On large-screen devices this likely means that it sizes to content. On small-screen devices this might simply mean that it doesn't take up the full screen.<br />
<br />
We'll likely need the ability for an inline activity handler to defer to a full-page handler in response to user actions. For example a facebook "share" handler might start as an inline handler, but need to switch to a fullpage UI if the user wants to configure security settings or add complex data to the post.<br />
<br />
Pocket also has dome some really great research [https://docs.google.com/a/readitlater.com/document/d/1S5TnrCMrtaYqPTSK3YUIE-6shWSvRONdEhm74rW7CrE/edit here].<br />
<br />
This research proposes even allowing overlays that render directly on top of the initiating app. This provides for some pretty awesome UI, but also exposes issues like clickjacking. Ideally disposition:inline can bring most of the benefits of this proposal, while still not exposing clickjacking risks.<br />
<br />
=== UX issues if the handler app is already running when the activity is launched ===<br />
<br />
In FirefoxOS's implementation of WebActivities, if the twitter app was already running in the background when the ''does not return a value'' flow happens, we switch to the twitter app and send a message to it and ask it to handle the activity. However this means that the app has to leave it's current state in order to do so. So if the user was in the middle of some other task within the twitter app, that is now lost.<br />
<br />
'''Recommended solutions'''<br />
If we follow the recommendation above for [[#UX issues with activities that return a value|UX issues with activities that return a value]] that actually solves the problem for activities that return a value. A new page will always be opened and rendered on top of the app that initiated the activity.<br />
<br />
Likewise disposition:inline activities will also not suffer this problem since they open a new page inside the inline UI on top of the page that initiated the activity.<br />
<br />
For other activity handlers a good solution might be to fire an event in the handlers ServiceWorker and let the worker decide if a new page should be opened, or if an existing page could be used.<br />
<br />
=== Lack of ability to save intermediate results ===<br />
<br />
Consider a "Google Drive" page that uses an "edit" activity to launch a "photoshop" page in order to edit a picture file. Once the user is done editing the picture the photoshop page could return the edited picture to the Google Drive page and Google Drive could save the edited picture using application specific logic.<br />
<br />
There are a couple of issues with this flow though. First off given that a return <br />
<br />
One flow that is currently not supported by neither WebActivities or Web Intents is the ability for a <br />
<br />
=== Ability to switch from inline to full-page handler ===<br />
<br />
=== Should activity launcher have a say in disposition of the handler? ===<br />
<br />
For activities that does not return a value, the initiating page might want to treat launching the activity handler as either a "navigation" or as a "open in new tab".</div>Sickinghttps://wiki.mozilla.org/index.php?title=WebAPI/WebActivities/LessonsLearned&diff=975080WebAPI/WebActivities/LessonsLearned2014-05-08T22:54:42Z<p>Sicking: Created page with "== Lessons Learned == Based on internal experience, as well as experience talking with other partners like Google and Pocket, we have learned a lot about how to design the ne..."</p>
<hr />
<div>== Lessons Learned ==<br />
<br />
Based on internal experience, as well as experience talking with other partners like Google and Pocket, we have learned a lot about how to design the next iteration of WebActivities.<br />
<br />
To simplify the discussion, here's two standard flows when using WebActivities<br />
<br />
'''Using an activity that returns a value'''<br />
# User launches facebook<br />
# User clicks "attach a picture"<br />
# Facebook launches the "pick" WebActivity<br />
# The activity picker comes up.<br />
# User chooses to use the camera app as activity handler<br />
# Camera app is launched<br />
# User takes a picture<br />
# Camera app returns the picture as result of the activity<br />
# Camera app is closed and user is back in facebook app.<br />
<br />
'''Using an activity that does not return a value'''<br />
# User goes to news website and finds an interesting article<br />
# User clicks "share" button<br />
# News website lauches the "share" WebActivity<br />
# The activity picker comes up.<br />
# User chooses to use the twitter app as activity handler<br />
# Twitter app is launched<br />
# Twitter app prefills URL of news article as tweet content<br />
# User writes short message to go along with the URL and submits the tweet<br />
<br />
=== UX issues with activities that return a value ===<br />
<br />
In FirefoxOS, if the user in step 7 of the ''returns a value'' flow temporarily switches app, for example to look something up, or to answer an incoming phone call, then the activity is aborted and facebook receives an error message. We were forced to do this in order to deal with the situation when the user might switch back to the facebook app, in which case we didn't want to force facebook to deal with having to implement a sensible UI while the activity was still in progress. However aborting the activity just because the user looked something up is obviously bad.<br />
<br />
In Chrome's Web Intents, step 6 of ''returns a value'' flow launches the camera app in a separate tab in the browser. That creates an awkward relationship between the tab with the facebook app and the tab with camera app. In particular, if the user closes the facebook tab, then when the picture is taken, it's dropped on the floor since there is no facebook app to receive it.<br />
<br />
'''Recommended solutions'''<br />
For activities that return a value, the activity handler should be overlayed on top of the initiating app. I.e. in the example above the camera app should be rendered on top of the facebook app.<br />
<br />
In a small-screen device this means that when the application switcher shouldn't display facebook and the camera as two separate apps currently running. Instead only the facebook app should be listed, though possibly the UI could somehow indicate that the facebook app is currently using the camera app or some such. Switching to the facebook app should render the camera app on top of it.<br />
<br />
On a large-screen device with a traditional tabbed browser UI, the camera app should be rendered in the same tab as the facebook app. I.e. the camera app would be on top of the facebook app.<br />
<br />
=== UX issues with opening in activities in a new app/tab ===<br />
<br />
In FirefoxOS a webactivity always launches a new fullpage app. This makes activities always have a fairly heavy flow since it involves two app switches, one to the activity handler, and one to switch back to the original app.<br />
<br />
Activity handlers that want to implement things like "save this for later" or "share on my photo stream" only needs to display minimal UI that doesn't take the user out of the current app.<br />
<br />
'''Recommended solutions'''<br />
We should implement a "disposition: 'inline'" like what Web Intents has. This is already specified for WebActivities but was never implemented. An inline handler would be rendered like a "dialog" on top of the current app.<br />
<br />
On large-screen devices this likely means that it sizes to content. On small-screen devices this might simply mean that it doesn't take up the full screen.<br />
<br />
We'll likely need the ability for an inline activity handler to defer to a full-page handler in response to user actions. For example a facebook "share" handler might start as an inline handler, but need to switch to a fullpage UI if the user wants to configure security settings or add complex data to the post.<br />
<br />
Pocket also has dome some really great research [https://docs.google.com/a/readitlater.com/document/d/1S5TnrCMrtaYqPTSK3YUIE-6shWSvRONdEhm74rW7CrE/edit here].<br />
<br />
=== UX issues if the handler app is already running when the activity is launched ===<br />
<br />
=== Lack of ability to save intermediate results ===<br />
<br />
=== Ability to switch from inline to full-page handler ===<br />
<br />
=== Should activity launcher have a say in disposition of the handler? ===</div>Sickinghttps://wiki.mozilla.org/index.php?title=Modules/Core&diff=903140Modules/Core2014-01-22T23:47:04Z<p>Sicking: </p>
<hr />
<div><noinclude><br />
'''Do not edit this page''' unless either:<br />
<br />
# you are a module owner who is:<br />
#* altering the list of peers in your module<br />
#* adding or removing a sub-module<br />
#* changing the owner of one of your sub-modules; or<br />
# you have agreed a change of owner or module addition/deletion with the Module Ownership Module group, probably via [https://www.mozilla.org/about/forums/#governance mozilla.governance].<br />
</noinclude><br />
{{Module<br />
|name=Accessibility<br />
|description=Support for platform accessibility APIs. Accessibility APIs are used by 3rd party software like screen readers, screen magnifiers, and voice dictation software, which need information about document content and UI controls, as well as important events like changes of focus.<br />
|owner=[mailto:surkov.alexander@gmail.com Alexander Surkov]<br />
|peers=[mailto:bolterbugz@gmail.com David Bolter], [mailto:ginn.chen@oracle.com Ginn Chen], [mailto:trev.saunders@gmail.com Trevor Saunders], [mailto:marco.zehe@googlemail.com Marco Zehe] <br />
|group=dev-accessibility<br />
|source_dirs=accessible/<br />
|url=http://www.mozilla.org/access/<br />
|components=Core::Disability Access APIs<br />
}}<br />
<br />
{{Module<br />
|name=Build and Release Tools<br />
|description=Tools related to build and release automation and configuration of release builds.<br />
|owner=[mailto:nrthomas@gmail.com Nick Thomas]<br />
|peers=[mailto:bhearsum@mozilla.com Ben Hearsum], [mailto:ccooper@deadsquid.com Chris Cooper], [mailto:cmp@mozilla.org Chase Phillips], [mailto:mozpreed@sigkill.com John Paul Reed], [mailto:robert@roberthelmer.com Robert Helmer]<br />
|group=dev-builds<br />
|source_dirs=tools/botrunner.py, tools/build-environment/, tools/build/, tools/buildbot-configs/, tools/buildbot/, tools/buildbotcustom/, tools/l10n/, tools/MozBuild/, tools/patcher-configs/, tools/patcher/, tools/release/, tools/tinderbox-configs/, tools/tinderbox/, tools/update-packaging/, browser/config/mozconfigs/, mobile/config/mozconfigs/, xulrunner/config/mozconfigs/<br />
|url=<br />
|components=mozilla.org::Release Engineering, mozilla.org::Release Engineering: Custom Builds<br />
}}<br />
<br />
{{Module<br />
|name=Build Config<br />
|description=The build system for Gecko and several mozilla.org hosted Gecko-based applications.<br />
|owner=[mailto:gps@mozilla.com Gregory Szorc] (:gps)<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg] (:bsmedberg), [mailto:mh@glandium.org Mike Hommey] (:glandium), [mailto:ted@mielczarek.org Ted Mielczarek] (:ted), [mailto:mshal@mozilla.com Mike Shal] (:mshal), [mailto:me@kylehuey.com Kyle Huey] (:khuey) (less active - send reviews to others)<br />
|group=dev-builds<br />
|source_dirs=build/, config/, python/mozbuild, tools/cross-commit, tools/cvs2hg-import.py, tools/cvsmgmt/, tools/elf-dynstr-gc/, tools/trees.pl, browser/config/mozconfigs/, mobile/config/mozconfigs/, xulrunner/config/mozconfigs/<br />
|url=http://www.mozilla.org/build/<br />
|components=Core::Build Config<br />
}}<br />
<br />
{{Module<br />
|name=Code Analysis and Debugging Tools<br />
|description=Tools for debugging Mozilla code or for analyzing speed, memory use, and other characteristics of it.<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|peers=<br />
|group=dev-performance<br />
|source_dirs=tools/codesighs/, tools/debug/, tools/dreftool/, tools/dumpdeps/, tools/footprint/, tools/jprof/, tools/leaky/, tools/memory/, tools/module-deps/, tools/performance/, tools/post_compile/, tools/preloader/, tools/rb/, tools/reorder/, tools/trace-malloc/, tools/uuiddeps/, <br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Content HTTP Headers<br />
|description=HTTP headers related to content, e.g. User-Agent, Content-Type, Accept. (Transport-related headers are the responsibility of the Necko module owner.)<br />
|owner=[mailto:gerv@mozilla.org Gervase Markham]<br />
|peers=[mailto:lmandel@mozilla.com Lawrence Mandel]<br />
|group=dev-platform<br />
|source_dirs= <br />
|url=https://developer.mozilla.org/en/Gecko_user_agent_string_reference<br />
|components=Core::Networking: HTTP<br />
}}<br />
<br />
{{Module<br />
|name=Cookies and Permissions<br />
|description=<br />
|owner=[mailto:mchew@mozilla.com Monica Chew]<br />
|peers=[mailto:josh@joshmatthews.com Josh Matthews], [mailto:ehsan@mozilla.com Ehsan Akhgari], [mailto:mconnor@steelgryphon.com Mike Connor], [mailto:dwitte@gmail.com Dan Witte], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:sdwilsh@shawnwilsher.com Shawn Wilsher (ping on irc)]<br />
|group=dev-tech-network<br />
|source_dirs=extensions/cookie/, netwerk/cookie/<br />
|url=<br />
|components=Core::Networking: Cookies<br />
}}<br />
{{Module<br />
|name=Cycle Collector<br />
|description=Code to break and collect objects within reference cycles<br />
|owner=[mailto:continuation@gmail.com Andrew McCreight]<br />
|peers=Peter Van der Beken, Olli Pettay, David Baron<br />
|source_dirs=xpcom/base/nsCycleCollector.* and some support headers<br />
|components=Core::XPCOM<br />
|group=dev-platform<br />
}}<br />
{{Module<br />
|name=docshell<br />
|description=<br />
|owner=[mailto:bzbarsky@mit.edu Boris Zbarsky]<br />
|peers=[mailto:cbiesinger@gmail.com Christian Biesinger],[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:jst@mozilla.org Johnny Stenback], [mailto:Olli.Pettay@helsinki.fi Olli Pettay], [mailto:justin.lebar@gmail.com Justin Lebar]<br />
|group=dev-tech-layout<br />
|source_dirs=docshell/, uriloader/, webshell/<br />
|url=<br />
|components=Core::Document Navigation<br />
}}<br />
<br />
{{Module<br />
|name=Device Storage<br />
|description=Support for the device storage API<br />
|owner=[mailto:dhylands@mozilla.com Dave Hylands], [mailto:jvarga@mozilla.com Jan Varga]<br />
|peers=[mailto:dougt@dougt.org Doug Turner]<br />
|group=dev-tech-dom<br />
|source_dirs=dom/devicestorage/, dom/interfaces/devicestorage/<br />
|url=https://developer.mozilla.org/en-US/docs/WebAPI/Device_Storage<br />
|components=Core::DOM: Device Interfaces<br />
}}<br />
<br />
{{Module<br />
|name=Document Object Model<br />
|description=<br />
|owner=[mailto:jst@mozilla.org Johnny Stenback], [mailto:peterv@propagandism.org Peter Van der Beken]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:jonas@sicking.cc Jonas Sicking], [mailto:Olli.Pettay@helsinki.fi Olli Pettay], [mailto:bent@mozilla.com Ben Turner], [mailto:mounir.lamouri@mozilla.com Mounir Lamouri], [mailto:khuey@kylehuey.com Kyle Huey], [mailto:justin.lebar@gmail.com Justin Lebar], [mailto:hsivonen@iki.fi Henri Sivonen], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:bobbyholley@gmail.com Bobby Holley]<br />
|group=dev-tech-dom<br />
|source_dirs=content/*, dom/*, except directories covered by other modules<br />
|url=http://developer.mozilla.org/en/docs/DOM<br />
|components=Core::DOM, Core::DOM: CSS Object Model, Core::DOM: Core & HTML, Core::DOM: Events<br />
}}<br />
<br />
{{Module<br />
|name=Web Workers<br />
|description=<br />
|owner=[mailto:bent@mozilla.com Ben Turner]<br />
|peers=[mailto:mrbkap@mozilla.com Blake Kaplan], [mailto:jonas@sicking.cc Jonas Sicking], [mailto:khuey@mozilla.com Kyle Huey]<br />
|group=dev-platform<br />
|source_dirs=dom/workers/<br />
|url=https://developer.mozilla.org/En/Using_web_workers<br />
|components=Core::DOM: Workers<br />
}}<br />
<br />
<br />
{{Module<br />
|name=IndexedDB<br />
|description=<br />
|owner=[mailto:bent@mozilla.com Ben Turner]<br />
|peers=[mailto:jonas@sicking.cc Jonas Sicking], [mailto:khuey@mozilla.com Kyle Huey], [mailto:jvarga@mozilla.com Jan Varga]<br />
|group=dev-platform<br />
|source_dirs=dom/indexedDB/<br />
|url=https://developer.mozilla.org/en/IndexedDB<br />
|components=Core::DOM: IndexedDB<br />
}}<br />
<br />
{{Module<br />
|name=Editor<br />
|description=<br />
|owner=[mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|peers=<br />
|group=dev-platform<br />
|source_dirs=editor/<br />
|url=http://www.mozilla.org/editor/<br />
|components=Core::Editor<br />
}}<br />
<br />
{{Module<br />
|name=Embedding<br />
|description=<br />
|owner=[mailto:benjamin@smedbergs.us Benjamin Smedberg]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:jst@mozilla.org Johnny Stenback]<br />
|group=dev-embedding<br />
|source_dirs=embedding/<br />
|url=<br />
|components=Core::Embedding: APIs, Core::Embedding: ActiveX Wrapper, Core::Embedding: GRE Core, Core::Embedding: GTK Widget, Core::Embedding: MFC Embed, Core::Embedding: Mac, Core::Embedding: Packaging<br />
}}<br />
<br />
{{Module<br />
|name=Find As You Type<br />
|description=Find As You Type (formerly called Type Ahead Find) is a feature that allows quick web page navigation when you type a succession of characters in the body of the displayed page (not in an edit box of or drop down list). Currently seeks new owner.<br />
|owner=<br />
|peers=<br />
|group=dev-accessibility<br />
|source_dirs=extensions/typeaheadfind/<br />
|url=http://www.mozilla.org/access/type-ahead/<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Geolocation<br />
|description=Implementation of the Geolocation W3C Spec, location provider apis, and wifi scanning code.<br />
|owner=[mailto:dougt@dougt.org Doug Turner]<br />
|peers=[mailto:josh@joshmatthews.net Josh Matthews], [mailto:kchen@mozilla.com Kan-Ru Chen]<br />
|group=dev-tech-dom<br />
|source_dirs=dom/src/geolocation, dom/system/, netwerk/wifi<br />
|url=https://developer.mozilla.org/En/Using_geolocation<br />
|components=Core::Geolocation<br />
}}<br />
<br />
{{Module<br />
|name=Global Key Bindings<br />
|description=Global hot keys in Mozilla for the browser, editor, mail-news and widgets. Does not include underlined menu accelerators and the like, as those are part of i18n.<br />
|owner=[mailto:aaronleventhal@moonset.net Aaron Leventhal]<br />
|peers=[mailto:neil@parkwaycc.co.uk Neil Rashbrook]<br />
|group=dev-accessibility<br />
|source_dirs=content/xbl/builtin/<br />
|url=http://www.mozilla.org/projects/ui/accessibility/mozkeyintro.html<br />
|components=Core::Keyboard: Navigation<br />
}}<br />
<br />
{{Module<br />
|name=Graphics<br />
|description=Mozilla graphics API<br />
|owner=[mailto:jrmuizel@mozilla.com Jeff Muizelaar], [mailto:roc+@cs.cmu.edu Robert O'Callahan]<br />
|peers=[mailto:jdrew@mozilla.com Joe Drew], [mailto:vladimir@pobox.com Vladimir Vukicevic], [mailto:bas.schouten@live.nl Bas Schouten], [mailto:bjacob@mozilla.com Benoit Jacob], [mailto:bgirard@mozilla.com Benoit Girard], [mailto:ajuma.bugzilla@alijuma.com Ali Juma], [mailto:jgilbert@mozilla.com Jeff Gilbert], [mailto:george@mozilla.com George Wright], [mailto:mwoodrow@mozilla.com Matt Woodrow], [mailto:jdaggett@mozilla.com John Daggett], [mailto:jfkthame@googlemail.com Jonathan Kew], [mailto:nsilva@mozilla.com Nicolas Silva], [mailto:ncameron@mozilla.com Nick Cameron]<br />
|group=dev-platform<br />
|source_dirs=gfx/, content/canvas/src/<br />
|url=https://wiki.mozilla.org/Platform/GFX https://wiki.mozilla.org/Gecko:Layers https://wiki.mozilla.org/Gecko:2DGraphicsSketch<br />
|components=Core::Graphics, Core::Graphics: Layers, Core::Graphics: Text, Core::GFX: Color Management, Core::Canvas: 2D, Core::Canvas: WebGL<br />
}}<br />
<br />
{{Module<br />
|name=GTK Embedding Widget<br />
|description=Gtk Widget for embedding Mozilla into Gtk applications<br />
|owner=[mailto:marco@gnome.org Marco Pesenti Gritti]<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:dougt@meer.net Doug Turner]<br />
|group=dev-embedding<br />
|source_dirs=<br />
|url=<br />
|components=Core::Embedding: GTK Widget<br />
}}<br />
<br />
{{Module<br />
|name=Legacy HTML Parser<br />
|description=<br />
|owner=[mailto:mrbkap@gmail.com Blake Kaplan]<br />
|peers=[mailto:dbaron@dbaron.org David Baron], [mailto:jst@mozilla.org Johnny Stenback], [mailto:peterv@propagandism.org Peter Van der Beken], [mailto:rbs@maths.uq.edu.au rbs@maths.uq.edu.au]<br />
|group=dev-tech-dom<br />
|source_dirs=parser/htmlparser<br />
|url=http://www.mozilla.org/newlayout/doc/parser.html<br />
|components=Core::HTML: Parser<br />
}}<br />
<br />
{{Module<br />
|name=HAL<br />
|description=Hardware Abstraction Layer<br />
|owner=[mailto:cjones@mozilla.com Chris Jones]<br />
|peers=[mailto:mounir@lamouri.fr Mounir Lamouri], [mailto:jlebar@mozilla.com Justin Lebar]<br />
|group=dev-platform<br />
|source_dirs=hal/<br />
|components=Core::Hardware Abstraction Layer (HAL)<br />
}}<br />
<br />
{{Module<br />
|name=HTML Parser<br />
|description=The HTML Parser transforms HTML source code into a DOM. It conforms to the HTML specification, and is mostly translated automatically from Java to C++.<br />
|owner=[mailto:hsivonen@iki.fi Henri Sivonen]<br />
|peers=<br />
|group=dev-tech-dom<br />
|source_dirs=parser/html<br />
|url=http://about.validator.nu/<br />
|components=Core::HTML: Parser<br />
}}<br />
<br />
{{Module<br />
|name=I18N Library<br />
|description=<br />
|owner=[mailto:jshin1987@gmail.com Jungshik Shin], [mailto:smontagu@smontagu.org Simon Montagu]<br />
|peers=[mailto:VYV03354@nifty.ne.jp Masatoshi Kimura]<br />
|group=dev-i18n<br />
|source_dirs=intl/<br />
|url=http://mozilla.org/projects/intl/index.html<br />
|components=Core::Internationalization<br />
}}<br />
<br />
{{Module<br />
|name=ImageLib<br />
|description=<br />
|owner=[mailto:joe@drew.ca Joe Drew]<br />
|peers=[mailto:netzen@gmail.com Brian Bondy], [mailto:jmuizelaar@mozilla.com Jeff Muizelaar], [mailto:jlebar@mozilla.com Justin Lebar], [mailto:seth@mozilla.com Seth Fowler]<br />
|group=dev-platform<br />
|source_dirs=media/libjpeg/, media/libpng/, image/, modules/zlib/<br />
|url=<br />
|components=Core::ImageLib<br />
}}<br />
<br />
{{Module<br />
|name=IPC<br />
|description=Message-passing between threads and processes<br />
|owner=[mailto:cjones@mozilla.com Chris Jones]<br />
|peers=[mailto:danderson@mozilla.com David Anderson], [mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:bent.mozilla@gmail.com Ben Turner]<br />
|group=dev-platform<br />
|source_dirs=ipc/glue/, ipc/ipdl/, ipc/chromium/<br />
|url=<br />
|components=Core::IPC}}<br />
<br />
{{Module<br />
|name=Java APIs for DOM<br />
|description=APIs for Java access to the Document Object Model<br />
|owner=[mailto:ashuk@eng.sun.com Ashutosh Kulkarni]<br />
|peers=<br />
|group=dev-tech-dom,dev-tech-java<br />
|source_dirs=java/dom/<br />
|url=http://www.mozilla.org/projects/blackwood/dom/<br />
|components=Core::Java APIs for DOM<br />
}}<br />
<br />
{{Module<br />
|name=Java APIs to WebShell<br />
|description=<br />
|owner=[mailto:edburns@acm.org Ed Burns]<br />
|peers=[mailto:ashuk@eng.sun.com Ashutosh Kulkarni]<br />
|group=dev-tech-java,dev-embedding<br />
|source_dirs=java/webclient/<br />
|url=http://www.mozilla.org/projects/blackwood/webclient/<br />
|components=Core::Java APIs to WebShell<br />
}}<br />
<br />
{{Module<br />
|name=Java Stubs<br />
|description=OJI<br />
|owner=[mailto:alfred.peng@sun.com Alfred Peng]<br />
|peers=[mailto:Xiaobin.Lu@eng.Sun.com Xiaobin Lu]<br />
|group=dev-tech-java<br />
|source_dirs=modules/oji/, nav-java/, sun-java/<br />
|url=http://www.mozilla.org/oji/<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Java to XPCOM Bridge<br />
|description=<br />
|owner=[mailto:pedemont@us.ibm.com Javier Pedemont]<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg]<br />
|group=dev-tech-xpcom,dev-tech-java<br />
|source_dirs=extensions/java<br />
|url=http://www.mozilla.org/projects/blackwood/connect/<br />
|components=Core::Java to XPCOM Bridge<br />
}}<br />
<br />
{{Module<br />
|name=Java Utility Classes<br />
|description=assert, debug, utilities, etc.<br />
|owner=[mailto:edburns@acm.org Ed Burns]<br />
|peers=[mailto:ashuk@eng.sun.com Ashutosh Kulkarni]<br />
|group=dev-tech-java<br />
|source_dirs=java/util/<br />
|url=http://www.mozilla.org/projects/blackwood/java-util/<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Java-Implemented Plugins<br />
|description=Infrastructure for writing MIME content-handlers<br />
in Java.<br />
|owner=[mailto:idk@eng.sun.com Igor Kushnirskiy]<br />
|peers=<br />
|group=dev-tech-java<br />
|source_dirs=java/plugins/<br />
|url=http://www.mozilla.org/projects/blackwood/java-plugins/<br />
|components=Core::Java-Implemented Plugins<br />
}}<br />
<br />
{{Module<br />
|name=JavaScript<br />
|description=JavaScript engine (SpiderMonkey)<br />
|owner=[mailto:jorendorff@mozilla.com Jason Orendorff]<br />
|peers=[mailto:danderson@mozilla.com David Anderson], [mailto:igor@mir2.org Igor Bukanov], [mailto:brendan@mozilla.org Brendan Eich], [mailto:gal@mozilla.com Andreas Gal], [mailto:wmccloskey@mozilla.com Bill McCloskey], [mailto:nnethercote@mozilla.com Nick Nethercote], [mailto:luke@mozilla.com Luke Wagner], [mailto:jwalden@mit.edu Jeff Walden], [mailto:ejpbruel@mozilla.com Eddy Bruel], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:jdemooij@mozilla.com Jan de Mooij], [mailto:hv1989@gmail.com Hannes Verschore], [mailto:kvijayan@mozilla.com Kannan Vijayan], [mailto:nmatsakis@mozilla.com Niko Matsakis], [mailto:shu@mozilla.com Shu-yu Guo], [mailto:evilpies@gmail.com Tom Schuster], [mailto:bhackett1024@gmail.com Brian Hackett], [mailto:bobbyholley@gmail.com Bobby Holley], [mailto:till@tillschneidereit.net Till Schneidereit]<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/src<br />
|url=http://www.mozilla.org/js/spidermonkey,<br />
http://developer.mozilla.org/en/docs/About_JavaScript<br />
|components=Core::JavaScript Engine<br />
}}<br />
<br />
{{Module<br />
|name=JavaScript JIT<br />
|description=JavaScript engine's JIT compilers (IonMonkey, Baseline)<br />
|owner=[mailto:jdemooij@mozilla.com Jan de Mooij]<br />
|peers=[mailto:danderson@mozilla.com David Anderson], [mailto:shu@mozilla.com Shu-yu Guo], [mailto:bhackett1024@gmail.com Brian Hackett], [mailto:nicolas.b.pierron@mozilla.com Nicolas Pierron], [mailto:mrosenberg@mozilla.com Marty Rosenberg], [mailto:evilpies@gmail.com Tom Schuster], [mailto:sstangl@mozilla.com Sean Stangl], [mailto:hv1989@gmail.com Hannes Verschore], [mailto:kvijayan@mozilla.com Kannan Vijayan], [mailto:luke@mozilla.com Luke Wagner]<br />
|group=dev-tech-js-engine-internals<br />
|source_dirs=js/src/jit<br />
|url=http://www.mozilla.org/js/spidermonkey<br />
|components=Core::JavaScript Engine: JIT<br />
}}<br />
<br />
{{Module<br />
|name=JavaScript Debugger Backend<br />
|description=JavaScript debugging hooks<br />
|owner=[mailto:timeless@mozdev.org Josh 'timeless' Soref]<br />
|peers=[mailto:brendan@mozilla.org Brendan Eich], [mailto:rginda@hacksrus.com Rob Ginda]<br />
|group=dev-apps-js-debugger<br />
|source_dirs=js/jsd/<br />
|url=http://www.mozilla.org/js/jsd<br />
|components=Other Applications::Venkman JS Debugger<br />
}}<br />
<br />
{{Module<br />
|name=js-ctypes<br />
|description=A foreign function interface which allows privileged JS code to interact with binary code without using XPCOM/XPConnect.<br />
|owner=[mailto:jorendorff@mozilla.com Jason Orendorff]<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:bobbyholley@gmail.com Bobby Holley]<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/src/ctypes/<br />
|url=https://wiki.mozilla.org/JSctypes<br />
|components=Core::js-ctypes<br />
}}<br />
<br />
{{Module<br />
|name=js-tests<br />
|description=JavaScript test suite<br />
|owner=[mailto:bclary@bclary.com Bob Clary]<br />
|peers=<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/tests/<br />
|url=http://www.mozilla.org/js/tests/library.html<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Layout Engine<br />
|description=rendering tree construction, layout (reflow), painting, etc.<br />
|owner=[mailto:roc+@cs.cmu.edu Robert O'Callahan]<br />
|peers=[mailto:bmlk@gmx.de Bernd Mielke], [mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:dbaron@dbaron.org David Baron], [mailto:smontagu@smontagu.org Simon Montagu]<br />
|group=dev-tech-layout<br />
|source_dirs=layout/%, layout/base/, layout/build/, layout/doc/, layout/forms/, layout/generic/, layout/html/, layout/macbuild/, layout/printing/, layout/tables/, layout/tools/<br />
|url=http://mozilla.org/newlayout/doc/ ,<br />
http://lxr.mozilla.org/mozilla/source/layout/doc/<br />
|components=Core::Layout, Core::Layout: Block and Inline, Core::Layout: Floats, Core::Layout: Form Controls, Core::Layout: HTML Frames, Core::Layout: Images, Core::Layout: Misc Code, Core::Layout: R & A Pos, Core::Layout: Tables, Core::Layout: Text, Core::Layout: View Rendering<br />
}}<br />
<br />
{{Module<br />
|name=libjar<br />
|description=The JAR handling code (protocol handler, stream implementation, and zipreader/zipwriter).<br />
|owner=[mailto:tglek@mozilla.com Taras Glek]<br />
|peers=[mailto:mwu@mozilla.com Michael Wu]<br />
|group=dev-platform<br />
|source_dirs=modules/libjar<br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=MathML<br />
|description=MathML is a low-level specification for describing mathematics which provides a foundation for the inclusion of mathematical expressions in Web pages.<br />
|owner=[mailto:karlt+@karlt.net Karl Tomlinson]<br />
|peers=[mailto:roc+@cs.cmu.edu Robert O'Callahan]<br />
|group=dev-tech-mathml<br />
|source_dirs=layout/mathml/<br />
|url=http://www.mozilla.org/projects/mathml/<br />
|components=Core::MathML<br />
}}<br />
<br />
{{Module<br />
|name=mfbt<br />
|description=mfbt is a collection of headers, macros, data structures, methods, and other functionality available for use and reuse throughout all Mozilla code (including SpiderMonkey and Gecko more broadly).<br />
|owner=[mailto:jwalden@mit.edu Jeff Walden]<br />
|peers=<br />
|group=dev-platform<br />
|source_dirs=mfbt/<br />
|url=<br />
|components=Core::MFBT<br />
}}<br />
<br />
{{Module<br />
|name=mozilla-toplevel<br />
|description=The top level directory for the mozilla tree.<br />
|owner=[mailto:brendan@mozilla.org Brendan Eich]<br />
|peers=<br />
|group=<br />
|source_dirs=tools/README<br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Necko<br />
|description=The Mozilla Networking Library<br />
|owner=[mailto:pmcmanus@mozilla.com Patrick McManus]<br />
|peers=[mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:jduell.mcbugs@gmail.com Jason Duell], [mailto:honzab.moz@firemni.cz Honza Bambas], [mailto:brian@briansmith.org Brian Smith], [mailto:mnovotny@mozilla.com Michal Novotny], [mailto:hurley@mozilla.com Nick Hurley], [mailto:sworkman@mozilla.com Steve Workman]<br />
|group=dev-tech-network<br />
|source_dirs=netwerk/%, netwerk/base/, netwerk/build/, netwerk/cache/, netwerk/dns/, netwerk/locales/, netwerk/mime/, netwerk/protocol/, netwerk/resources/, netwerk/socket/, netwerk/streamconv/, netwerk/system/, netwerk/test/, netwerk/testserver/<br />
|url=http://www.mozilla.org/projects/netlib/, https://developer.mozilla.org/en/Necko<br />
|components=Core::Networking, Core::Networking: Cache, Core::Networking: Cookies, Core::Networking: FTP, Core::Networking: File, Core::Networking: HTTP, Core::Networking: JAR, Core::Networking: Websockets<br />
}}<br />
<br />
{{Module<br />
|name=NSPR<br />
|description=Netscape Portable Runtime<br />
|owner=[mailto:nelson@bolyard.com Nelson Bolyard], [mailto:wtc@google.com Wan-Teh Chang]<br />
|peers=[mailto:ted.mielczarek@gmail.com Ted Mielczarek]<br />
|group=dev-tech-nspr<br />
|source_dirs=nsprpub/<br />
|url=http://www.mozilla.org/projects/nspr/<br />
http://www.mozilla.org/projects/nspr/reference/html/<br />
http://www.mozilla.org/projects/nspr/release-notes/<br />
|components=NSPR<br />
}}<br />
<br />
{{Module<br />
|name=PDF<br />
|description=Rendering code to display documents encoded in the ISO 32000-1 `PDF' format.<br />
|owner=[mailto:cjones@mozilla.com Chris Jones], [mailto:gal@mozilla.com Andreas Gal]<br />
|peers=[mailto:aadib@mozilla.com Artur Adib], [mailto:bdahl@mozilla.com Brendan Dahl], [mailto:vnicolas@mozilla.com Vivien Nicolas]<br />
|group=dev-platform<br />
|source_dirs=media/pdf/<br />
|url=https://github.com/mozilla/pdf.js<br />
|components=Core::PDF<br />
}}<br />
<br />
{{Module<br />
|name=Plugins<br />
|description= NPAPI Plugin support.<br />
|owner=[mailto:joshmoz@gmail.com Josh Aas]<br />
|peers=[mailto:jst@mozilla.org Johnny Stenback], [mailto:roc+@cs.cmu.edu Robert O'Callahan], [mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:jmathies@mozilla.com Jim Mathies], [mailto:jschoenick@mozilla.com John Schoenick]<br />
|group=<br />
|source_dirs=dom/plugins/, modules/plugin/<br />
|url=https://wiki.mozilla.org/Plugins<br />
|components=Core::Java-Implemented Plugins, Core::Plug-ins<br />
}}<br />
<br />
{{Module<br />
|name=Preferences<br />
|description=Preference library<br />
|owner=[mailto:dwitte@mozilla.com Dan Witte]<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg]<br />
|group=dev-platform<br />
|source_dirs=modules/libpref/<br />
|url=<br />
|components=Core::Preferences: Backend<br />
}}<br />
<br />
{{Module<br />
|name=Privilege Manager<br />
|description="caps"<br />
|owner=[mailto:bobbyholley@gmail.com Bobby Holley]<br />
|peers=[mailto:brendan@mozilla.org Brendan Eich], [mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:dveditz@cruzio.com Dan Veditz], [mailto:jst@mozilla.org Johnny Stenback]<br />
|group=dev-tech-dom<br />
|source_dirs=caps/<br />
|url=http://www.mozilla.org/projects/security/components/index.html<br />
|components=Core::Security: CAPS<br />
}}<br />
<br />
{{Module<br />
|name=Push Notifications<br />
|description=Push is a way for application developers to send messages to their web applications.<br />
|owner=[mailto:doug.turner@gmail.com Doug Turner]<br />
|peers=[mailto:nsm.nikhil@gmail.com Nikhil Marathe], [mailto:justin.lebar@gmail.com Justin Lebar]<br />
|group=<br />
|source_dirs=dom/push<br />
|url=https://wiki.mozilla.org/WebAPI/SimplePush<br />
|components=<br />
}}<br />
<br />
<br />
{{Module<br />
|name=PyXPCOM<br />
|description=The Python to XPCOM bridge.<br />
|owner=[mailto:toddw@activestate.com Todd Whiteman]<br />
|peers=[mailto:mhammond@skippinet.com.au Mark Hammond]<br />
|group=<br />
|source_dirs=extension/python<br />
|url=https://developer.mozilla.org/en/PyXPCOM<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Qt-based gfx and widget<br />
|description=Qt-based rendering and widget code<br />
|owner=[mailto:romaxa@gmail.com Oleg Romashin]<br />
|peers=[mailto:mozilla@rosenauer.org Wolfgang Rosenauer], [mailto:doug.turner@gmail.com Doug Turner]<br />
|group=dev-tech-widget<br />
|source_dirs=widget/qt/<br />
|url=<br />
|components=Core::Widget: Qt<br />
}}<br />
<br />
{{Module<br />
|name=RDF<br />
|description=<br />
|owner=[mailto:axel@pike.org Axel Hecht]<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg]<br />
|group=dev-tech-rdf<br />
|source_dirs=rdf/<br />
|url=http://www.mozilla.org/rdf/doc/<br />
|components=Core::RDF<br />
}}<br />
<br />
{{Module<br />
|name=security<br />
|description=Crypto/PKI code, including NSS (Network Security Services) and JSS (NSS for Java)<br />
|owner=[mailto:rrelyea@redhat.com Bob Relyea], [mailto:wtc@google.com Wan-Teh Chang]<br />
|peers=[mailto:emaldona@redhat.com Elio Maldonado], [mailto:bsmith@mozilla.com Brian Smith], [mailto:kaie@kuix.de Kai Engert], [mailto:ryan.sleevi@gmail.com Ryan Sleevi]<br />
|group=dev-tech-crypto<br />
|source_dirs=dbm/, security/coreconf/, security/dbm/, security/jss/, security/nss/, security/tinderbox/, security/tinderlight/<br />
|url=http://mozilla.org/projects/security/pki/<br />
|components=NSS, JSS, Core::Security, Core::Security: S/MIME<br />
}}<br />
<br />
{{Module<br />
|name=Security - Mozilla PSM Glue<br />
|description=Personal Security Manager<br />
|owner=[mailto:bsmith@mozilla.com Brian Smith]<br />
|peers=[mailto:honzab.moz@firemni.cz Honza Bambas], [mailto:dkeeler@mozilla.com David Keeler], [mailto:wtc@google.com Wan-Teh Chang]<br />
|group=dev-tech-crypto<br />
|source_dirs=security/manager/<br />
|url=<br />
|components=Core::Security: PSM, Core::Security: UI<br />
}}<br />
<br />
{{Module<br />
|name=storage<br />
|description=Storage APIs with a SQLite backend<br />
|owner=[mailto:mak77@bonardo.net Marco Bonardo]<br />
|peers=[mailto:bugmail@asutherland.org Andrew Sutherland], [mailto:bent.mozillla@gmail.com Ben Turner]<br />
|group=dev-platform<br />
|source_dirs=db/sqlite3/, storage/<br />
|url=http://developer.mozilla.org/en/docs/Storage<br />
|components=Toolkit::Storage, Core::SQL<br />
}}<br />
<br />
{{Module<br />
|name=String<br />
|description=<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:jlebar@mozilla.com Justin Lebar]<br />
|group=dev-tech-xpcom<br />
|source_dirs=string/, xpcom/string/<br />
|url=https://developer.mozilla.org/En/Mozilla_internal_string_guide<br />
|components=Core::String<br />
}}<br />
<br />
{{Module<br />
|name=Style System<br />
|description=CSS style sheet handling; style data computation<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky]<br />
|group=dev-tech-layout<br />
|source_dirs=layout/style/<br />
|url=https://wiki.mozilla.org/Gecko:Overview#Style_System<br />
|components=Core::CSS Parsing and Computation<br />
}}<br />
<br />
{{Module<br />
|name=SVG<br />
|description=Scalable Vector Graphics<br />
|owner=[mailto:jwatt@jwatt.org Jonathan Watt]<br />
|peers=[mailto:longsonr@gmail.com Robert Longson], [mailto:roc+@cs.cmu.edu Robert O'Callahan], [mailto:dholbert@mozilla.com Daniel Holbert], [mailto:birtles@gmail.com Brian Birtles]<br />
|group=dev-tech-svg<br />
|source_dirs=content/svg/, layout/svg/, content/smil/<br />
|url=https://developer.mozilla.org/en-US/docs/Web/SVG<br />
|components=Core::SVG<br />
}}<br />
<br />
{{Module<br />
|name=Tamarin<br />
|description=VM for ActionScript and JavaScript<br />
|owner=[mailto:edwsmith@adobe.com Edwin Smith], [mailto:jodyer@adobe.com Jeff Dyer]<br />
|peers=[mailto:brendan@mozilla.org Brendan Eich], [mailto:stejohns@adobe.com Steven Johnson], [mailto:tierney@adobe.com Erik Tierney], [mailto:treilly@adobe.com Tom Reilly]<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/tamarin<br />
|url=http://www.mozilla.org/projects/tamarin/<br />
http://wiki.mozilla.org/tamarin/<br />
http://hg.mozilla.org/tamarin-central/<br />
http://hg.mozilla.org/tamarin-tracing/<br />
|components=Tamarin<br />
}}<br />
<br />
{{Module<br />
|name=Test Harness<br />
|description=In-tree test infrastructure and tools. Harnesses include, XPCShell, Mochitest (& Chrome), Reftest, JsREftest, Compiled Code Tests, Robocop, Mozmill and Marionette. Requests for new harnesses should go to Testing::General.<br />
|owner=[mailto:ted@mozilla.com Ted Mielczarek]<br />
|peers=[mailto:dbaron@dbaron.org David Baron] (reftest), [mailto:jwalden@mit.edu Jeff Walden] (httpd.js, jsreftest), [mailto:rcampbell@mozilla.com Rob Campbell] (mochitest, mochitest chrome, marionette), [mailto:jmaher@mozilla.com Joel Maher] (reftest, mochitest, jsreftest), [mailto:ctalbert@mozilla.com Clint Talbert] (reftest, compiled code, mozmill), [mailto:geoffbrown@mozilla.com Geoff Brown] (robocop), [mailto:hskupin@mozilla.com Henrik Skupin] (mozmill), [mailto:mdas@mozilla.com Malini Das] (marionette), [mailto:jgriffin Jonathan Griffin] (marionette), [mailto:jhammel@mozilla.com Jeffrey Hammel] (mozmill) [mailto:dburns@mozilla.com David Burns] (marionette)<br />
|group=dev-quality<br />
|source_dirs=/testing<br />
|url=http://wiki.mozilla.org/SoftwareTesting<br />
|components=Testing::General, Testing::Mochitest, Testing::Mochitest Chrome, Testing::Marionette, Testing::Mozmill, Testing::Reftest, Testing::XPCShell Harness, Testing::httpd.js<br />
}}<br />
<br />
{{Module<br />
|name=Testing Infrastructure<br />
|description=Testing tools and infrastructure for Mozilla projects, harnesses for automated tests, stand-alone test tools. Talos, Graph Server, Mozbase, Pulse, WOO, Bughunter, SUTAgent, Eideticker<br />
|owner=[mailto:ctalbert@mozilla.com Clint Talbert]<br />
|peers=[mailto:bclary@bclary.com Bob Clary], [mailto:bhearsum@mozilla.com Ben Hearsum], [mailto:ccooper@deadsquid.com Chris Cooper], [mailto:ctalbert@mozilla.com Clint Talbert], [mailto:robert@roberthelmer.com Robert Helmer], [mailto:jmaher@mozilla.com Joel Maher], [mailto:rcampbell@mozilla.com Rob Campbell], [mailto:jhammel@mozilla.com Jeffrey Hammel], [mailto:wlach@mozilla.com William Lachance], [mailto:jeads@mozilla.com Jonathan Eads], [mailto:jgriffin Jonathan Griffin], [mailto:bmoss@mozilla.com Bob Moss], [mailto:mcote@mozilla.com Mark Côté]<br />
|group=dev-quality<br />
|source_dirs=testing/, tools/httptester/, tools/page-loader/, tools/test-harness/, tools/tests/, tools/testserver/, tools/testy/<br />
|url=http://wiki.mozilla.org/SoftwareTesting<br />
|components=Testing::Infrastructure<br />
}}<br />
<br />
{{Module<br />
|name=JS Marionette Harness and Tools<br />
|description=Test harness and associated tools for running marionette tests on NodeJS (submodule of Test Infrastructure)<br />
|owner=[mailto:jlal@mozilla.com James Lal] <lightsofapollo>, [mailto:gaye@mozilla.com Gareth Aye] <gaye><br />
|peers=[mailto:aus@mozilla.com Ghislain "Aus" Lacroix] <auswerk>, [mailto:mike@bocoup.com Mike Pennisi] <jugglinmike>, [mailto:evanxd@mozilla.com Evan Tseng] <evanxd><br />
|source_dirs=These are all mozilla-b2g github repos: [https://github.com/mozilla-b2g/marionette-js-runner Marionette JS Runner], [https://github.com/mozilla-b2g/mocha-json-proxy Mocha JSON Proxy], [https://github.com/mozilla-b2g/mocha-tbpl-reporter Mocha TBPL Reporter], [https://github.com/mozilla-b2g/marionette-js-client Marionette JS Client], [https://github.com/mozilla-b2g/sockit-to-me Sockit To Me], [https://github.com/mozilla-b2g/marionette-apps Marionette Apps], [https://github.com/mozilla-b2g/marionette-js-logger Marionette JS Logger], [https://github.com/mozilla-b2g/marionette-b2gdesktop-host Marionette B2G Desktop Host], [https://github.com/mozilla-b2g/marionette-firefox-host Marionette Firefox Host], [https://github.com/mozilla-b2g/marionette-profile-builder Marionette Profile Builder], [https://github.com/mozilla-b2g/mozilla-profile-builder Mozilla Profile Builder]<br />
|components=Testing::JSMarionette<br />
|group=dev-gaia<br />
}}<br />
<br />
{{Module<br />
|name=XPCShell Test Harness<br />
|description=The XPCShell Harness<br />
|owner=[mailto:ted.mielczarek@gmail.com Ted Mielczarek]<br />
|peers=[mailto:jmaher@mozilla.com Joel Maher]<br />
|source_dirs=testing/xpcshell<br />
|components=Testing::XPCShell Harness<br />
}}<br />
<br />
{{Module<br />
|name=Update Service<br />
|description=server code for Mozilla Update services (aus, addons, pfs)<br />
|owner=[mailto:morgamic@mozilla.com Mike Morgan]<br />
|peers=[mailto:jscott@mozilla.com Justin Scott], [mailto:shaver@mozilla.org Mike Shaver], [mailto:wclouser@mozilla.com Will Clouser]<br />
|group=dev-amo<br />
|source_dirs=webtools/addons/, webtools/aus/, webtools/update/<br />
|url=http://wiki.mozilla.org/wiki/AMO<br />
|components=AUS::Administration, AUS::Systems<br />
}}<br />
<br />
{{Module<br />
|name=View System<br />
|description=The View Manager is responsible for handling "heavyweight" rendering (some clipping, compositing) and event handling tasks.<br />
|owner=[mailto:roc+@cs.cmu.edu Robert O'Callahan]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:dbaron@dbaron.org David Baron]<br />
|group=dev-tech-layout<br />
|source_dirs=view/<br />
|url=<br />
|components=Core::Layout: View Rendering<br />
}}<br />
<br />
{{Module<br />
|name=Web Audio<br />
|description=Support for the W3C Web Audio API specification.<br />
|owner=[mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|peers=[mailto:roc+@cs.cmu.edu Robert O'Callahan], [mailto:padenot@mozilla.com Paul Adenot]<br />
|group=dev-platform<br />
|source_dirs=content/media/webaudio<br />
|url=https://wiki.mozilla.org/Web_Audio_API<br />
|components=Core::Web Audio<br />
}}<br />
<br />
{{Module<br />
|name=WebRTC<br />
|description=WebRTC is responsible for realtime audio and video communication, as well as related issues like low-level camera and microphone access (on desktop at least)<br />
|owner=[mailto:rjesup@mozilla.com Randell Jesup]<br />
|peers=[mailto:roc+@cs.cmu.edu Robert O'Callahan], [mailto:tterriberry@mozilla.com Tim Terriberry], [mailto:anant@mozilla.com Anant Narayanan]<br />
|group=dev-media<br />
|source_dirs=media/webrtc<br />
|url=https://wiki.mozilla.org/Media/webrtc<br />
|components=Core::WebRTC, Core::WebRTC (Audio/Video), Core::WebRTC (Networking), Core::WebRTC (Signaling)<br />
}}<br />
<br />
{{Module<br />
|name=Widget<br />
|description=<br />
|owner=[mailto:roc+@cs.cmu.edu Robert O'Callahan]<br />
|peers=[mailto:pavlov@pavlov.net Stuart Parmenter], [mailto:vladimir@pobox.com Vladimir Vukicevic]<br />
|group=dev-platform<br />
|source_dirs=widget/%, widget/public/, widget/%, widget/xpwidgets/<br />
|url=<br />
|components=Core::Drag and Drop, Core::Widget<br />
}}<br />
<br />
{{Module<br />
|name=Widget - Android<br />
|description=The Android Port<br />
|owner=[mailto:blassey.bugs@lassey.us Brad Lassey]<br />
|peers=[mailto:vladimir@mozilla.com Vladimir Vukicevic], [mailto:dougt@dougt.org Doug Turner], [mailto:mwu@mozilla.com Michael Wu]<br />
|group=dev-platform<br />
|source_dirs=widget/android/, embedding/android<br />
|url=<br />
|components=Core::Widget: Android<br />
}}<br />
<br />
{{Module<br />
|name=Widget - GTK<br />
|description=supported X widgetry and gfx<br />
|owner=[mailto:roc+@cs.cmu.edu Robert O'Callahan]<br />
|peers=[mailto:karlt+@karlt.net Karl Tomlinson]<br />
|group=dev-platform<br />
|source_dirs=widget/gtk/, widget/gtk2/, widget/gtksuperwin/, widget/gtkxtbin/<br />
|url=http://www.mozilla.org/unix/, http://www.gtk.org, http://www.mozilla.org/ports/gtk/<br />
|components=Core::Widget: Gtk<br />
}}<br />
<br />
{{Module<br />
|name=Widget - Mac OS X<br />
|description= Gecko's Mac OS X compatibility layer.<br />
|owner=[mailto:joshmoz@gmail.com Josh Aas]<br />
|peers=[mailto:mstange@themasta.com Markus Stange], [mailto:smichaud@pobox.com Steven Michaud], [mailto:bgirard@mozilla.com Benoit Girard], [mailto:spohl@mozilla.com Stephen Pohl]<br />
|group=dev-platform<br />
|source_dirs=widget/cocoa/<br />
|url=<br />
|components=Core::Widget: Cocoa<br />
}}<br />
<br />
{{Module<br />
|name=Widget - Windows<br />
|description=Windows widgets and desktop integration<br />
|owner=[mailto:jmathies@mozilla.com Jim Mathies]<br />
|peers=[mailto:blassey@mozilla.com Brad Lassey], [mailto:netzen@gmail.com Brian Bondy], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:dougt@meer.net Doug Turner], [mailto:neil@parkwaycc.co.uk Neil Rashbrook], [mailto:robarnold@cmu.edu Rob Arnold], [mailto:timeless@mozdev.org Josh 'timeless' Soref], [mailto:vladimir@pobox.com Vladimir Vukicevic]<br />
|group=dev-platform<br />
|source_dirs=widget/windows/<br />
|url=<br />
|components=Core::Widget: Win32<br />
}}<br />
<br />
{{Module<br />
|name=XBL<br />
|description=eXtensible Binding Language<br />
|owner=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:jonas@sicking.cc Jonas Sicking]<br />
|peers=[mailto:mrbkap@gmail.com Blake Kaplan]<br />
|group=dev-tech-xbl<br />
|source_dirs=content/xbl/%, content/xbl/public/, content/xbl/src/<br />
|url=http://www.mozilla.org/projects/xbl/<br />
|components=Core::XBL<br />
}}<br />
<br />
{{Module<br />
|name=XML<br />
|description=XML in Mozilla, including XML, XHTML, Namespaces in XML, Associating Style Sheets with XML Documents, XML Linking and XML Extras. XML-related things that are not covered by more specific projects.<br />
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:jonas@sicking.cc Jonas Sicking], [mailto:jst@mozilla.org Johnny Stenback]<br />
|group=dev-tech-xml<br />
|source_dirs=content/xml/, extensions/xmlextras/, parser/expat/<br />
|url=http://www.mozilla.org/newlayout/xml/<br />
|components=Core::XML<br />
}}<br />
<br />
{{Module<br />
|name=XPApps<br />
|description=Cross-Platform Applications, mostly Navigator front end and application shell.<br />
|owner=[mailto:neil@parkwaycc.co.uk Neil Rashbrook]<br />
|peers=[mailto:dean_tessman@hotmail.com Dean Tessman], [mailto:jag@tty.nl Peter Annema], [mailto:timeless@mozdev.org Josh 'timeless' Soref]<br />
|group=dev-apps-seamonkey<br />
|source_dirs=xpfe/<br />
|url=http://www.mozilla.org/xpapps/<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=XPCOM<br />
|description=The cross-platform object model and core data structures.<br />
|owner=[mailto:benjamin@smedbergs.us Benjamin Smedberg]<br />
|peers=[mailto:dougt@meer.net Doug Turner], [mailto:froydnj@mozilla.com Nathan Froyd]<br />
|group=dev-platform<br />
|source_dirs=startupcache/, xpcom/%, xpcom/base/, xpcom/build/, xpcom/components/, xpcom/ds/, xpcom/glue/, xpcom/proxy/, xpcom/sample/, xpcom/stub/, xpcom/tests/, xpcom/threads/, xpcom/tools/, xpcom/windbgdlg/<br />
|url=http://developer.mozilla.org/en/XPCOM<br />
|components=Core::XPCOM<br />
}}<br />
<br />
{{Module<br />
|name=XPConnect<br />
|description=Deep Magic<br />
|owner=[mailto:bobbyholley@gmail.com Bobby Holley]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:gal@uci.edu Andreas Gal], [mailto:jst@mozilla.org Johnny Stenback], [mailto:peterv@propagandism.org Peter Van der Beken], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:gkrizsanits@mozilla.com Gabor Krizsanits]<br />
|group=<br />
|source_dirs=js/xpconnect/<br />
|url=<br />
|components=Core::XPConnect<br />
}}<br />
<br />
{{Module<br />
|name=XPIDL<br />
|description=Cross-platform IDL compiler; produces .h C++ header files and .xpt runtime type description files from .idl interface description files. Also produces .java interface files, as part of an experimental java<->xpcom connection layer.<br />
|owner=[mailto:BradleyJunk@cinci.rr.com BradleyJunk@cinci.rr.com]<br />
|peers=[mailto:jband@netscape.com(disabled) jband@netscape.com(disabled)], [mailto:shaver@mozilla.org Mike Shaver], [mailto:timeless@mozdev.org Josh 'timeless' Soref]<br />
|group=dev-tech-xpcom<br />
|source_dirs=xpcom/typelib/<br />
|url=http://www.mozilla.org/scriptable/xpidl<br />
http://www.mozilla.org/scriptable<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=XPInstall<br />
|description=<br />
|owner=[mailto:dveditz@cruzio.com Dan Veditz]<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg]<br />
|group=dev-tech-xpinstall<br />
|source_dirs=xpinstall/<br />
|url=<br />
|components=Core::Installer: XPInstall Engine<br />
}}<br />
<br />
{{Module<br />
|name=xptcall<br />
|description=XPTCall - platform-specific assembly for calling and implementing arbitrary XPCOM interfaces.<br />
|owner=[mailto:timeless@mozdev.org Josh 'timeless' Soref]<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:shaver@mozilla.org Mike Shaver]<br />
|group=dev-xpcom<br />
|source_dirs=xpcom/reflect/xptcall/<br />
|url=http://www.mozilla.org/scriptable/xptcall-faq.html<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=XPToolkit<br />
|description=Cross-platform user interface toolkit<br />
|owner=<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:hyatt@mozilla.org Dave Hyatt], [mailto:jag@tty.nl Peter Annema], [mailto:Jan.Varga@gmail.com Jan Varga]<br />
|group=dev-tech-xul<br />
|source_dirs=content/xul/, layout/xul/<br />
|url=http://www.mozilla.org/xpfe/<br />
|components=Core::XP Toolkit/Widgets: Menus, Core::XP Toolkit/Widgets: XUL<br />
}}<br />
<br />
{{Module<br />
|name=XSLT Processor<br />
|description=XSLT transformations processor<br />
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]<br />
|peers=[mailto:axel@pike.org Axel Hecht], [mailto:jonas@sicking.cc Jonas Sicking]<br />
|group=dev-tech-xslt<br />
|source_dirs=content/xslt/<br />
|url=http://www.mozilla.org/projects/xslt/, http://www.w3.org/TR/xslt.html<br />
|components=Core::XSLT<br />
}}<br />
<br />
{{Module<br />
|name=XTF<br />
|description=eXtensible Tag Framework<br />
|owner=<br />
|peers=[mailto:alex@croczilla.com alex@croczilla.com], [mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:jonas@sicking.cc Jonas Sicking]<br />
|group=dev-tech-xbl<br />
|source_dirs=content/xtf/, layout/xtf/<br />
|url=http://www.croczilla.com/bits_and_pieces/xtf/<br />
|components=Core::XTF<br />
}}<br />
<br />
===Submodules===<br />
{{Module<br />
|name=Build Config - moz.build Data Migration<br />
|description=Temporary submodule that covers just the data conversion aspects of the transition from Makefile.in to moz.build files. This does not cover establishing new symbols in the moz.build execution sandbox. This module will cease to exist once the moz.build migration is complete.<br />
|owner=[mailto:gps@mozilla.com Gregory Szorc]<br />
|peers=Same as Build Config plus [mailto:jarmstrong@mozilla.com Joey Armstrong].<br />
|group=dev-builds<br />
|components=Core::Build Config<br />
}}<br />
{{Module<br />
|name=Build Config - Fennec<br />
|description=Submodule of the build config covering Fennec's build system in mobile/android.<br />
|owner=[mailto:gps@mozilla.com Gregory Szorc]<br />
|peers=Same as Build Config plus [mailto:nalexander@mozilla.com Nicholas Alexander].<br />
|group=dev-builds<br />
|components=Core::Build Config<br />
}}<br />
<br />
<noinclude><br />
<br />
===Unassigned Bugzilla Components===<br />
<br />
The following Bugzilla components in the Core project have not been assigned to a module (this list is not exhaustive):<br />
<br />
<pre><br />
Core::Event Handling<br />
Core::File Handling<br />
Core::Find Backend<br />
Core::Gecko Profiler<br />
Core::General<br />
Core::HTML: Form Submission<br />
Core::History: Global<br />
Core::Identity<br />
Core::Image Blocking<br />
Core::JavaScript Debugging APIs<br />
Core::Localization<br />
Core::Nanojit<br />
Core::Networking: Domain Lists<br />
Core::Print Preview<br />
Core::Printing: Output<br />
Core::Printing: Setup<br />
Core::Profile: BackEnd<br />
Core::Profile: Migration<br />
Core::Profile: Roaming<br />
Core::QuickLaunch (AKA turbo mode)<br />
Core::Rewriting and Analysis<br />
Core::Selection<br />
Core::Serializers<br />
Core::Spelling checker<br />
Core::Tracking<br />
Core::Video/Audio<br />
Core::Web Services<br />
Core::WebDAV<br />
Core::Widget: OS/2<br />
Core::Widget: Photon<br />
Core::X-remote<br />
Core::XForms<br />
Core::XUL<br />
Core::jemalloc<br />
</pre><br />
</noinclude></div>Sickinghttps://wiki.mozilla.org/index.php?title=B2G/Triage&diff=741537B2G/Triage2013-10-29T22:53:01Z<p>Sicking: /* Triage for 1.2.0 (Koi) */</p>
<hr />
<div>This page is a rollup of all the bug queries floating across the B2G project. This will include Gonk, Gaia, Gecko, and Marketplace. <br />
<br />
== Release Triage ==<br />
* Dial-in and Vidyo connection details for all triage sessions are the same as all Firefox OS general meetings: https://wiki.mozilla.org/B2G#Meetings<br />
<br />
=== Issues that Should Block ===<br />
* Features our product team has committed us to<br />
* Major issue in new feature - especially those in which a large number of users will be impacted, or a smaller number of users will be significantly impacted<br />
* Major identifiable regressions (perf or otherwise)<br />
* Non-localizable strings<br />
* Top Crashes<br />
* sec-high, sec-critical security bugs<br />
* Smoke-test regression<br />
* Data loss<br />
* Issues that block partner certification (bluetooth, wifi, legal, etc.)<br />
* Issues getting a lot of support calls with partners or on SUMO<br />
* Issues critical around updates (especially if there's been a repro)<br />
* Anything critical around the first time experience<br />
* Major Dialer, SMS, and VM communication issues<br />
* Issues that prevent automated tests in established testsuites (visible test suites on b2g integration branches on TBPL) from running green at least 90% of the time.<br />
* Certification waivers from the previous release (new policy)<br />
* Major issue with an embedded 3rd party app (in case it can't be solved, it could be decided to remove the app) <br />
<br />
=== Issues that Should Not Block===<br />
Any exceptions to these rules must be discussed on b2g-release-drivers@mozilla.org or with Release Management:<br />
* Enhancements<br />
* New Features<br />
* New perf requirements (see enhancements)<br />
* Non-critical string changes (due to l10n)<br />
* Polish and other minor issues<br />
* Unfinished localization (except in the last ~3 weeks of the release)<br />
* Issues requiring the user to perform extremely uncommon use cases<br />
* Issues in languages not being shipped in the version of B2G<br />
* Bugs without clear STR or that are not reproducible<br />
* Bugs that do not impact production phones or the simulator<br />
<br />
=== Blocker Nomination Notes ===<br />
Here are some other pointers to keep in mind:<br />
* Please do not file a bug without having first determined whether or not it's a regression. If you find it is a regression, please add the keyword and help identify a regression window<br />
* Please ensure that anybody who is nominating critical issues is aware of the above criteria<br />
* Please include a description of why an issue is critical for you when nominating (tell us if it's a certification blocker)<br />
* Do not file multiple issues in a single bug<br />
* Please make sure that whoever nominates a bug for blocking is available to promptly answer questions. Even better, please make sure to use one Bugzilla account per individual nominating.<br />
<br />
=== Blocker Whiteboard Additions ===<br />
As of the week of 4/15/13, we will now use:<br />
<br />
* '''[POVB]''' in the whiteboard to denote "part of vendor build" (OEM-specific)<br />
** Denotes that this bug is the responsibility of the OEM<br />
** Used in conjunction with an impacted device in the whiteboard, for instance [buri], [ikura], or [COM_RIL] (for partner RIL issues)<br />
* '''[NPOTB]''' in the whiteboard to denote "not part of the build" <br />
** Used for bugs that involve server infrastructure, build scripts, tests, etc.<br />
*'''[Apps Watch List]''' is the whiteboard used for any bug that impacts apps sourced from Marketplace, the Review process, or bugs used to generate grid builds. The resolution of these bugs have been determined to be outside the sphere of control of the 3rd party developer who is responsible for submissions to the Marketplace. App Review Team, Partner Engineering and Content Program Management use the flag to track bugs that impact their arena.<br />
*'''[Apps Watch List1]''' is used for bugs related to pre-installed apps that are the responsibility of a 3rd party developer to resolve. The Apps Review team uses this tag to trigger communications to the 3rd party developers who contribute apps to Marketplace.<br />
<br />
===Triage for 1.2.0 (Koi)===<br />
'''Schedule'''<br />
* Tues/Weds/Thurs at 08:30 PST / 16:30 CET / 23:30 CST (US + EU)<br />
* Tues at 21:00 PST / 05:00 CET / 12:00 CST (US + TW)<br />
<br />
'''Queries'''<br />
* [https://bugzilla.mozilla.org/buglist.cgi?j_top=OR&f1=cf_blocking_b2g&list_id=8383112&o1=equals&query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&v1=koi%3F koi?]<br />
* [http://mzl.la/16H9k2v koi+]<br />
* [http://mzl.la/Hr85ZT Unfixed koi+]<br />
* [https://bugzilla.mozilla.org/buglist.cgi?f1=cf_blocking_b2g&j_top=OR&keywords=smoketest%2C%20&keywords_type=anywords&o1=anywordssubstr&query_format=advanced&v1=koi&columnlist=product%2Ccomponent%2Cassigned_to%2Cbug_status%2Cresolution%2Cshort_desc%2Cchangeddate%2Ckeywords%2Ccf_blocking_b2g&list_id=8119940 Smoke test bugs]<br />
* [https://bugzilla.mozilla.org/buglist.cgi?j_top=OR&keywords=crash%2C%20crashreportid%2C%20&keywords_type=anywords&f1=cf_blocking_b2g&columnlist=product%2Ccomponent%2Cassigned_to%2Cbug_status%2Cresolution%2Cshort_desc%2Cchangeddate%2Ckeywords%2Ccf_blocking_b2g&o1=anywordssubstr&query_format=advanced&v1=koi&list_id=8119942 Crash bugs]<br />
* [https://bugzilla.mozilla.org/buglist.cgi?j_top=OR&emailtype3=substring&f1=cf_blocking_b2g&emailtype2=substring&email3=nobody%40mozilla.org&emailassigned_to3=1&o1=equals&emailtype1=exact&emailassigned_to1=1&query_format=advanced&email2=nobody%40mozilla.org&emailassigned_to2=1&email1=nobody%40mozilla.org&v1=koi%3F&list_id=8119944 Unassigned koi? bugs]<br />
* [https://bugzilla.mozilla.org/buglist.cgi?o5=nowordssubstr&f1=OP&list_id=8119982&f0=OP&f8=owner_idle_time&o2=equals&f4=OP&v5=fixed%20verified%20unaffected%20wontfix&query_format=advanced&j1=OR&f3=CP&f2=cf_blocking_b2g&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&j4=OR&f5=cf_status_b2g_1_2&v8=-3d&f6=CP&v2=koi%2B&f7=CP&o8=greaterthan koi+ blockers last commented since 3 days]<br />
<br />
===Flag Descriptions===<br />
* '''blocking-basecamp''' is no longer in use (https://bugzilla.mozilla.org/show_bug.cgi?id=830433)<br />
* '''blocking-b2g'''<br />
** blocking-b2g:tef? is for nominating CRITICAL bug fixes to be considered for v1.0.0.0 after 1/15/2013<br />
** blocking-b2g:tef+ is for bugs that we've got agreement with partners about needing as part of v1.0.0.0<br />
** blocking-b2g:shira? is for nominating bug fixes to be considered for v1.0.1<br />
** blocking-b2g:shira+ is for bugs required for v1.0.1 to ship<br />
** blocking-b2g:leo? is for nominating bug fixes to be considered for v1.1.0<br />
** blocking-b2g:leo+ is for bugs required for v1.1.0 to ship<br />
* '''tracking-b2g18:+''' means the bug must be fixed on the v1 branch, and tracking-b2g18:? represents a nomination<br />
* '''tracking-b2g18:19+''' means the bug must be fixed on the v1 branch within 6 weeks after v1.0 code ships (to be fixed prior to FF19's release). This flag will be used for security bugs fixed in FF19, for example.<br />
* '''status-b2g18-v1.0.0''' represents the fix status on v1.0.0 branch (gaia v1.0.0 and/or mozilla-b2g18_v_1_0_0)<br />
* '''status-b2g18''' represents the fix status on the v1.* branches (currently v1.0.1 until it branches, we'll add a separate status flag for it)<br />
<br />
=== More v1.x Triage Queries ===<br />
* Joint Triage<br />
** US/EU - M,W,F at 08:00 Pacific (17:00 CET)<br />
<br />
* tracking-b2g18 - v1.x fixes (functional, security, or otherwise)<br />
** [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced;order=Bug%20Number;field0-0-0=cf_tracking_b2g18;type0-0-0=equals;value0-0-0=%3F tracking nominations]<br />
** [https://bugzilla.mozilla.org/buglist.cgi?type0-1-0=nowordssubstr;order=Bug%20Number;field0-1-0=cf_status_b2g18;field0-0-0=cf_tracking_b2g18;query_format=advanced;value0-1-0=fixed%20verified%20unaffected%20wontfix;type0-0-0=equals;order=Bug%20Number;value0-0-0=%2B tracked and unfixed, but not for a specific version]<br />
** [https://bugzilla.mozilla.org/buglist.cgi?type0-1-0=nowordssubstr;order=Bug%20Number;field0-1-0=cf_status_b2g18;field0-0-0=cf_tracking_b2g18;query_format=advanced;value0-1-0=fixed%20verified%20unaffected%20wontfix;type0-0-0=equals;order=Bug%20Number;value0-0-0={{BETA_VERSION}}%2B tracked and unfixed, to be fixed before release of Firefox {{BETA_VERSION}}] - currently only used for for Gecko security bugs<br />
* approvals<br />
** [https://bugzilla.mozilla.org/buglist.cgi?field0-0-0=flagtypes.name;order=Bug%20Number;query_format=advanced;type0-0-0=substring;value0-0-0=approval-mozilla-b2g18%3F approval-b2g18:?]<br />
** [https://bugzilla.mozilla.org/buglist.cgi?list_id=5454927;field0-0-0=flagtypes.name;order=Bug%20Number;type0-0-0=substring;value0-0-0=approval-gaia-v1%3F;query_format=advanced approval-gaia-v1:?]<br />
<br />
== Performance Triage ==<br />
<br />
'''Canceled from March 5<br />
<br />
'''3 times a week meetings'''<br />
* Monday, Wednesday, Friday: 9 am (PST), 18:00 (CET)<br />
<br />
'''Connection Information'''<br />
* Vidyo connection details:<br />
** Room: David Scravaglieri (9807)<br />
** Guest Access (Need Vidyo Desktop and a Browser): http://bit.ly/14oKDCm<br />
** By Phone: +1 800 707 2533, pin 369 - then 99807# <br />
<br />
'''Search'''<br />
* The Bugzilla Searches requests are:<br />
** [FFOS_perf] Nominations: http://bit.ly/Vx4GOJ<br />
** [FFOS_perf] Status: http://bit.ly/12AASUC<br />
<br />
'''Performance'''<br />
* Performance Graphic: https://datazilla.mozilla.org/b2g/<br />
<br />
== QA Triage ==<br />
<br />
See the B2G QA Triage [https://wiki.mozilla.org/B2G/QA/Triage wiki] for information on this.</div>Sickinghttps://wiki.mozilla.org/index.php?title=WebAPI/SpeakerManager&diff=736901WebAPI/SpeakerManager2013-10-25T06:03:26Z<p>Sicking: </p>
<hr />
<div>== Speaker Control API ==<br />
General Use Cases: Allow application can control acoustic sound output through speaker.<br />
<br />
==Proposed API==<br />
[Constructor()]<br />
interface MozSpeakerManager : EventTarget {<br />
/* query the speaker status */<br />
readonly attribute boolean speakerforced;<br />
/* force the device's sound go through speaker */<br />
attribute boolean forcespeaker;<br />
/* this event will be fired when force speaker status change */<br />
attribute EventHandler onspeakerforcedchange;<br />
};<br />
<br />
<br />
==Example:Turn on speaker ==<br />
var sm = new MozSpeakerManager();<br />
// fired anytime when device's speaker status changed<br />
sm.onspeakerforcedchange = function() {<br />
bool enabled = sm.speakerforced;<br />
// Refresh UI<br />
return;<br />
}<br />
if (sm.speakerforced) {<br />
// device's speaker is on<br />
} else {<br />
sm.forcespeaker = true;<br />
}<br />
<br />
== Use cases ==<br />
*Listen to FM Radio and want to output sounds to speaker audio path.<br />
*Dialer can force output sound from earpiece to speaker<br />
<br />
== Behavior ==<br />
*speakerforced reflects phone status. I.e. if the speaker is currently forced on then this always returns true, no matter which app forced the speaker to be on.<br />
*onspeakerforcedchange fires anytime speakerforced changes.<br />
*forcespeaker=true means that this app attempts to force the speaker to be on. This is only honored if the app is currently in the foreground. So if a foreground app calls forcespeaker=true that means that 'speakerforced' in all applications switches to true, and any audio from any application will go to the speaker.<br />
*If a background app calls forcespeaker=true that doesn't change anything. 'speakerforced' remains false everywhere.<br />
*If an app that has called forcespeaker=true, but no audio is currently playing in the app itself, is switched to the background we switch 'speakerforced' to false in all apps.<br />
*If an app that has called forcespeaker=true, and audio is currently playing in the app itself, is switched to the background 'speakerforced' remains true in all apps. If/when the app stops playing audio, 'speakerforced' switches to false in all apps.<br />
*If an app that has called forcespeaker=true is switched from the background to the foreground 'speakerforced' switches to true in all apps. I.e. the app doesn't have to call forcespeaker=true again when it comes into foreground.<br />
<br />
=== Permissions Table===<br />
<br />
{| border="1" class="wikitable"<br />
! Type<br />
! Use Cases<br />
! Authorization Model<br />
! Notes & Other Controls<br />
|- <br />
| Web Content || None || No access<br />
|- <br />
| Installed Web Apps || None || No access<br />
|- <br />
| Privileged Web Apps || None || No access<br />
|- <br />
| Certified Web Apps || General use cases || Implicit<br />
|}</div>Sickinghttps://wiki.mozilla.org/index.php?title=WebAPI/DeviceStorageAPI2&diff=717811WebAPI/DeviceStorageAPI22013-09-30T07:43:52Z<p>Sicking: Blanked the page</p>
<hr />
<div></div>Sickinghttps://wiki.mozilla.org/index.php?title=WebAPI/DataStore&diff=687583WebAPI/DataStore2013-07-30T23:14:09Z<p>Sicking: /* Interface */</p>
<hr />
<div>= Data Store API =<br />
<br />
This is the snapshot of a discussion between Mounir Lamouri, Thinker Lee, Gene Lian, Jonas Sicking and Hsin-Yi Tsai.<br><br />
The work drafting happened on https://etherpad.mozilla.org/whatever-you-want<br />
<br />
== Use Cases ==<br />
<br />
Allow an application to create data that can be shared with multiple other applications.<br><br />
Allow multiple applications supply data to the same data store.<br><br />
Support read-only stores like facebook contacts.<br><br />
Support read/write stores like built-in contacts.<br><br />
Support keeping an application-local cache of a data store. I.e. enable getting notified about changes to a data store so that the local cache can be kept up-to-date.<br><br />
Enforce types of attributes (avoid to break other applications).<br />
<br />
== Why not...? ==<br />
<br />
=== Why not use specific APIs for the use-cases like the existing Contacts and SMS/MMS APIs? ===<br />
<br />
Here's an [https://groups.google.com/d/msg/mozilla.dev.webapi/H2qobP0qzHM/o8PdD1CGvBEJ informative reply from Jonas Sicking on the dev-webapi list], included below:<br />
<br />
The Contacts and MobileMessage APIs are richer in the sense that they<br />
support things like richer querying, like filtering, sorting and<br />
grouping.<br />
<br />
However the Contacts and MobileMessage APIs has the severe shortcoming<br />
is that you are forced to live with the limitations of what querying<br />
capabilities those APIs have. Including the performance of those<br />
quering API.<br />
<br />
We are *constantly* having to revise these APIs because it turns out<br />
that the querying capabilities aren't matching what our apps need.<br />
This is not a workable long term situation. And it's not even a<br />
workable short-term solution for 3rd party apps since we can't revise<br />
the APIs to support the capabilities that every 3rd party app<br />
developer needs.<br />
<br />
This is why the DataStore API allows applications to synchronize data<br />
into a application-local cache. This cache can be<br />
stored/index/grouped/sorted in whatever format the application needs<br />
in order to support its UI. It even allows things like merge data from<br />
the MobilaMessage API and the Contacts API into a single location.<br />
<br />
A very common reaction to this is "caching data in the application<br />
means duplicating the data!". This is true, but the current path we're<br />
on also causes a lot of duplication. Supporting all types of<br />
filtering, sorting and grouping like we do, forces us to create a lot<br />
of indexes. Indexes are effectively partial copies of the data. And we<br />
have to create those indexes whether they are actually used or not,<br />
because the API requires them.<br />
<br />
By allowing applications to cache the data, only data that is actively<br />
needed by installed application is copied. And we enable applications<br />
to cache data in more formats than we could every think of and bake<br />
into the API.<br />
<br />
This obviously doesn't mean that DataStore API will solve all of our<br />
problems. I suspect that something like the inter-app communication<br />
API will still be needed.<br />
<br />
=== Why not use the Inter App Communication API? ===<br />
<br />
[[WebAPI/Inter App Communication]] has more complicated security issues and is being worked at a lower priority.<br />
<br />
== Interface ==<br />
<br />
interface DataStore {<br />
// Returns the label of the DataSource.<br />
readonly attribute DOMString name;<br />
// Returns the origin of the DataSource (e.g., 'facebook.com').<br />
// TODO: defines what the value should be if owned by 'system'.<br />
readonly attribute DOMString owner;<br />
// is readOnly a F(current_app, datastore) function? yes<br />
readonly attribute boolean readOnly;<br />
// TODO: id should be incremental.<br />
Future<Object> get(int id);<br />
Future<void> update(int id, Object obj);<br />
Future<int> add(Object obj);<br />
Future<boolean> remove(int id);<br />
Future<void> clear();<br />
readonly attribute DOMString revisionId;<br />
attribute EventHandler onchange;<br />
Future<DataStoreChanges> getChanges(DOMString revisionId);<br />
// TODO: getAll(), getLength().<br />
};<br />
<br />
interface DataStoreChanges {<br />
readonly attribute DOMString revisionId;<br />
readonly attribute int[] addedIds;<br />
readonly attribute int[] updatedIds;<br />
readonly attribute int[] removedIds;<br />
}<br />
<br />
partial interface Navigator {<br />
Future<sequence<DataStore>> getDataStores(DOMString name);<br />
};<br />
<br />
== Manifest ==<br />
<br />
=== For the application that provides the datastore ===<br />
{<br />
...<br />
datastores-owned: {<br />
"contacts": {<br />
"readonly": true,<br />
"name": "Facebook contacts",<br />
}<br />
},<br />
...<br />
}<br />
<br />
=== For the application that wants to access the datastore ===<br />
{<br />
...<br />
datastores-access: {<br />
"contacts": {<br />
"access": "readonly",<br />
"description": ...<br />
}<br />
},<br />
...<br />
}<br />
<br />
== Incremental Schema ==<br />
DataStore is designed for sharing data among applications. Applications will make some assumptions on data types of attributes. If the data type of an attributes is not consistent among applications, applications may be broken. So, data types of attributes should be enforced.<br />
to define types of an attributes while attributes with a new path were found first time. In another word, once a new object was added to a data store, its tree of attributes will be traveled, and define the type of new found attributes with the type of their values.<br />
<br />
For example, if the following object is the object been added to a data store.<br />
<br />
{<br />
SN: 123,<br />
name: "John Lin",<br />
info: {<br />
address: ".....",<br />
birth: Date(....),<br />
}<br />
}<br />
<br />
Then, the types table of the data store is<br />
SN: Integer<br />
name: String<br />
info: object<br />
info address: String<br />
info birth: Date<br />
<br />
Then, the following object is added.<br />
{<br />
SN: 123,<br />
name: "John Lin",<br />
info: {<br />
address: ".....",<br />
birth: Date(....),<br />
phone: "123456",<br />
}<br />
}<br />
<br />
The types table should be<br />
SN: Integer<br />
name: String<br />
info: object<br />
info address: String<br />
info birth: Date<br />
info phone: String<br />
<br />
Every time a new object was added to a data store, the types of attributes would be checked against the types table of the data store. The action of adding will be failed if the type of any attribute does not match the type defined in the types table.<br />
<br />
== Issues ==<br />
* {name, owner, value} is a complicated key.<br />
* UI: what to do when we have multiple access requests?<br />
* What's happening if the central gets changes during the process of local updates?<br />
* |addedIds|, |removedIds| and |updatedIds| arrays should be synchronized. For example, the ID of record that has been updated and removed should only show up in the |removedIds| array. Need to define the behaviours.<br />
* Should all data stores with the same name share a schema?<br />
* Enforcing types can be a footgun. What should a data provider do if it decides some key should have a different type?</div>Sickinghttps://wiki.mozilla.org/index.php?title=WebAPI/KeboardIME&diff=685585WebAPI/KeboardIME2013-07-26T06:51:09Z<p>Sicking: /* Proposed API */</p>
<hr />
<div><br />
__TOC__<br />
<br />
== Introduction ==<br />
<br />
Virtual Keyboard/IME API aims to implement the system IME as a Web App. It will be used in Firefox OS and use cases could be found in the<br />
[https://wiki.mozilla.org/images/6/61/Gaia_Keyboard_20130417.pdf Firefox OS Keyboard UX document(WIP)].<br />
<br />
The API provides the communication channel between the IME App and the other App that receives user's inputs.<br />
<br />
It is very different from the [http://dvcs.w3.org/hg/ime-api/raw-file/default/Overview.html IME API from Google] that aims to re-use the system's IME in a web page.<br />
<br />
== Status ==<br />
<br />
API discussion:<br />
<br />
# [https://groups.google.com/forum/?fromgroups#!topic/mozilla.dev.webapi/Vs3-HGv9NNw WebAPI mailing list post]<br />
# [https://groups.google.com/forum/?fromgroups=#!topic/mozilla.dev.webapi/A7dIBaR3lpU Extended API mailing list post]<br />
<br />
Implementation:<br />
#{{bug|737110}} - Bug 737110 - Virtual Keyboard API<br />
#{{bug|805586}} - [keyboard] keyboard needs a 'hide keyboard' button(main tracking bug)<br />
#{{bug|844716}} - Enable keyboard Apps to get/set selection range of the input field<br />
#{{bug|860546}} - [keyboard] JS changes to a textfield while keyboard is displayed do not get passed to keyboard<br />
#{{bug|861665}} - Allow IME to get notification when text field content is changed<br />
#{{bug|861515}} - Keyboard should be able to modify the text of the input field directly<br />
#{{bug|838308}} - mozKeyboard should require a permission to use<br />
#{{bug|842436}} - Keyboard API: There should only be one keyboard active, and Gecko should block interaction from non-active keyboards<br />
<br />
== Features ==<br />
<br />
The Virtual Keyboard/IME API supports the following features:<br />
<br />
* Notifies the VKB app when the focus text field was changing in other<br />
apps<br />
* Allow user to manual hide the keyboard. Check {{bug|737110}}.<br />
* The VKB app should be responsive to properties and the state of the input field (more than HTML5 input type, including current content, cursor position, x-inputmode {{bug|796544}}).<br />
* Sends trust<br />
* The VKB app should be able to send trusted key events such as they are considered by the other apps as user' inputs.<br />
* The VKB app should be able to send a character or a string to the current input cursor position.<br />
* Keyboard should be able to overwrite the current value of the input field of the input field and set the cursor position.<br />
* The VKB app should be able to move the cursor position or select a specified range of text.<br />
* The VKB should be able to switch the focus onto the previous/next input field.<br />
* The return key label of the VKB can be customized.<br />
<br />
== Proposed Manifest of a 3rd-Party IME ==<br />
<br />
Just like any other apps, keyboard apps register themselves in the same apps registry. We extend the manifest syntax here to describe layout(s) available in a given keyboard app. Gaia will be paring the manifest. There are 3 special fields to distinguish and describe a 3rd-party IME:<br />
* [Line 4] a "role" field with value "keyboard" declares it's an IME app. Homescreen app will ignore some role types when displaying app icons, and "keyboard" is one of them. (see {{bug|892397}})<br />
* [Line 6-8] a "permissions" field that requests "keyboard" permission. All IME apps need this permission for sending input keys and updating the value of a input field.<br />
* [Line 9-30] a "entry_points" field specifies supported layouts. Each layout is described in a key-value pair, where the key represents the layout name (will be shown up on Settings app with the app name), and the value describes the detailed information of the layout, including launch path of the layout and supported input types. (See [[#Layout Matching Algorithm]])<br />
** The allowed value in "types" field is a subset of [http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#attr-input-type type attribute of input element]: text, search, tel, number, url, email. Other types will be ignored by FxOS Gaia in the initial version because at this point UI for <select> and <input type=date> (called "value selectors") are not open for 3rd-party implementation.<br />
<br />
=== IME App Manifest Example ===<br />
<br />
1 {<br />
2 "name": "MyKeyboard",<br />
3 "description": "A 3rd Party Keyboard",<br />
4 "role": "keyboard",<br />
5 "launch_path": "/settings.html",<br />
6 "permissions": {<br />
7 "keyboard": {}<br />
8 },<br />
9 "entry_points": {<br />
10 "English": {<br />
11 "launch_path": "/index.html#en",<br />
12 "description": "English layout",<br />
13 "types": ["url", "number"]<br />
14 },<br />
15 "English (Dvorak)": {<br />
16 "launch_path": "/index.html#en-Dvorak",<br />
17 "description": "Dvorak layout",<br />
18 "types": ["text", "url", "number"]<br />
19 },<br />
20 "Spanish": {<br />
21 "launch_path": "/index.html#es",<br />
22 "description": "Spanish layout",<br />
23 "types": ["text", "number"]<br />
24 },<br />
25 "number": {<br />
26 "launch_path": "/index.html#numberLayout",<br />
27 "description": "Number layout",<br />
28 "types": ["number"]<br />
29 }<br />
30 }<br />
31 }<br />
<br />
=== Layout Matching Algorithm ===<br />
<br />
When an input field is focused, if its <code>type</code> attribute is one of the allowed values stated above, it will be used to filter a set of candidate layouts. A candidate layout means it can handle this input type or is possible to let user input all characters that this input field can accept.<br />
For example, if the type of a input is "url", then a layout with "url" or "text" listed in the <code>types</code> of its manifest will be matched. However, if a input field with type "text", then all layouts that support "text" will be matched, but those layouts that only support "url" will not. This is because we believe layouts that can handle "text" could be a fallback for "url" input type, but not vice versa. An input type fallback plan is pre-defined as follows:<br />
<br />
* "text" is the fallback of "textarea", "url", "email", "password", "search", and "contenteditable".<br />
* "number" is the fallback of "number" and "tel".<br />
<br />
The matching algorithm of keyboard manager in System app is as follows:<br />
<br />
# With the given type, find all layouts claims to support the said type and put it into the list.<br />
# Next, if fallback exists for a given type, find layouts claims to support the fallback type and put it into the list. Layouts do not get duplicated listing even if it supports both types.<br />
# Present the user with the choice of the layouts available to handle the input field. The order of presenting list is depend on UX design and/or user preferences in Settings.<br />
<br />
== Proposed API ==<br />
<br />
The input method API is available to web content who intend to implement an input method, or "input source", or "virtual keyboard".<br />
<br />
partial interface Navigator {<br />
readonly attribute InputMethod inputMethod;<br />
};<br />
<br />
interface InputMethod: EventTarget {<br />
// Input Method Manager contain a few global methods expose to apps<br />
readonly attribute InputMethodManager mgmt;<br />
<br />
// Fired when the input context changes, include changes from and to null.<br />
// The new InputContext instance will be available in the event object under |inputcontext| property.<br />
// When it changes to null it means the app (the user of this API) no longer has the control of the original focused input field.<br />
// Note that if the app saves the original context, it might get void; implementation decides when to void the input context.<br />
attribute EventHandler oninputcontextchange;<br />
<br />
// An "input context" is mapped to a text field that the app is allow to mutate.<br />
// this attribute should be null when there is no text field currently focused.<br />
readonly attribute InputContext? inputcontext;<br />
};<br />
<br />
// Manages the list of IMEs, enables/disables IME and switches to an IME.<br />
interface InputMethodManager {<br />
// Ask the OS to show a list of available IMEs for users to switch from.<br />
// OS should ignore this request if the app is currently not the active one.<br />
void <strike>showInputMethodPicker</strike> showAll();<br />
<br />
// Ask the OS to switch away from the current active Keyboard app.<br />
// OS should ignore this request if the app is currently not the active one.<br />
void <strike>switchToNextInputMethod</strike> next();<br />
<br />
// To know if the OS supports IME switching or not.<br />
// Use case: let the keyboard app knows if it is necessary to show the "IME switching"<br />
// (globe) button. We have a use case that when there is only one IME enabled, we<br />
// should not show the globe icon.<br />
boolean supportsSwitching();<br />
<br />
// Ask the OS to hide the current active Keyboard app. (was: |removeFocus()|)<br />
// OS should ignore this request if the app is currently not the active one.<br />
// The OS will void the current input context (if it exists).<br />
// This method belong to |mgmt| because we would like to allow Keyboard to access to<br />
// this method w/o a input context.<br />
void <strike>removeFocus</strike> hide();<br />
};<br />
<br />
// The input context, which consists of attributes and information of current input field.<br />
// It also hosts the methods available to the keyboard app to mutate the input field represented.<br />
// An "input context" gets void when the app is no longer allowed to interact with the text field,<br />
// e.g., the text field does no longer exist, the app is being switched to background, and etc.<br />
// [JJ] I doubt whether we should have 'name', 'type', etc. here. In the manifest we should<br />
// have entry points where the keyboard specifies which view to load when going into a<br />
// certain context. Requiring to do this manually will give extra work.<br />
// The system should guarantee that the right view is rendered based on entry_points in<br />
// in manifest (e.g. navigate keyboard to #text/en, or something, based on manifest.<br />
// [Tim] I don't think they are exclusive. A keyboard app might choose to load the same page with the same hash<br />
// for different types but only to deal with the |type| or |inputmode| difference later.<br />
// [JS] I agree that exposing type etc is a good idea. It's quite likely that the same keyboard<br />
// app will want to handle multiple different keyboards, for example both for latin text as well as<br />
// numeric keyboard.<br />
// But I agree that also enabling the keyboard to declare in the manifest which types it supports<br />
// is a good idea.<br />
interface <strike>InputMethodConnection</strike> InputContext: EventTarget {<br />
// The tag name of input field, which is enum of "input", "textarea", or "contenteditable"<br />
// [JS] I think "type" would be better here.<br />
// [JS] This should also be 'readonly', right?<br />
DOMString name;<br />
<br />
// The type of the input field, which is enum of text, number, password, url, search, email, and so on.<br />
// See http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#states-of-the-type-attribute<br />
// [JS] and "inputtype" here.<br />
// [JS] This should also be 'readonly', right?<br />
DOMString type;<br />
<br />
/*<br />
* The inputmode string, representing the input mode.<br />
* See http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#input-modalities:-the-inputmode-attribute<br />
*/<br />
// [JS] This should be 'readonly', right?<br />
DOMString inputmode;<br />
<br />
/*<br />
* The primary language for the input field.<br />
* It is the value of HTMLElement.lang.<br />
* See http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#htmlelement<br />
*/<br />
// [JS] This should be 'readonly', right?<br />
DOMString lang;<br />
<br />
/*<br />
* Get the whole text content of the input field.<br />
*/<br />
Promise<DOMString> getText([optional] offset, [optional] length);<br />
<br />
// The start and stop position of the selection.<br />
readonly attribute long selectionStart;<br />
readonly attribute long selectionEnd;<br />
<br />
/*<br />
* Set the selection range of the the editable text.<br />
* Note: This method cannot be used to move the cursor during composition. Calling this<br />
* method will cancel composition.<br />
* @param start The beginning of the selected text.<br />
* @param length The length of the selected text.<br />
*<br />
* Note that the start position should be less or equal to the end position.<br />
* To move the cursor, set the start and end position to the same value.<br />
*<br />
* [JJ] I think that this method should return the same info as the selectionchange event<br />
* rather than a boolean.<br />
* [yxl] I don't think so. We could get selection range info by checking the attributes of <br />
* selectionStart and selectionEnd.<br />
*/<br />
Promise<boolean> setSelectionRange(long start, long length);<br />
<br />
/* User moves the cursor, or changes the selection with other means. If the text around<br />
* cursor has changed, but the cursor has not been moved, the IME won't get notification.<br />
*<br />
* [JJ] I would merge this with onsurroundingtextchange to have 1 state event.<br />
* in the end, every onselectionchange event will also generate a surrounding<br />
* text change event.<br />
*/<br />
attribute EventHandler onselectionchange;<br />
<br />
/*<br />
* Commit text to current input field and replace text around cursor position. It will clear the current composition.<br />
*<br />
* @param text The string to be replaced with.<br />
* @param offset The offset from the cursor position where replacing starts. Defaults to 0.<br />
* @param length The length of text to replace. Defaults to 0.<br />
*/<br />
Promise<boolean> <strike>commitText</strike> replaceSurroundingText(DOMString text, [optional] long offset, [optional] long length);<br />
<br />
/*<br />
*<br />
* Delete text around the cursor.<br />
* @param offset The offset from the cursor position where deletion starts.<br />
* @param length The length of text to delete.<br />
* TODO: maybe updateSurroundingText(DOMString beforeText, DOMString afterText); ?<br />
* [JJ] Rather do a replaceSurroundingText(long offset, long length, optional DOMString text)<br />
* If text is null or empty, it behaves the same<br />
*/<br />
Promise<boolean> deleteSurroundingText(long offset, long length);<br />
<br />
/*<br />
* Notifies when the text around the cursor is changed, due to either text<br />
* editing or cursor movement. If the cursor has been moved, but the text around has not<br />
* changed, the IME won't get notification.<br />
*<br />
* The event handler function is specified as:<br />
* @param beforeString Text before and including cursor position.<br />
* @param afterString Text after and excluing cursor position.<br />
* function(DOMString beforeText, DOMString afterText) {<br />
* ...<br />
* }<br />
*/<br />
// [JS] Can you describe how the cursor can be moved without the surrounding text<br />
// also changing? Is that really something that can happen?<br />
attribute SurroundingTextChangeEventHandler onsurroundingtextchange;<br />
<br />
/*<br />
* send a character with its key events.<br />
* @param modifiers see http://mxr.mozilla.org/mozilla-central/source/dom/interfaces/base/nsIDOMWindowUtils.idl#206<br />
* @return true if succeeds. Otherwise false if the input context becomes void.<br />
* Alternative: sendKey(KeyboardEvent event), but we will likely waste memory for creating the KeyboardEvent object.<br />
*/<br />
Promise<boolean> sendKey(long keyCode, long charCode, long modifiers);<br />
<br />
/*<br />
* Set current composition. It will start or update composition.<br />
* @param cursor Position in the text of the cursor.<br />
*<br />
* The API implementation should automatically ends the composition<br />
* session (with event and confirm the current composition) if <br />
* endComposition is never called. Same apply when the inputContext is lost<br />
* during a unfinished composition session.<br />
*/<br />
// [JS] A more detailed description of how to use these two functions would be great.<br />
// It's not really obvious to me what either of these two arguments do.<br />
Promise<boolean> setComposition(DOMString text, long cursor);<br />
<br />
/*<br />
* End composition and actually commit the text. (was |commitText(text, offset, length)|)<br />
* Ending the composition with an empty string will not send any text.<br />
* Note that if composition always ends automatically (with the current composition committed) if the composition <br />
* did not explicitly with |endComposition()| but was interrupted with |sendKey()|, |setSelectionRange()|,<br />
* user moving the cursor, or remove the focus, etc.<br />
*<br />
* @param text The text<br />
*/<br />
Promise<boolean> endComposition(DOMString text);<br />
};<br />
<br />
=== Use cases for each of the methods ===<br />
<br />
* For a simple virtual keyboard action (send a character and key events w/ each user action), use <code>sendKey()</code>. TODO: should we allow backspace key to be sent from the method? If not, how do send these non-printable characters and it's effect with key events?<br />
*[yxl] I perfer to allowing non-printable character, such as backspace key, to be sent, if there is no security issue. This<br />
* would give the IME more flexibility.<br />
* For spellcheck, autocomplete etc, use surrounding text methods.<br />
* For cursor moment helper features, use <code>setSelectionRange()</code> and related attributes.<br />
* For Asian IMEs that sends characters and composition along with the composition events, use <code>setComposition()</code> and <code>endComposition()</code>.<br />
<br />
It is important to stick with the given use cases because the web application might need to react with what the user actually do. To test the events currently sent to the web, see http://jsfiddle.net/timdream/YDGgk/ .<br />
<br />
== Examples ==<br />
<br />
The following "snowman filler" Keyboard app will start filling snowman character ("☃") and follow by characters "SNOW" with key events to the input field whenever the user is focus on a input field and switch to the keyboard app.<br />
<br />
If the field is a numeric field, it will fill "1337".<br />
<br />
var timer;<br />
function startTyping(inputContext) {<br />
clearTimeout(timer);<br />
timer = setInterval(function typing() {<br />
/* [JJ] So I think that this code shouldn't be here, because you'll get lots of clutter<br />
* as you'll also have to take languages into account.<br />
* Rather rely on entry points in manifest...<br />
*/<br />
<br />
if (inputContext.inputmode === 'numeric' || inputContext.type === 'number') {<br />
['1', '3', '3', '7'].forEach(function (k) {<br />
// For numbers, keyCode is same as the charCode.<br />
inputContext.sendKey(k.charCodeAt(0), k.charCodeAt(0));<br />
});<br />
} else {<br />
// It's not a good idea to commit text w/o sending events. So we should first send composition events.<br />
inputContext.setComposition('☃');<br />
// end the composition and commit the text.<br />
inputContext.endComposition('☃');<br />
['S', 'N', 'O', 'W'].forEach(function (k) {<br />
// For capital Latin letters, keyCode is same as the charCode.<br />
inputContext.sendKey(k.charCodeAt(0), k.charCodeAt(0));<br />
});<br />
}, 1000);<br />
}<br />
<br />
function stopTyping() {<br />
clearTimeout(timer);<br />
}<br />
<br />
var im = navigator.inputMethod;<br />
<br />
im.addEventListener('inputcontextchange', function contextchanged(evt) {<br />
if (evt.inputcontext) {<br />
// Got a new context, start working with it.<br />
startTyping(evt.inputcontext);<br />
} else {<br />
// The user have removed the focus, we are not allow to type into the text field anymore.<br />
stopTyping();<br />
}<br />
});<br />
<br />
if (im.inputcontext) {<br />
// The webpage here is loaded *after* the user has place the focus on the text field,<br />
// let's start typing now.<br />
startTyping(im.inputcontext);<br />
}<br />
<br />
== Related ==<br />
<br />
Android IME API:<br />
<br />
http://developer.android.com/guide/topics/text/creating-input-method.html#IMEAPI<br />
<br />
iOS Keyboard Management:<br />
<br />
http://developer.apple.com/library/ios/#documentation/StringsTextFonts/Conceptual/TextAndWebiPhoneOS/KeyboardManagement/KeyboardManagement.html#//apple_ref/doc/uid/TP40009542-CH5-SW1<br />
<br />
Chrome Extensions API:<br />
<br />
http://developer.chrome.com/trunk/extensions/input.ime.html</div>Sickinghttps://wiki.mozilla.org/index.php?title=WebAPI/KeboardIME&diff=685584WebAPI/KeboardIME2013-07-26T06:49:00Z<p>Sicking: /* Proposed API */</p>
<hr />
<div><br />
__TOC__<br />
<br />
== Introduction ==<br />
<br />
Virtual Keyboard/IME API aims to implement the system IME as a Web App. It will be used in Firefox OS and use cases could be found in the<br />
[https://wiki.mozilla.org/images/6/61/Gaia_Keyboard_20130417.pdf Firefox OS Keyboard UX document(WIP)].<br />
<br />
The API provides the communication channel between the IME App and the other App that receives user's inputs.<br />
<br />
It is very different from the [http://dvcs.w3.org/hg/ime-api/raw-file/default/Overview.html IME API from Google] that aims to re-use the system's IME in a web page.<br />
<br />
== Status ==<br />
<br />
API discussion:<br />
<br />
# [https://groups.google.com/forum/?fromgroups#!topic/mozilla.dev.webapi/Vs3-HGv9NNw WebAPI mailing list post]<br />
# [https://groups.google.com/forum/?fromgroups=#!topic/mozilla.dev.webapi/A7dIBaR3lpU Extended API mailing list post]<br />
<br />
Implementation:<br />
#{{bug|737110}} - Bug 737110 - Virtual Keyboard API<br />
#{{bug|805586}} - [keyboard] keyboard needs a 'hide keyboard' button(main tracking bug)<br />
#{{bug|844716}} - Enable keyboard Apps to get/set selection range of the input field<br />
#{{bug|860546}} - [keyboard] JS changes to a textfield while keyboard is displayed do not get passed to keyboard<br />
#{{bug|861665}} - Allow IME to get notification when text field content is changed<br />
#{{bug|861515}} - Keyboard should be able to modify the text of the input field directly<br />
#{{bug|838308}} - mozKeyboard should require a permission to use<br />
#{{bug|842436}} - Keyboard API: There should only be one keyboard active, and Gecko should block interaction from non-active keyboards<br />
<br />
== Features ==<br />
<br />
The Virtual Keyboard/IME API supports the following features:<br />
<br />
* Notifies the VKB app when the focus text field was changing in other<br />
apps<br />
* Allow user to manual hide the keyboard. Check {{bug|737110}}.<br />
* The VKB app should be responsive to properties and the state of the input field (more than HTML5 input type, including current content, cursor position, x-inputmode {{bug|796544}}).<br />
* Sends trust<br />
* The VKB app should be able to send trusted key events such as they are considered by the other apps as user' inputs.<br />
* The VKB app should be able to send a character or a string to the current input cursor position.<br />
* Keyboard should be able to overwrite the current value of the input field of the input field and set the cursor position.<br />
* The VKB app should be able to move the cursor position or select a specified range of text.<br />
* The VKB should be able to switch the focus onto the previous/next input field.<br />
* The return key label of the VKB can be customized.<br />
<br />
== Proposed Manifest of a 3rd-Party IME ==<br />
<br />
Just like any other apps, keyboard apps register themselves in the same apps registry. We extend the manifest syntax here to describe layout(s) available in a given keyboard app. Gaia will be paring the manifest. There are 3 special fields to distinguish and describe a 3rd-party IME:<br />
* [Line 4] a "role" field with value "keyboard" declares it's an IME app. Homescreen app will ignore some role types when displaying app icons, and "keyboard" is one of them. (see {{bug|892397}})<br />
* [Line 6-8] a "permissions" field that requests "keyboard" permission. All IME apps need this permission for sending input keys and updating the value of a input field.<br />
* [Line 9-30] a "entry_points" field specifies supported layouts. Each layout is described in a key-value pair, where the key represents the layout name (will be shown up on Settings app with the app name), and the value describes the detailed information of the layout, including launch path of the layout and supported input types. (See [[#Layout Matching Algorithm]])<br />
** The allowed value in "types" field is a subset of [http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#attr-input-type type attribute of input element]: text, search, tel, number, url, email. Other types will be ignored by FxOS Gaia in the initial version because at this point UI for <select> and <input type=date> (called "value selectors") are not open for 3rd-party implementation.<br />
<br />
=== IME App Manifest Example ===<br />
<br />
1 {<br />
2 "name": "MyKeyboard",<br />
3 "description": "A 3rd Party Keyboard",<br />
4 "role": "keyboard",<br />
5 "launch_path": "/settings.html",<br />
6 "permissions": {<br />
7 "keyboard": {}<br />
8 },<br />
9 "entry_points": {<br />
10 "English": {<br />
11 "launch_path": "/index.html#en",<br />
12 "description": "English layout",<br />
13 "types": ["url", "number"]<br />
14 },<br />
15 "English (Dvorak)": {<br />
16 "launch_path": "/index.html#en-Dvorak",<br />
17 "description": "Dvorak layout",<br />
18 "types": ["text", "url", "number"]<br />
19 },<br />
20 "Spanish": {<br />
21 "launch_path": "/index.html#es",<br />
22 "description": "Spanish layout",<br />
23 "types": ["text", "number"]<br />
24 },<br />
25 "number": {<br />
26 "launch_path": "/index.html#numberLayout",<br />
27 "description": "Number layout",<br />
28 "types": ["number"]<br />
29 }<br />
30 }<br />
31 }<br />
<br />
=== Layout Matching Algorithm ===<br />
<br />
When an input field is focused, if its <code>type</code> attribute is one of the allowed values stated above, it will be used to filter a set of candidate layouts. A candidate layout means it can handle this input type or is possible to let user input all characters that this input field can accept.<br />
For example, if the type of a input is "url", then a layout with "url" or "text" listed in the <code>types</code> of its manifest will be matched. However, if a input field with type "text", then all layouts that support "text" will be matched, but those layouts that only support "url" will not. This is because we believe layouts that can handle "text" could be a fallback for "url" input type, but not vice versa. An input type fallback plan is pre-defined as follows:<br />
<br />
* "text" is the fallback of "textarea", "url", "email", "password", "search", and "contenteditable".<br />
* "number" is the fallback of "number" and "tel".<br />
<br />
The matching algorithm of keyboard manager in System app is as follows:<br />
<br />
# With the given type, find all layouts claims to support the said type and put it into the list.<br />
# Next, if fallback exists for a given type, find layouts claims to support the fallback type and put it into the list. Layouts do not get duplicated listing even if it supports both types.<br />
# Present the user with the choice of the layouts available to handle the input field. The order of presenting list is depend on UX design and/or user preferences in Settings.<br />
<br />
== Proposed API ==<br />
<br />
The input method API is available to web content who intend to implement an input method, or "input source", or "virtual keyboard".<br />
<br />
partial interface Navigator {<br />
readonly attribute InputMethod inputMethod;<br />
};<br />
<br />
interface InputMethod: EventTarget {<br />
// Input Method Manager contain a few global methods expose to apps<br />
readonly attribute InputMethodManager mgmt;<br />
<br />
// Fired when the input context changes, include changes from and to null.<br />
// The new InputContext instance will be available in the event object under |inputcontext| property.<br />
// When it changes to null it means the app (the user of this API) no longer has the control of the original focused input field.<br />
// Note that if the app saves the original context, it might get void; implementation decides when to void the input context.<br />
attribute EventHandler oninputcontextchange;<br />
<br />
// An "input context" is mapped to a text field that the app is allow to mutate.<br />
// this attribute should be null when there is no text field currently focused.<br />
readonly attribute InputContext? inputcontext;<br />
};<br />
<br />
// Manages the list of IMEs, enables/disables IME and switches to an IME.<br />
interface InputMethodManager {<br />
// Ask the OS to show a list of available IMEs for users to switch from.<br />
// OS should ignore this request if the app is currently not the active one.<br />
void <strike>showInputMethodPicker</strike> showAll();<br />
<br />
// Ask the OS to switch away from the current active Keyboard app.<br />
// OS should ignore this request if the app is currently not the active one.<br />
void <strike>switchToNextInputMethod</strike> next();<br />
<br />
// To know if the OS supports IME switching or not.<br />
// Use case: let the keyboard app knows if it is necessary to show the "IME switching"<br />
// (globe) button. We have a use case that when there is only one IME enabled, we<br />
// should not show the globe icon.<br />
boolean supportsSwitching();<br />
<br />
// Ask the OS to hide the current active Keyboard app. (was: |removeFocus()|)<br />
// OS should ignore this request if the app is currently not the active one.<br />
// The OS will void the current input context (if it exists).<br />
// This method belong to |mgmt| because we would like to allow Keyboard to access to<br />
// this method w/o a input context.<br />
void <strike>removeFocus</strike> hide();<br />
};<br />
<br />
// The input context, which consists of attributes and information of current input field.<br />
// It also hosts the methods available to the keyboard app to mutate the input field represented.<br />
// An "input context" gets void when the app is no longer allowed to interact with the text field,<br />
// e.g., the text field does no longer exist, the app is being switched to background, and etc.<br />
// [JJ] I doubt whether we should have 'name', 'type', etc. here. In the manifest we should<br />
// have entry points where the keyboard specifies which view to load when going into a<br />
// certain context. Requiring to do this manually will give extra work.<br />
// The system should guarantee that the right view is rendered based on entry_points in<br />
// in manifest (e.g. navigate keyboard to #text/en, or something, based on manifest.<br />
// [Tim] I don't think they are exclusive. A keyboard app might choose to load the same page with the same hash<br />
// for different types but only to deal with the |type| or |inputmode| difference later.<br />
// [JS] I agree that exposing type etc is a good idea. It's quite likely that the same keyboard<br />
// app will want to handle multiple different keyboards, for example both for latin text as well as<br />
// numeric keyboard.<br />
// But I agree that also enabling the keyboard to declare in the manifest which types it supports<br />
// is a good idea.<br />
interface <strike>InputMethodConnection</strike> InputContext: EventTarget {<br />
// The tag name of input field, which is enum of "input", "textarea", or "contenteditable"<br />
// [JS] I think "type" would be better here.<br />
// [JS] This should also be 'readonly', right?<br />
DOMString name;<br />
<br />
// The type of the input field, which is enum of text, number, password, url, search, email, and so on.<br />
// See http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#states-of-the-type-attribute<br />
// [JS] and "inputtype" here.<br />
// [JS] This should also be 'readonly', right?<br />
DOMString type;<br />
<br />
/*<br />
* The inputmode string, representing the input mode.<br />
* See http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#input-modalities:-the-inputmode-attribute<br />
*/<br />
// [JS] This should be 'readonly', right?<br />
DOMString inputmode;<br />
<br />
/*<br />
* The primary language for the input field.<br />
* It is the value of HTMLElement.lang.<br />
* See http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#htmlelement<br />
*/<br />
// [JS] This should be 'readonly', right?<br />
DOMString lang;<br />
<br />
/*<br />
* Get the whole text content of the input field.<br />
*/<br />
Promise<DOMString> getText([optional] offset, [optional] length);<br />
<br />
// The start and stop position of the selection.<br />
readonly attribute long selectionStart;<br />
readonly attribute long selectionEnd;<br />
<br />
/*<br />
* Set the selection range of the the editable text.<br />
* Note: This method cannot be used to move the cursor during composition. Calling this<br />
* method will cancel composition.<br />
* @param start The beginning of the selected text.<br />
* @param length The length of the selected text.<br />
*<br />
* Note that the start position should be less or equal to the end position.<br />
* To move the cursor, set the start and end position to the same value.<br />
*<br />
* [JJ] I think that this method should return the same info as the selectionchange event<br />
* rather than a boolean.<br />
* [yxl] I don't think so. We could get selection range info by checking the attributes of <br />
* selectionStart and selectionEnd.<br />
*/<br />
Promise<boolean> setSelectionRange(long start, long length);<br />
<br />
/* User moves the cursor, or changes the selection with other means. If the text around<br />
* cursor has changed, but the cursor has not been moved, the IME won't get notification.<br />
*<br />
* [JJ] I would merge this with onsurroundingtextchange to have 1 state event.<br />
* in the end, every onselectionchange event will also generate a surrounding<br />
* text change event.<br />
*/<br />
attribute EventHandler onselectionchange;<br />
<br />
/*<br />
* Commit text to current input field and replace text around cursor position. It will clear the current composition.<br />
*<br />
* @param text The string to be replaced with.<br />
* @param offset The offset from the cursor position where replacing starts. Defaults to 0.<br />
* @param length The length of text to replace. Defaults to 0.<br />
*/<br />
Promise<boolean> <strike>commitText</strike> replaceSurroundingText(DOMString text, [optional] long offset, [optional] long length);<br />
<br />
/*<br />
*<br />
* Delete text around the cursor.<br />
* @param offset The offset from the cursor position where deletion starts.<br />
* @param length The length of text to delete.<br />
* TODO: maybe updateSurroundingText(DOMString beforeText, DOMString afterText); ?<br />
* [JJ] Rather do a replaceSurroundingText(long offset, long length, optional DOMString text)<br />
* If text is null or empty, it behaves the same<br />
*/<br />
Promise<boolean> deleteSurroundingText(long offset, long length);<br />
<br />
/*<br />
* Notifies when the text around the cursor is changed, due to either text<br />
* editing or cursor movement. If the cursor has been moved, but the text around has not<br />
* changed, the IME won't get notification.<br />
*<br />
* The event handler function is specified as:<br />
* @param beforeString Text before and including cursor position.<br />
* @param afterString Text after and excluing cursor position.<br />
* function(DOMString beforeText, DOMString afterText) {<br />
* ...<br />
* }<br />
*/<br />
// [JS] Can you describe how the cursor can be moved without the surrounding text<br />
// also changing? Is that really something that can happen?<br />
attribute SurroundingTextChangeEventHandler onsurroundingtextchange;<br />
<br />
/*<br />
* send a character with its key events.<br />
* @param modifiers see http://mxr.mozilla.org/mozilla-central/source/dom/interfaces/base/nsIDOMWindowUtils.idl#206<br />
* @return true if succeeds. Otherwise false if the input context becomes void.<br />
* Alternative: sendKey(KeyboardEvent event), but we will likely waste memory for creating the KeyboardEvent object.<br />
*/<br />
Promise<boolean> sendKey(long keyCode, long charCode, long modifiers);<br />
<br />
/*<br />
* Set current composition. It will start or update composition.<br />
* @param cursor Position in the text of the cursor.<br />
*<br />
* The API implementation should automatically ends the composition<br />
* session (with event and confirm the current composition) if <br />
* endComposition is never called. Same apply when the inputContext is lost<br />
* during a unfinished composition session.<br />
*/<br />
Promise<boolean> setComposition(DOMString text, long cursor);<br />
<br />
/*<br />
* End composition and actually commit the text. (was |commitText(text, offset, length)|)<br />
* Ending the composition with an empty string will not send any text.<br />
* Note that if composition always ends automatically (with the current composition committed) if the composition <br />
* did not explicitly with |endComposition()| but was interrupted with |sendKey()|, |setSelectionRange()|,<br />
* user moving the cursor, or remove the focus, etc.<br />
*<br />
* @param text The text<br />
*/<br />
Promise<boolean> endComposition(DOMString text);<br />
};<br />
<br />
=== Use cases for each of the methods ===<br />
<br />
* For a simple virtual keyboard action (send a character and key events w/ each user action), use <code>sendKey()</code>. TODO: should we allow backspace key to be sent from the method? If not, how do send these non-printable characters and it's effect with key events?<br />
*[yxl] I perfer to allowing non-printable character, such as backspace key, to be sent, if there is no security issue. This<br />
* would give the IME more flexibility.<br />
* For spellcheck, autocomplete etc, use surrounding text methods.<br />
* For cursor moment helper features, use <code>setSelectionRange()</code> and related attributes.<br />
* For Asian IMEs that sends characters and composition along with the composition events, use <code>setComposition()</code> and <code>endComposition()</code>.<br />
<br />
It is important to stick with the given use cases because the web application might need to react with what the user actually do. To test the events currently sent to the web, see http://jsfiddle.net/timdream/YDGgk/ .<br />
<br />
== Examples ==<br />
<br />
The following "snowman filler" Keyboard app will start filling snowman character ("☃") and follow by characters "SNOW" with key events to the input field whenever the user is focus on a input field and switch to the keyboard app.<br />
<br />
If the field is a numeric field, it will fill "1337".<br />
<br />
var timer;<br />
function startTyping(inputContext) {<br />
clearTimeout(timer);<br />
timer = setInterval(function typing() {<br />
/* [JJ] So I think that this code shouldn't be here, because you'll get lots of clutter<br />
* as you'll also have to take languages into account.<br />
* Rather rely on entry points in manifest...<br />
*/<br />
<br />
if (inputContext.inputmode === 'numeric' || inputContext.type === 'number') {<br />
['1', '3', '3', '7'].forEach(function (k) {<br />
// For numbers, keyCode is same as the charCode.<br />
inputContext.sendKey(k.charCodeAt(0), k.charCodeAt(0));<br />
});<br />
} else {<br />
// It's not a good idea to commit text w/o sending events. So we should first send composition events.<br />
inputContext.setComposition('☃');<br />
// end the composition and commit the text.<br />
inputContext.endComposition('☃');<br />
['S', 'N', 'O', 'W'].forEach(function (k) {<br />
// For capital Latin letters, keyCode is same as the charCode.<br />
inputContext.sendKey(k.charCodeAt(0), k.charCodeAt(0));<br />
});<br />
}, 1000);<br />
}<br />
<br />
function stopTyping() {<br />
clearTimeout(timer);<br />
}<br />
<br />
var im = navigator.inputMethod;<br />
<br />
im.addEventListener('inputcontextchange', function contextchanged(evt) {<br />
if (evt.inputcontext) {<br />
// Got a new context, start working with it.<br />
startTyping(evt.inputcontext);<br />
} else {<br />
// The user have removed the focus, we are not allow to type into the text field anymore.<br />
stopTyping();<br />
}<br />
});<br />
<br />
if (im.inputcontext) {<br />
// The webpage here is loaded *after* the user has place the focus on the text field,<br />
// let's start typing now.<br />
startTyping(im.inputcontext);<br />
}<br />
<br />
== Related ==<br />
<br />
Android IME API:<br />
<br />
http://developer.android.com/guide/topics/text/creating-input-method.html#IMEAPI<br />
<br />
iOS Keyboard Management:<br />
<br />
http://developer.apple.com/library/ios/#documentation/StringsTextFonts/Conceptual/TextAndWebiPhoneOS/KeyboardManagement/KeyboardManagement.html#//apple_ref/doc/uid/TP40009542-CH5-SW1<br />
<br />
Chrome Extensions API:<br />
<br />
http://developer.chrome.com/trunk/extensions/input.ime.html</div>Sickinghttps://wiki.mozilla.org/index.php?title=WebAPI/KeboardIME&diff=685549WebAPI/KeboardIME2013-07-26T01:03:26Z<p>Sicking: /* Proposed API */</p>
<hr />
<div><br />
__TOC__<br />
<br />
== Introduction ==<br />
<br />
Virtual Keyboard/IME API aims to implement the system IME as a Web App. It will be used in Firefox OS and use cases could be found in the<br />
[https://wiki.mozilla.org/images/6/61/Gaia_Keyboard_20130417.pdf Firefox OS Keyboard UX document(WIP)].<br />
<br />
The API provides the communication channel between the IME App and the other App that receives user's inputs.<br />
<br />
It is very different from the [http://dvcs.w3.org/hg/ime-api/raw-file/default/Overview.html IME API from Google] that aims to re-use the system's IME in a web page.<br />
<br />
== Status ==<br />
<br />
API discussion:<br />
<br />
# [https://groups.google.com/forum/?fromgroups#!topic/mozilla.dev.webapi/Vs3-HGv9NNw WebAPI mailing list post]<br />
# [https://groups.google.com/forum/?fromgroups=#!topic/mozilla.dev.webapi/A7dIBaR3lpU Extended API mailing list post]<br />
<br />
Implementation:<br />
#{{bug|737110}} - Bug 737110 - Virtual Keyboard API<br />
#{{bug|805586}} - [keyboard] keyboard needs a 'hide keyboard' button(main tracking bug)<br />
#{{bug|844716}} - Enable keyboard Apps to get/set selection range of the input field<br />
#{{bug|860546}} - [keyboard] JS changes to a textfield while keyboard is displayed do not get passed to keyboard<br />
#{{bug|861665}} - Allow IME to get notification when text field content is changed<br />
#{{bug|861515}} - Keyboard should be able to modify the text of the input field directly<br />
#{{bug|838308}} - mozKeyboard should require a permission to use<br />
#{{bug|842436}} - Keyboard API: There should only be one keyboard active, and Gecko should block interaction from non-active keyboards<br />
<br />
== Features ==<br />
<br />
The Virtual Keyboard/IME API supports the following features:<br />
<br />
* Notifies the VKB app when the focus text field was changing in other<br />
apps<br />
* Allow user to manual hide the keyboard. Check {{bug|737110}}.<br />
* The VKB app should be responsive to properties and the state of the input field (more than HTML5 input type, including current content, cursor position, x-inputmode {{bug|796544}}).<br />
* Sends trust<br />
* The VKB app should be able to send trusted key events such as they are considered by the other apps as user' inputs.<br />
* The VKB app should be able to send a character or a string to the current input cursor position.<br />
* Keyboard should be able to overwrite the current value of the input field of the input field and set the cursor position.<br />
* The VKB app should be able to move the cursor position or select a specified range of text.<br />
* The VKB should be able to switch the focus onto the previous/next input field.<br />
* The return key label of the VKB can be customized.<br />
<br />
== Proposed Manifest of a 3rd-Party IME ==<br />
<br />
Just like any other apps, keyboard apps register themselves in the same apps registry. We extend the manifest syntax here to describe layout(s) available in a given keyboard app. Gaia will be paring the manifest. There are 3 special fields to distinguish and describe a 3rd-party IME:<br />
* [Line 4] a "role" field with value "keyboard" declares it's an IME app. Homescreen app will ignore some role types when displaying app icons, and "keyboard" is one of them. (see {{bug|892397}})<br />
* [Line 6-8] a "permissions" field that requests "keyboard" permission. All IME apps need this permission for sending input keys and updating the value of a input field.<br />
* [Line 9-30] a "entry_points" field specifies supported layouts. Each layout is described in a key-value pair, where the key represents the layout name (will be shown up on Settings app with the app name), and the value describes the detailed information of the layout, including launch path of the layout and supported input types. (See [[#Layout Matching Algorithm]])<br />
** The allowed value in "types" field is a subset of [http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#attr-input-type type attribute of input element]: text, search, tel, number, url, email. Other types will be ignored by FxOS Gaia in the initial version because at this point UI for <select> and <input type=date> (called "value selectors") are not open for 3rd-party implementation.<br />
<br />
=== IME App Manifest Example ===<br />
<br />
1 {<br />
2 "name": "MyKeyboard",<br />
3 "description": "A 3rd Party Keyboard",<br />
4 "role": "keyboard",<br />
5 "launch_path": "/settings.html",<br />
6 "permissions": {<br />
7 "keyboard": {}<br />
8 },<br />
9 "entry_points": {<br />
10 "English": {<br />
11 "launch_path": "/index.html#en",<br />
12 "description": "English layout",<br />
13 "types": ["url", "number"]<br />
14 },<br />
15 "English (Dvorak)": {<br />
16 "launch_path": "/index.html#en-Dvorak",<br />
17 "description": "Dvorak layout",<br />
18 "types": ["text", "url", "number"]<br />
19 },<br />
20 "Spanish": {<br />
21 "launch_path": "/index.html#es",<br />
22 "description": "Spanish layout",<br />
23 "types": ["text", "number"]<br />
24 },<br />
25 "number": {<br />
26 "launch_path": "/index.html#numberLayout",<br />
27 "description": "Number layout",<br />
28 "types": ["number"]<br />
29 }<br />
30 }<br />
31 }<br />
<br />
=== Layout Matching Algorithm ===<br />
<br />
When an input field is focused, if its <code>type</code> attribute is one of the allowed values stated above, it will be used to filter a set of candidate layouts. A candidate layout means it can handle this input type or is possible to let user input all characters that this input field can accept.<br />
For example, if the type of a input is "url", then a layout with "url" or "text" listed in the <code>types</code> of its manifest will be matched. However, if a input field with type "text", then all layouts that support "text" will be matched, but those layouts that only support "url" will not. This is because we believe layouts that can handle "text" could be a fallback for "url" input type, but not vice versa. An input type fallback plan is pre-defined as follows:<br />
<br />
* "text" is the fallback of "textarea", "url", "email", "password", "search", and "contenteditable".<br />
* "number" is the fallback of "number" and "tel".<br />
<br />
The matching algorithm of keyboard manager in System app is as follows:<br />
<br />
# With the given type, find all layouts claims to support the said type and put it into the list.<br />
# Next, if fallback exists for a given type, find layouts claims to support the fallback type and put it into the list. Layouts do not get duplicated listing even if it supports both types.<br />
# Present the user with the choice of the layouts available to handle the input field. The order of presenting list is depend on UX design and/or user preferences in Settings.<br />
<br />
== Proposed API ==<br />
<br />
The input method API is available to web content who intend to implement an input method, or "input source", or "virtual keyboard".<br />
<br />
partial interface Navigator {<br />
readonly attribute InputMethod inputMethod;<br />
};<br />
<br />
interface InputMethod: EventTarget {<br />
// Input Method Manager contain a few global methods expose to apps<br />
readonly attribute InputMethodManager mgmt;<br />
<br />
// Fired when the input context changes, include changes from and to null.<br />
// The new InputContext instance will be available in the event object under |inputcontext| property.<br />
// When it changes to null it means the app (the user of this API) no longer has the control of the original focused input field.<br />
// Note that if the app saves the original context, it might get void; implementation decides when to void the input context.<br />
attribute EventHandler oninputcontextchange;<br />
<br />
// An "input context" is mapped to a text field that the app is allow to mutate.<br />
// this attribute should be null when there is no text field currently focused.<br />
readonly attribute InputContext? inputcontext;<br />
};<br />
<br />
// Manages the list of IMEs, enables/disables IME and switches to an IME.<br />
interface InputMethodManager {<br />
// Ask the OS to show a list of available IMEs for users to switch from.<br />
// OS should ignore this request if the app is currently not the active one.<br />
void <strike>showInputMethodPicker</strike> showAll();<br />
<br />
// Ask the OS to switch away from the current active Keyboard app.<br />
// OS should ignore this request if the app is currently not the active one.<br />
void <strike>switchToNextInputMethod</strike> next();<br />
<br />
// To know if the OS supports IME switching or not.<br />
// Use case: let the keyboard app knows if it is necessary to show the "IME switching"<br />
// (globe) button. We have a use case that when there is only one IME enabled, we<br />
// should not show the globe icon.<br />
boolean supportsSwitching();<br />
<br />
// Ask the OS to hide the current active Keyboard app. (was: |removeFocus()|)<br />
// OS should ignore this request if the app is currently not the active one.<br />
// The OS will void the current input context (if it exists).<br />
// This method belong to |mgmt| because we would like to allow Keyboard to access to<br />
// this method w/o a input context.<br />
void <strike>removeFocus</strike> hide();<br />
};<br />
<br />
// The input context, which consists of attributes and information of current input field.<br />
// It also hosts the methods available to the keyboard app to mutate the input field represented.<br />
// An "input context" gets void when the app is no longer allowed to interact with the text field,<br />
// e.g., the text field does no longer exist, the app is being switched to background, and etc.<br />
// [JJ] I doubt whether we should have 'name', 'type', etc. here. In the manifest we should<br />
// have entry points where the keyboard specifies which view to load when going into a<br />
// certain context. Requiring to do this manually will give extra work.<br />
// The system should guarantee that the right view is rendered based on entry_points in<br />
// in manifest (e.g. navigate keyboard to #text/en, or something, based on manifest.<br />
// [Tim] I don't think they are exclusive. A keyboard app might choose to load the same page with the same hash<br />
// for different types but only to deal with the |type| or |inputmode| difference later.<br />
interface <strike>InputMethodConnection</strike> InputContext: EventTarget {<br />
// The tag name of input field, which is enum of "input", "textarea", or "contenteditable"<br />
// [JS] I think "type" would be better here.<br />
// [JS] This should also be 'readonly', right?<br />
DOMString name;<br />
<br />
// The type of the input field, which is enum of text, number, password, url, search, email, and so on.<br />
// See http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#states-of-the-type-attribute<br />
// [JS] and "inputtype" here.<br />
// [JS] This should also be 'readonly', right?<br />
DOMString type;<br />
<br />
/*<br />
* The inputmode string, representing the input mode.<br />
* See http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#input-modalities:-the-inputmode-attribute<br />
*/<br />
// [JS] This should be 'readonly', right?<br />
DOMString inputmode;<br />
<br />
/*<br />
* The primary language for the input field.<br />
* It is the value of HTMLElement.lang.<br />
* See http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#htmlelement<br />
*/<br />
// [JS] This should be 'readonly', right?<br />
DOMString lang;<br />
<br />
/*<br />
* Get the whole text content of the input field.<br />
*/<br />
Promise<DOMString> getText([optional] offset, [optional] length);<br />
<br />
// The start and stop position of the selection.<br />
readonly attribute long selectionStart;<br />
readonly attribute long selectionEnd;<br />
<br />
/*<br />
* Set the selection range of the the editable text.<br />
* Note: This method cannot be used to move the cursor during composition. Calling this<br />
* method will cancel composition.<br />
* @param start The beginning of the selected text.<br />
* @param length The length of the selected text.<br />
*<br />
* Note that the start position should be less or equal to the end position.<br />
* To move the cursor, set the start and end position to the same value.<br />
*<br />
* [JJ] I think that this method should return the same info as the selectionchange event<br />
* rather than a boolean.<br />
* [yxl] I don't think so. We could get selection range info by checking the attributes of <br />
* selectionStart and selectionEnd.<br />
*/<br />
Promise<boolean> setSelectionRange(long start, long length);<br />
<br />
/* User moves the cursor, or changes the selection with other means. If the text around<br />
* cursor has changed, but the cursor has not been moved, the IME won't get notification.<br />
*<br />
* [JJ] I would merge this with onsurroundingtextchange to have 1 state event.<br />
* in the end, every onselectionchange event will also generate a surrounding<br />
* text change event.<br />
*/<br />
attribute EventHandler onselectionchange;<br />
<br />
/*<br />
* Commit text to current input field and replace text around cursor position. It will clear the current composition.<br />
*<br />
* @param text The string to be replaced with.<br />
* @param offset The offset from the cursor position where replacing starts. Defaults to 0.<br />
* @param length The length of text to replace. Defaults to 0.<br />
*/<br />
Promise<boolean> <strike>commitText</strike> replaceSurroundingText(DOMString text, [optional] long offset, [optional] long length);<br />
<br />
/*<br />
*<br />
* Delete text around the cursor.<br />
* @param offset The offset from the cursor position where deletion starts.<br />
* @param length The length of text to delete.<br />
* TODO: maybe updateSurroundingText(DOMString beforeText, DOMString afterText); ?<br />
* [JJ] Rather do a replaceSurroundingText(long offset, long length, optional DOMString text)<br />
* If text is null or empty, it behaves the same<br />
*/<br />
Promise<boolean> deleteSurroundingText(long offset, long length);<br />
<br />
/*<br />
* Notifies when the text around the cursor is changed, due to either text<br />
* editing or cursor movement. If the cursor has been moved, but the text around has not<br />
* changed, the IME won't get notification.<br />
*<br />
* The event handler function is specified as:<br />
* @param beforeString Text before and including cursor position.<br />
* @param afterString Text after and excluing cursor position.<br />
* function(DOMString beforeText, DOMString afterText) {<br />
* ...<br />
* }<br />
*/<br />
// [JS] Can you describe how the cursor can be moved without the surrounding text<br />
// also changing? Is that really something that can happen?<br />
attribute SurroundingTextChangeEventHandler onsurroundingtextchange;<br />
<br />
/*<br />
* send a character with its key events.<br />
* @param modifiers see http://mxr.mozilla.org/mozilla-central/source/dom/interfaces/base/nsIDOMWindowUtils.idl#206<br />
* @return true if succeeds. Otherwise false if the input context becomes void.<br />
* Alternative: sendKey(KeyboardEvent event), but we will likely waste memory for creating the KeyboardEvent object.<br />
*/<br />
Promise<boolean> sendKey(long keyCode, long charCode, long modifiers);<br />
<br />
/*<br />
* Set current composition. It will start or update composition.<br />
* @param cursor Position in the text of the cursor.<br />
*<br />
* The API implementation should automatically ends the composition<br />
* session (with event and confirm the current composition) if <br />
* endComposition is never called. Same apply when the inputContext is lost<br />
* during a unfinished composition session.<br />
*/<br />
Promise<boolean> setComposition(DOMString text, long cursor);<br />
<br />
/*<br />
* End composition and actually commit the text. (was |commitText(text, offset, length)|)<br />
* Ending the composition with an empty string will not send any text.<br />
* Note that if composition always ends automatically (with the current composition committed) if the composition <br />
* did not explicitly with |endComposition()| but was interrupted with |sendKey()|, |setSelectionRange()|,<br />
* user moving the cursor, or remove the focus, etc.<br />
*<br />
* @param text The text<br />
*/<br />
Promise<boolean> endComposition(DOMString text);<br />
};<br />
<br />
=== Use cases for each of the methods ===<br />
<br />
* For a simple virtual keyboard action (send a character and key events w/ each user action), use <code>sendKey()</code>. TODO: should we allow backspace key to be sent from the method? If not, how do send these non-printable characters and it's effect with key events?<br />
*[yxl] I perfer to allowing non-printable character, such as backspace key, to be sent, if there is no security issue. This<br />
* would give the IME more flexibility.<br />
* For spellcheck, autocomplete etc, use surrounding text methods.<br />
* For cursor moment helper features, use <code>setSelectionRange()</code> and related attributes.<br />
* For Asian IMEs that sends characters and composition along with the composition events, use <code>setComposition()</code> and <code>endComposition()</code>.<br />
<br />
It is important to stick with the given use cases because the web application might need to react with what the user actually do. To test the events currently sent to the web, see http://jsfiddle.net/timdream/YDGgk/ .<br />
<br />
== Examples ==<br />
<br />
The following "snowman filler" Keyboard app will start filling snowman character ("☃") and follow by characters "SNOW" with key events to the input field whenever the user is focus on a input field and switch to the keyboard app.<br />
<br />
If the field is a numeric field, it will fill "1337".<br />
<br />
var timer;<br />
function startTyping(inputContext) {<br />
clearTimeout(timer);<br />
timer = setInterval(function typing() {<br />
/* [JJ] So I think that this code shouldn't be here, because you'll get lots of clutter<br />
* as you'll also have to take languages into account.<br />
* Rather rely on entry points in manifest...<br />
*/<br />
<br />
if (inputContext.inputmode === 'numeric' || inputContext.type === 'number') {<br />
['1', '3', '3', '7'].forEach(function (k) {<br />
// For numbers, keyCode is same as the charCode.<br />
inputContext.sendKey(k.charCodeAt(0), k.charCodeAt(0));<br />
});<br />
} else {<br />
// It's not a good idea to commit text w/o sending events. So we should first send composition events.<br />
inputContext.setComposition('☃');<br />
// end the composition and commit the text.<br />
inputContext.endComposition('☃');<br />
['S', 'N', 'O', 'W'].forEach(function (k) {<br />
// For capital Latin letters, keyCode is same as the charCode.<br />
inputContext.sendKey(k.charCodeAt(0), k.charCodeAt(0));<br />
});<br />
}, 1000);<br />
}<br />
<br />
function stopTyping() {<br />
clearTimeout(timer);<br />
}<br />
<br />
var im = navigator.inputMethod;<br />
<br />
im.addEventListener('inputcontextchange', function contextchanged(evt) {<br />
if (evt.inputcontext) {<br />
// Got a new context, start working with it.<br />
startTyping(evt.inputcontext);<br />
} else {<br />
// The user have removed the focus, we are not allow to type into the text field anymore.<br />
stopTyping();<br />
}<br />
});<br />
<br />
if (im.inputcontext) {<br />
// The webpage here is loaded *after* the user has place the focus on the text field,<br />
// let's start typing now.<br />
startTyping(im.inputcontext);<br />
}<br />
<br />
== Related ==<br />
<br />
Android IME API:<br />
<br />
http://developer.android.com/guide/topics/text/creating-input-method.html#IMEAPI<br />
<br />
iOS Keyboard Management:<br />
<br />
http://developer.apple.com/library/ios/#documentation/StringsTextFonts/Conceptual/TextAndWebiPhoneOS/KeyboardManagement/KeyboardManagement.html#//apple_ref/doc/uid/TP40009542-CH5-SW1<br />
<br />
Chrome Extensions API:<br />
<br />
http://developer.chrome.com/trunk/extensions/input.ime.html</div>Sickinghttps://wiki.mozilla.org/index.php?title=WebAPI/KeboardIME&diff=685548WebAPI/KeboardIME2013-07-26T00:46:38Z<p>Sicking: /* Proposed API */</p>
<hr />
<div><br />
__TOC__<br />
<br />
== Introduction ==<br />
<br />
Virtual Keyboard/IME API aims to implement the system IME as a Web App. It will be used in Firefox OS and use cases could be found in the<br />
[https://wiki.mozilla.org/images/6/61/Gaia_Keyboard_20130417.pdf Firefox OS Keyboard UX document(WIP)].<br />
<br />
The API provides the communication channel between the IME App and the other App that receives user's inputs.<br />
<br />
It is very different from the [http://dvcs.w3.org/hg/ime-api/raw-file/default/Overview.html IME API from Google] that aims to re-use the system's IME in a web page.<br />
<br />
== Status ==<br />
<br />
API discussion:<br />
<br />
# [https://groups.google.com/forum/?fromgroups#!topic/mozilla.dev.webapi/Vs3-HGv9NNw WebAPI mailing list post]<br />
# [https://groups.google.com/forum/?fromgroups=#!topic/mozilla.dev.webapi/A7dIBaR3lpU Extended API mailing list post]<br />
<br />
Implementation:<br />
#{{bug|737110}} - Bug 737110 - Virtual Keyboard API<br />
#{{bug|805586}} - [keyboard] keyboard needs a 'hide keyboard' button(main tracking bug)<br />
#{{bug|844716}} - Enable keyboard Apps to get/set selection range of the input field<br />
#{{bug|860546}} - [keyboard] JS changes to a textfield while keyboard is displayed do not get passed to keyboard<br />
#{{bug|861665}} - Allow IME to get notification when text field content is changed<br />
#{{bug|861515}} - Keyboard should be able to modify the text of the input field directly<br />
#{{bug|838308}} - mozKeyboard should require a permission to use<br />
#{{bug|842436}} - Keyboard API: There should only be one keyboard active, and Gecko should block interaction from non-active keyboards<br />
<br />
== Features ==<br />
<br />
The Virtual Keyboard/IME API supports the following features:<br />
<br />
* Notifies the VKB app when the focus text field was changing in other<br />
apps<br />
* Allow user to manual hide the keyboard. Check {{bug|737110}}.<br />
* The VKB app should be responsive to properties and the state of the input field (more than HTML5 input type, including current content, cursor position, x-inputmode {{bug|796544}}).<br />
* Sends trust<br />
* The VKB app should be able to send trusted key events such as they are considered by the other apps as user' inputs.<br />
* The VKB app should be able to send a character or a string to the current input cursor position.<br />
* Keyboard should be able to overwrite the current value of the input field of the input field and set the cursor position.<br />
* The VKB app should be able to move the cursor position or select a specified range of text.<br />
* The VKB should be able to switch the focus onto the previous/next input field.<br />
* The return key label of the VKB can be customized.<br />
<br />
== Proposed Manifest of a 3rd-Party IME ==<br />
<br />
Just like any other apps, keyboard apps register themselves in the same apps registry. We extend the manifest syntax here to describe layout(s) available in a given keyboard app. Gaia will be paring the manifest. There are 3 special fields to distinguish and describe a 3rd-party IME:<br />
* [Line 4] a "role" field with value "keyboard" declares it's an IME app. Homescreen app will ignore some role types when displaying app icons, and "keyboard" is one of them. (see {{bug|892397}})<br />
* [Line 6-8] a "permissions" field that requests "keyboard" permission. All IME apps need this permission for sending input keys and updating the value of a input field.<br />
* [Line 9-30] a "entry_points" field specifies supported layouts. Each layout is described in a key-value pair, where the key represents the layout name (will be shown up on Settings app with the app name), and the value describes the detailed information of the layout, including launch path of the layout and supported input types. (See [[#Layout Matching Algorithm]])<br />
** The allowed value in "types" field is a subset of [http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#attr-input-type type attribute of input element]: text, search, tel, number, url, email. Other types will be ignored by FxOS Gaia in the initial version because at this point UI for <select> and <input type=date> (called "value selectors") are not open for 3rd-party implementation.<br />
<br />
=== IME App Manifest Example ===<br />
<br />
1 {<br />
2 "name": "MyKeyboard",<br />
3 "description": "A 3rd Party Keyboard",<br />
4 "role": "keyboard",<br />
5 "launch_path": "/settings.html",<br />
6 "permissions": {<br />
7 "keyboard": {}<br />
8 },<br />
9 "entry_points": {<br />
10 "English": {<br />
11 "launch_path": "/index.html#en",<br />
12 "description": "English layout",<br />
13 "types": ["url", "number"]<br />
14 },<br />
15 "English (Dvorak)": {<br />
16 "launch_path": "/index.html#en-Dvorak",<br />
17 "description": "Dvorak layout",<br />
18 "types": ["text", "url", "number"]<br />
19 },<br />
20 "Spanish": {<br />
21 "launch_path": "/index.html#es",<br />
22 "description": "Spanish layout",<br />
23 "types": ["text", "number"]<br />
24 },<br />
25 "number": {<br />
26 "launch_path": "/index.html#numberLayout",<br />
27 "description": "Number layout",<br />
28 "types": ["number"]<br />
29 }<br />
30 }<br />
31 }<br />
<br />
=== Layout Matching Algorithm ===<br />
<br />
When an input field is focused, if its <code>type</code> attribute is one of the allowed values stated above, it will be used to filter a set of candidate layouts. A candidate layout means it can handle this input type or is possible to let user input all characters that this input field can accept.<br />
For example, if the type of a input is "url", then a layout with "url" or "text" listed in the <code>types</code> of its manifest will be matched. However, if a input field with type "text", then all layouts that support "text" will be matched, but those layouts that only support "url" will not. This is because we believe layouts that can handle "text" could be a fallback for "url" input type, but not vice versa. An input type fallback plan is pre-defined as follows:<br />
<br />
* "text" is the fallback of "textarea", "url", "email", "password", "search", and "contenteditable".<br />
* "number" is the fallback of "number" and "tel".<br />
<br />
The matching algorithm of keyboard manager in System app is as follows:<br />
<br />
# With the given type, find all layouts claims to support the said type and put it into the list.<br />
# Next, if fallback exists for a given type, find layouts claims to support the fallback type and put it into the list. Layouts do not get duplicated listing even if it supports both types.<br />
# Present the user with the choice of the layouts available to handle the input field. The order of presenting list is depend on UX design and/or user preferences in Settings.<br />
<br />
== Proposed API ==<br />
<br />
The input method API is available to web content who intend to implement an input method, or "input source", or "virtual keyboard".<br />
<br />
partial interface Navigator {<br />
readonly attribute InputMethod inputMethod;<br />
};<br />
<br />
interface InputMethod: EventTarget {<br />
// Input Method Manager contain a few global methods expose to apps<br />
readonly attribute InputMethodManager mgmt;<br />
<br />
// Fired when the input context changes, include changes from and to null.<br />
// The new InputContext instance will be available in the event object under |inputcontext| property.<br />
// When it changes to null it means the app (the user of this API) no longer has the control of the original focused input field.<br />
// Note that if the app saves the original context, it might get void; implementation decides when to void the input context.<br />
attribute EventHandler oninputcontextchange;<br />
<br />
// An "input context" is mapped to a text field that the app is allow to mutate.<br />
// this attribute should be null when there is no text field currently focused.<br />
readonly attribute InputContext? inputcontext;<br />
};<br />
<br />
// Manages the list of IMEs, enables/disables IME and switches to an IME.<br />
interface InputMethodManager {<br />
// Ask the OS to show a list of available IMEs for users to switch from.<br />
// OS should ignore this request if the app is currently not the active one.<br />
void <strike>showInputMethodPicker</strike> showAll();<br />
<br />
// Ask the OS to switch away from the current active Keyboard app.<br />
// OS should ignore this request if the app is currently not the active one.<br />
void <strike>switchToNextInputMethod</strike> next();<br />
<br />
// To know if the OS supports IME switching or not.<br />
// Use case: let the keyboard app knows if it is necessary to show the "IME switching"<br />
// (globe) button. We have a use case that when there is only one IME enabled, we<br />
// should not show the globe icon.<br />
boolean supportsSwitching();<br />
<br />
// Ask the OS to hide the current active Keyboard app. (was: |removeFocus()|)<br />
// OS should ignore this request if the app is currently not the active one.<br />
// The OS will void the current input context (if it exists).<br />
// This method belong to |mgmt| because we would like to allow Keyboard to access to<br />
// this method w/o a input context.<br />
void <strike>removeFocus</strike> hide();<br />
};<br />
<br />
// The input context, which consists of attributes and information of current input field.<br />
// It also hosts the methods available to the keyboard app to mutate the input field represented.<br />
// An "input context" gets void when the app is no longer allowed to interact with the text field,<br />
// e.g., the text field does no longer exist, the app is being switched to background, and etc.<br />
// [JJ] I doubt whether we should have 'name', 'type', etc. here. In the manifest we should<br />
// have entry points where the keyboard specifies which view to load when going into a<br />
// certain context. Requiring to do this manually will give extra work.<br />
// The system should guarantee that the right view is rendered based on entry_points in<br />
// in manifest (e.g. navigate keyboard to #text/en, or something, based on manifest.<br />
// [Tim] I don't think they are exclusive. A keyboard app might choose to load the same page with the same hash<br />
// for different types but only to deal with the |type| or |inputmode| difference later.<br />
interface <strike>InputMethodConnection</strike> InputContext: EventTarget {<br />
// The tag name of input field, which is enum of "input", "textarea", or "contenteditable"<br />
// [JS] I think "type" would be better here.<br />
// [JS] This should also be 'readonly', right?<br />
DOMString name;<br />
<br />
// The type of the input field, which is enum of text, number, password, url, search, email, and so on.<br />
// See http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#states-of-the-type-attribute<br />
// [JS] and "inputtype" here.<br />
// [JS] This should also be 'readonly', right?<br />
DOMString type;<br />
<br />
/*<br />
* The inputmode string, representing the input mode.<br />
* See http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#input-modalities:-the-inputmode-attribute<br />
*/<br />
// [JS] This should be 'readonly', right?<br />
DOMString inputmode;<br />
<br />
/*<br />
* The primary language for the input field.<br />
* It is the value of HTMLElement.lang.<br />
* See http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#htmlelement<br />
*/<br />
// [JS] This should be 'readonly', right?<br />
DOMString lang;<br />
<br />
/*<br />
* Get the whole text content of the input field.<br />
*/<br />
Promise<DOMString> getText([optional] offset, [optional] length);<br />
<br />
// The start and stop position of the selection.<br />
// [JS] Shouldn't this be an asynchronous function? I.e. something like<br />
// Promise<...> getSelection();?<br />
readonly attribute long selectionStart;<br />
readonly attribute long selectionEnd;<br />
<br />
/*<br />
* Set the selection range of the the editable text.<br />
* Note: This method cannot be used to move the cursor during composition. Calling this<br />
* method will cancel composition.<br />
* @param start The beginning of the selected text.<br />
* @param length The length of the selected text.<br />
*<br />
* Note that the start position should be less or equal to the end position.<br />
* To move the cursor, set the start and end position to the same value.<br />
*<br />
* [JJ] I think that this method should return the same info as the selectionchange event<br />
* rather than a boolean.<br />
* [yxl] I don't think so. We could get selection range info by checking the attributes of <br />
* selectionStart and selectionEnd.<br />
*/<br />
Promise<boolean> setSelectionRange(long start, long length);<br />
<br />
/* User moves the cursor, or changes the selection with other means. If the text around<br />
* cursor has changed, but the cursor has not been moved, the IME won't get notification.<br />
*<br />
* [JJ] I would merge this with onsurroundingtextchange to have 1 state event.<br />
* in the end, every onselectionchange event will also generate a surrounding<br />
* text change event.<br />
*/<br />
attribute EventHandler onselectionchange;<br />
<br />
/*<br />
* Commit text to current input field and replace text around cursor position. It will clear the current composition.<br />
*<br />
* @param text The string to be replaced with.<br />
* @param offset The offset from the cursor position where replacing starts. Defaults to 0.<br />
* @param length The length of text to replace. Defaults to 0.<br />
*/<br />
Promise<boolean> <strike>commitText</strike> replaceSurroundingText(DOMString text, [optional] long offset, [optional] long length);<br />
<br />
/*<br />
*<br />
* Delete text around the cursor.<br />
* @param offset The offset from the cursor position where deletion starts.<br />
* @param length The length of text to delete.<br />
* TODO: maybe updateSurroundingText(DOMString beforeText, DOMString afterText); ?<br />
* [JJ] Rather do a replaceSurroundingText(long offset, long length, optional DOMString text)<br />
* If text is null or empty, it behaves the same<br />
*/<br />
Promise<boolean> deleteSurroundingText(long offset, long length);<br />
<br />
/*<br />
* Notifies when the text around the cursor is changed, due to either text<br />
* editing or cursor movement. If the cursor has been moved, but the text around has not<br />
* changed, the IME won't get notification.<br />
*<br />
* The event handler function is specified as:<br />
* @param beforeString Text before and including cursor position.<br />
* @param afterString Text after and excluing cursor position.<br />
* function(DOMString beforeText, DOMString afterText) {<br />
* ...<br />
* }<br />
*/<br />
// [JS] Can you describe how the cursor can be moved without the surrounding text<br />
// also changing? Is that really something that can happen?<br />
attribute SurroundingTextChangeEventHandler onsurroundingtextchange;<br />
<br />
/*<br />
* send a character with its key events.<br />
* @param modifiers see http://mxr.mozilla.org/mozilla-central/source/dom/interfaces/base/nsIDOMWindowUtils.idl#206<br />
* @return true if succeeds. Otherwise false if the input context becomes void.<br />
* Alternative: sendKey(KeyboardEvent event), but we will likely waste memory for creating the KeyboardEvent object.<br />
*/<br />
Promise<boolean> sendKey(long keyCode, long charCode, long modifiers);<br />
<br />
/*<br />
* Set current composition. It will start or update composition.<br />
* @param cursor Position in the text of the cursor.<br />
*<br />
* The API implementation should automatically ends the composition<br />
* session (with event and confirm the current composition) if <br />
* endComposition is never called. Same apply when the inputContext is lost<br />
* during a unfinished composition session.<br />
*/<br />
Promise<boolean> setComposition(DOMString text, long cursor);<br />
<br />
/*<br />
* End composition and actually commit the text. (was |commitText(text, offset, length)|)<br />
* Ending the composition with an empty string will not send any text.<br />
* Note that if composition always ends automatically (with the current composition committed) if the composition <br />
* did not explicitly with |endComposition()| but was interrupted with |sendKey()|, |setSelectionRange()|,<br />
* user moving the cursor, or remove the focus, etc.<br />
*<br />
* @param text The text<br />
*/<br />
Promise<boolean> endComposition(DOMString text);<br />
};<br />
<br />
=== Use cases for each of the methods ===<br />
<br />
* For a simple virtual keyboard action (send a character and key events w/ each user action), use <code>sendKey()</code>. TODO: should we allow backspace key to be sent from the method? If not, how do send these non-printable characters and it's effect with key events?<br />
*[yxl] I perfer to allowing non-printable character, such as backspace key, to be sent, if there is no security issue. This<br />
* would give the IME more flexibility.<br />
* For spellcheck, autocomplete etc, use surrounding text methods.<br />
* For cursor moment helper features, use <code>setSelectionRange()</code> and related attributes.<br />
* For Asian IMEs that sends characters and composition along with the composition events, use <code>setComposition()</code> and <code>endComposition()</code>.<br />
<br />
It is important to stick with the given use cases because the web application might need to react with what the user actually do. To test the events currently sent to the web, see http://jsfiddle.net/timdream/YDGgk/ .<br />
<br />
== Examples ==<br />
<br />
The following "snowman filler" Keyboard app will start filling snowman character ("☃") and follow by characters "SNOW" with key events to the input field whenever the user is focus on a input field and switch to the keyboard app.<br />
<br />
If the field is a numeric field, it will fill "1337".<br />
<br />
var timer;<br />
function startTyping(inputContext) {<br />
clearTimeout(timer);<br />
timer = setInterval(function typing() {<br />
/* [JJ] So I think that this code shouldn't be here, because you'll get lots of clutter<br />
* as you'll also have to take languages into account.<br />
* Rather rely on entry points in manifest...<br />
*/<br />
<br />
if (inputContext.inputmode === 'numeric' || inputContext.type === 'number') {<br />
['1', '3', '3', '7'].forEach(function (k) {<br />
// For numbers, keyCode is same as the charCode.<br />
inputContext.sendKey(k.charCodeAt(0), k.charCodeAt(0));<br />
});<br />
} else {<br />
// It's not a good idea to commit text w/o sending events. So we should first send composition events.<br />
inputContext.setComposition('☃');<br />
// end the composition and commit the text.<br />
inputContext.endComposition('☃');<br />
['S', 'N', 'O', 'W'].forEach(function (k) {<br />
// For capital Latin letters, keyCode is same as the charCode.<br />
inputContext.sendKey(k.charCodeAt(0), k.charCodeAt(0));<br />
});<br />
}, 1000);<br />
}<br />
<br />
function stopTyping() {<br />
clearTimeout(timer);<br />
}<br />
<br />
var im = navigator.inputMethod;<br />
<br />
im.addEventListener('inputcontextchange', function contextchanged(evt) {<br />
if (evt.inputcontext) {<br />
// Got a new context, start working with it.<br />
startTyping(evt.inputcontext);<br />
} else {<br />
// The user have removed the focus, we are not allow to type into the text field anymore.<br />
stopTyping();<br />
}<br />
});<br />
<br />
if (im.inputcontext) {<br />
// The webpage here is loaded *after* the user has place the focus on the text field,<br />
// let's start typing now.<br />
startTyping(im.inputcontext);<br />
}<br />
<br />
== Related ==<br />
<br />
Android IME API:<br />
<br />
http://developer.android.com/guide/topics/text/creating-input-method.html#IMEAPI<br />
<br />
iOS Keyboard Management:<br />
<br />
http://developer.apple.com/library/ios/#documentation/StringsTextFonts/Conceptual/TextAndWebiPhoneOS/KeyboardManagement/KeyboardManagement.html#//apple_ref/doc/uid/TP40009542-CH5-SW1<br />
<br />
Chrome Extensions API:<br />
<br />
http://developer.chrome.com/trunk/extensions/input.ime.html</div>Sickinghttps://wiki.mozilla.org/index.php?title=Modules/Core&diff=683106Modules/Core2013-07-22T18:20:06Z<p>Sicking: </p>
<hr />
<div>{{Module<br />
|name=Accessibility<br />
|description=Support for platform accessibility APIs. Accessibility APIs are used by 3rd party software like screen readers, screen magnifiers, and voice dictation software, which need information about document content and UI controls, as well as important events like changes of focus.<br />
|owner=[mailto:surkov.alexander@gmail.com Alexander Surkov]<br />
|peers=[mailto:bolterbugz@gmail.com David Bolter], [mailto:ginn.chen@oracle.com Ginn Chen], [mailto:trev.saunders@gmail.com Trevor Saunders], [mailto:marco.zehe@googlemail.com Marco Zehe] <br />
|group=dev-accessibility<br />
|source_dirs=accessible/<br />
|url=http://www.mozilla.org/access/<br />
|components=Core::Disability Access APIs<br />
}}<br />
<br />
{{Module<br />
|name=Build and Release Tools<br />
|description=Tools related to build and release automation and configuration of release builds.<br />
|owner=[mailto:nrthomas@gmail.com Nick Thomas]<br />
|peers=[mailto:bhearsum@mozilla.com Ben Hearsum], [mailto:ccooper@deadsquid.com Chris Cooper], [mailto:cmp@mozilla.org Chase Phillips], [mailto:mozpreed@sigkill.com John Paul Reed], [mailto:robert@roberthelmer.com Robert Helmer]<br />
|group=dev-builds<br />
|source_dirs=tools/botrunner.py, tools/build-environment/, tools/build/, tools/buildbot-configs/, tools/buildbot/, tools/buildbotcustom/, tools/l10n/, tools/MozBuild/, tools/patcher-configs/, tools/patcher/, tools/release/, tools/tinderbox-configs/, tools/tinderbox/, tools/update-packaging/, browser/config/mozconfigs/, mobile/config/mozconfigs/, xulrunner/config/mozconfigs/<br />
|url=<br />
|components=mozilla.org::Release Engineering, mozilla.org::Release Engineering: Custom Builds<br />
}}<br />
<br />
{{Module<br />
|name=Build Config<br />
|description=The build system for Gecko and several mozilla.org hosted Gecko-based applications.<br />
|owner=[mailto:gps@mozilla.com Gregory Szorc]<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:me@kylehuey.com Kyle Huey], [mailto:mh@glandium.org Mike Hommey], [mailto:wtc@google.com Wan-Teh Chang], [mailto:ted@mielczarek.org Ted Mielczarek]<br />
|group=dev-builds<br />
|source_dirs=build/, config/, python/mozbuild, tools/cross-commit, tools/cvs2hg-import.py, tools/cvsmgmt/, tools/elf-dynstr-gc/, tools/trees.pl, browser/config/mozconfigs/, mobile/config/mozconfigs/, xulrunner/config/mozconfigs/<br />
|url=http://www.mozilla.org/build/<br />
|components=Core::Build Config<br />
}}<br />
<br />
{{Module<br />
|name=Code Analysis and Debugging Tools<br />
|description=Tools for debugging Mozilla code or for analyzing speed, memory use, and other characteristics of it.<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|peers=<br />
|group=dev-performance<br />
|source_dirs=tools/codesighs/, tools/debug/, tools/dreftool/, tools/dumpdeps/, tools/footprint/, tools/jprof/, tools/leaky/, tools/memory/, tools/module-deps/, tools/performance/, tools/post_compile/, tools/preloader/, tools/rb/, tools/reorder/, tools/trace-malloc/, tools/uuiddeps/, <br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Content HTTP Headers<br />
|description=HTTP headers related to content, e.g. User-Agent, Content-Type, Accept. (Transport-related headers are the responsibility of the Necko module owner.)<br />
|owner=[mailto:gerv@mozilla.org Gervase Markham]<br />
|peers=[mailto:lmandel@mozilla.com Lawrence Mandel]<br />
|group=dev-platform<br />
|source_dirs= <br />
|url=https://developer.mozilla.org/en/Gecko_user_agent_string_reference<br />
|components=Core::Networking: HTTP<br />
}}<br />
<br />
{{Module<br />
|name=Cookies and Permissions<br />
|description=<br />
|owner=[mailto:dwitte@gmail.com Dan Witte]<br />
|peers=[mailto:ehsan@mozilla.com Ehsan Akhgari], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:mconnor@steelgryphon.com Mike Connor], [mailto:josh@joshmatthews.com Josh Matthews], [mailto:sdwilsh@shawnwilsher.com Shawn Wilsher (ping on irc)]<br />
|group=dev-tech-network<br />
|source_dirs=extensions/cookie/, netwerk/cookie/<br />
|url=<br />
|components=Core::Networking: Cookies<br />
}}<br />
{{Module<br />
|name=Cycle Collector<br />
|description=Code to break and collect objects within reference cycles<br />
|owner=[mailto:continuation@gmail.com Andrew McCreight]<br />
|peers=Peter Van der Beken, Olli Pettay, David Baron<br />
|source_dirs=xpcom/base/nsCycleCollector.* and some support headers<br />
|components=Core::XPCOM<br />
|group=dev-platform<br />
}}<br />
{{Module<br />
|name=docshell<br />
|description=<br />
|owner=[mailto:bzbarsky@mit.edu Boris Zbarsky]<br />
|peers=[mailto:cbiesinger@gmail.com Christian Biesinger],[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:jst@mozilla.org Johnny Stenback], [mailto:Olli.Pettay@helsinki.fi Olli Pettay], [mailto:justin.lebar@gmail.com Justin Lebar]<br />
|group=dev-tech-layout<br />
|source_dirs=docshell/, uriloader/, webshell/<br />
|url=<br />
|components=Core::Document Navigation<br />
}}<br />
<br />
{{Module<br />
|name=Device Storage<br />
|description=Support for the device storage API<br />
|owner=[mailto:dhylands@mozilla.com Dave Hylands], [mailto:jvarga@mozilla.com Jan Varga]<br />
|peers=[mailto:dougt@dougt.org Doug Turner]<br />
|group=dev-tech-dom<br />
|source_dirs=dom/devicestorage/, dom/interfaces/devicestorage/<br />
|url=https://developer.mozilla.org/en-US/docs/WebAPI/Device_Storage<br />
|components=Core::DOM: Device Interfaces<br />
}}<br />
<br />
{{Module<br />
|name=Document Object Model<br />
|description=<br />
|owner=[mailto:jst@mozilla.org Johnny Stenback], [mailto:peterv@propagandism.org Peter Van der Beken]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:jonas@sicking.cc Jonas Sicking], [mailto:Olli.Pettay@helsinki.fi Olli Pettay], [mailto:bent@mozilla.com Ben Turner], [mailto:mounir.lamouri@mozilla.com Mounir Lamouri], [mailto:khuey@kylehuey.com Kyle Huey], [mailto:justin.lebar@gmail.com Justin Lebar], [mailto:hsivonen@iki.fi Henri Sivonen], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:bobbyholley@gmail.com Bobby Holley]<br />
|group=dev-tech-dom<br />
|source_dirs=content/*, dom/*, except directories covered by other modules<br />
|url=http://developer.mozilla.org/en/docs/DOM<br />
|components=Core::DOM, Core::DOM: CSS Object Model, Core::DOM: Core & HTML, Core::DOM: Events<br />
}}<br />
<br />
{{Module<br />
|name=Web Workers<br />
|description=<br />
|owner=[mailto:bent@mozilla.com Ben Turner]<br />
|peers=[mailto:mrbkap@mozilla.com Blake Kaplan], [mailto:jonas@sicking.cc Jonas Sicking]<br />
|group=dev-platform<br />
|source_dirs=dom/workers/<br />
|url=https://developer.mozilla.org/En/Using_web_workers<br />
|components=Core::DOM: Workers<br />
}}<br />
<br />
<br />
{{Module<br />
|name=IndexedDB<br />
|description=<br />
|owner=[mailto:jonas@sicking.cc Jonas Sicking]<br />
|peers=[mailto:bent@mozilla.com Ben Turner], [mailto:khuey@mozilla.com Kyle Huey], [mailto:jvarga@mozilla.com Jan Varga]<br />
|group=dev-platform<br />
|source_dirs=dom/indexedDB/<br />
|url=https://developer.mozilla.org/en/IndexedDB<br />
|components=Core::DOM: IndexedDB<br />
}}<br />
<br />
{{Module<br />
|name=Editor<br />
|description=<br />
|owner=[mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|peers=<br />
|group=dev-platform<br />
|source_dirs=editor/<br />
|url=http://www.mozilla.org/editor/<br />
|components=Core::Editor<br />
}}<br />
<br />
{{Module<br />
|name=Embedding<br />
|description=<br />
|owner=[mailto:benjamin@smedbergs.us Benjamin Smedberg]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:jst@mozilla.org Johnny Stenback]<br />
|group=dev-embedding<br />
|source_dirs=embedding/<br />
|url=<br />
|components=Core::Embedding: APIs, Core::Embedding: ActiveX Wrapper, Core::Embedding: GRE Core, Core::Embedding: GTK Widget, Core::Embedding: MFC Embed, Core::Embedding: Mac, Core::Embedding: Packaging<br />
}}<br />
<br />
{{Module<br />
|name=Find As You Type<br />
|description=Find As You Type (formerly called Type Ahead Find) is a feature that allows quick web page navigation when you type a succession of characters in the body of the displayed page (not in an edit box of or drop down list). Currently seeks new owner.<br />
|owner=<br />
|peers=<br />
|group=dev-accessibility<br />
|source_dirs=extensions/typeaheadfind/<br />
|url=http://www.mozilla.org/access/type-ahead/<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Geolocation<br />
|description=Implementation of the Geolocation W3C Spec, location provider apis, and wifi scanning code.<br />
|owner=[mailto:dougt@dougt.org Doug Turner]<br />
|peers=[mailto:josh@joshmatthews.net Josh Matthews], [mailto:kchen@mozilla.com Kan-Ru Chen]<br />
|group=dev-tech-dom<br />
|source_dirs=dom/src/geolocation, dom/system/, netwerk/wifi<br />
|url=https://developer.mozilla.org/En/Using_geolocation<br />
|components=Core::Geolocation<br />
}}<br />
<br />
{{Module<br />
|name=Global Key Bindings<br />
|description=Global hot keys in Mozilla for the browser, editor, mail-news and widgets. Does not include underlined menu accelerators and the like, as those are part of i18n.<br />
|owner=[mailto:aaronleventhal@moonset.net Aaron Leventhal]<br />
|peers=[mailto:neil@parkwaycc.co.uk Neil Rashbrook]<br />
|group=dev-accessibility<br />
|source_dirs=content/xbl/builtin/<br />
|url=http://www.mozilla.org/projects/ui/accessibility/mozkeyintro.html<br />
|components=Core::Keyboard: Navigation<br />
}}<br />
<br />
{{Module<br />
|name=Graphics<br />
|description=Mozilla graphics API<br />
|owner=[mailto:jrmuizel@mozilla.com Jeff Muizelaar], [mailto:roc+@cs.cmu.edu Robert O'Callahan]<br />
|peers=[mailto:jdrew@mozilla.com Joe Drew], [mailto:vladimir@pobox.com Vladimir Vukicevic], [mailto:bas.schouten@live.nl Bas Schouten], [mailto:bjacob@mozilla.com Benoit Jacob], [mailto:bgirard@mozilla.com Benoit Girard], [mailto:ajuma.bugzilla@alijuma.com Ali Juma], [mailto:jgilbert@mozilla.com Jeff Gilbert], [mailto:george@mozilla.com George Wright], [mailto:mwoodrow@mozilla.com Matt Woodrow], [mailto:jdaggett@mozilla.com John Daggett], [mailto:jfkthame@googlemail.com Jonathan Kew], [mailto:nsilva@mozilla.com Nicolas Silva], [mailto:ncameron@mozilla.com Nick Cameron]<br />
|group=dev-platform<br />
|source_dirs=gfx/, content/canvas/src/<br />
|url=https://wiki.mozilla.org/Platform/GFX https://wiki.mozilla.org/Gecko:Layers https://wiki.mozilla.org/Gecko:2DGraphicsSketch<br />
|components=Core::Graphics, Core::Graphics: Layers, Core::Graphics: Text, Core::GFX: Color Management, Core::Canvas: 2D, Core::Canvas: WebGL<br />
}}<br />
<br />
{{Module<br />
|name=GTK Embedding Widget<br />
|description=Gtk Widget for embedding Mozilla into Gtk applications<br />
|owner=[mailto:marco@gnome.org Marco Pesenti Gritti]<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:dougt@meer.net Doug Turner]<br />
|group=dev-embedding<br />
|source_dirs=<br />
|url=<br />
|components=Core::Embedding: GTK Widget<br />
}}<br />
<br />
{{Module<br />
|name=Legacy HTML Parser<br />
|description=<br />
|owner=[mailto:mrbkap@gmail.com Blake Kaplan]<br />
|peers=[mailto:dbaron@dbaron.org David Baron], [mailto:jst@mozilla.org Johnny Stenback], [mailto:peterv@propagandism.org Peter Van der Beken], [mailto:rbs@maths.uq.edu.au rbs@maths.uq.edu.au]<br />
|group=dev-tech-dom<br />
|source_dirs=parser/htmlparser<br />
|url=http://www.mozilla.org/newlayout/doc/parser.html<br />
|components=Core::HTML: Parser<br />
}}<br />
<br />
{{Module<br />
|name=HAL<br />
|description=Hardware Abstraction Layer<br />
|owner=[mailto:cjones@mozilla.com Chris Jones]<br />
|peers=[mailto:mounir@lamouri.fr Mounir Lamouri], [mailto:jlebar@mozilla.com Justin Lebar]<br />
|group=dev-platform<br />
|source_dirs=hal/<br />
|components=Core::Hardware Abstraction Layer (HAL)<br />
}}<br />
<br />
{{Module<br />
|name=HTML Parser<br />
|description=The HTML Parser transforms HTML source code into a DOM. It conforms to the HTML specification, and is mostly translated automatically from Java to C++.<br />
|owner=[mailto:hsivonen@iki.fi Henri Sivonen]<br />
|peers=<br />
|group=dev-tech-dom<br />
|source_dirs=parser/html<br />
|url=http://about.validator.nu/<br />
|components=Core::HTML: Parser<br />
}}<br />
<br />
{{Module<br />
|name=I18N Library<br />
|description=<br />
|owner=[mailto:jshin1987@gmail.com Jungshik Shin], [mailto:smontagu@smontagu.org Simon Montagu]<br />
|peers=[mailto:VYV03354@nifty.ne.jp Masatoshi Kimura]<br />
|group=dev-i18n<br />
|source_dirs=intl/<br />
|url=http://mozilla.org/projects/intl/index.html<br />
|components=Core::Internationalization<br />
}}<br />
<br />
{{Module<br />
|name=ImageLib<br />
|description=<br />
|owner=[mailto:joe@drew.ca Joe Drew]<br />
|peers=[mailto:netzen@gmail.com Brian Bondy], [mailto:jmuizelaar@mozilla.com Jeff Muizelaar], [mailto:jlebar@mozilla.com Justin Lebar]<br />
|group=dev-platform<br />
|source_dirs=media/libjpeg/, media/libpng/, image/, modules/zlib/<br />
|url=<br />
|components=Core::ImageLib<br />
}}<br />
<br />
{{Module<br />
|name=IPC<br />
|description=Message-passing between threads and processes<br />
|owner=[mailto:cjones@mozilla.com Chris Jones]<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:bent.mozilla@gmail.com Ben Turner]<br />
|group=dev-platform<br />
|source_dirs=ipc/glue/, ipc/ipdl/, ipc/chromium/<br />
|url=<br />
|components=Core::IPC}}<br />
<br />
{{Module<br />
|name=Java APIs for DOM<br />
|description=APIs for Java access to the Document Object Model<br />
|owner=[mailto:ashuk@eng.sun.com Ashutosh Kulkarni]<br />
|peers=<br />
|group=dev-tech-dom,dev-tech-java<br />
|source_dirs=java/dom/<br />
|url=http://www.mozilla.org/projects/blackwood/dom/<br />
|components=Core::Java APIs for DOM<br />
}}<br />
<br />
{{Module<br />
|name=Java APIs to WebShell<br />
|description=<br />
|owner=[mailto:edburns@acm.org Ed Burns]<br />
|peers=[mailto:ashuk@eng.sun.com Ashutosh Kulkarni]<br />
|group=dev-tech-java,dev-embedding<br />
|source_dirs=java/webclient/<br />
|url=http://www.mozilla.org/projects/blackwood/webclient/<br />
|components=Core::Java APIs to WebShell<br />
}}<br />
<br />
{{Module<br />
|name=Java Stubs<br />
|description=OJI<br />
|owner=[mailto:alfred.peng@sun.com Alfred Peng]<br />
|peers=[mailto:Xiaobin.Lu@eng.Sun.com Xiaobin Lu]<br />
|group=dev-tech-java<br />
|source_dirs=modules/oji/, nav-java/, sun-java/<br />
|url=http://www.mozilla.org/oji/<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Java to XPCOM Bridge<br />
|description=<br />
|owner=[mailto:pedemont@us.ibm.com Javier Pedemont]<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg]<br />
|group=dev-tech-xpcom,dev-tech-java<br />
|source_dirs=extensions/java<br />
|url=http://www.mozilla.org/projects/blackwood/connect/<br />
|components=Core::Java to XPCOM Bridge<br />
}}<br />
<br />
{{Module<br />
|name=Java Utility Classes<br />
|description=assert, debug, utilities, etc.<br />
|owner=[mailto:edburns@acm.org Ed Burns]<br />
|peers=[mailto:ashuk@eng.sun.com Ashutosh Kulkarni]<br />
|group=dev-tech-java<br />
|source_dirs=java/util/<br />
|url=http://www.mozilla.org/projects/blackwood/java-util/<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Java-Implemented Plugins<br />
|description=Infrastructure for writing MIME content-handlers<br />
in Java.<br />
|owner=[mailto:idk@eng.sun.com Igor Kushnirskiy]<br />
|peers=<br />
|group=dev-tech-java<br />
|source_dirs=java/plugins/<br />
|url=http://www.mozilla.org/projects/blackwood/java-plugins/<br />
|components=Core::Java-Implemented Plugins<br />
}}<br />
<br />
{{Module<br />
|name=JavaScript<br />
|description=JavaScript Engine in C++ (SpiderMonkey)<br />
|owner=[mailto:lwagner@mozilla.com Luke Wagner]<br />
|peers=[mailto:danderson@mozilla.com David Anderson], [mailto:igor@mir2.org Igor Bukanov], [mailto:brendan@mozilla.org Brendan Eich], [mailto:gal@mozilla.com Andreas Gal], [mailto:wmccloskey@mozilla.com Bill McCloskey], [mailto:nnethercote@mozilla.com Nick Nethercote], [mailto:jorendorff@mozilla.com Jason Orendorff], [mailto:jwalden@mit.edu Jeff Walden], [mailto:ejpbruel@mozilla.com Eddy Bruel] for proxies, [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:jdemooij@mozilla.com Jan de Mooij], [mailto:hv1989@gmail.com Hannes Verschore], [mailto:kvijayan@mozilla.com Kannan Vijayan], [mailto:nmatsakis@mozilla.com Niko Matsakis], [mailto:shu@mozilla.com Shu-yu Guo], [mailto:evilpies@gmail.com Tom Schuster], [mailto:bhackett1024@gmail.com Brian Hackett]<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/src/, js/src/config/, js/src/editline/, js/src/fdlibm/<br />
|url=http://www.mozilla.org/js/spidermonkey,<br />
http://developer.mozilla.org/en/docs/About_JavaScript<br />
|components=Core::JavaScript Engine<br />
}}<br />
<br />
{{Module<br />
|name=JavaScript Debugger Backend<br />
|description=JavaScript debugging hooks<br />
|owner=[mailto:timeless@mozdev.org Josh 'timeless' Soref]<br />
|peers=[mailto:brendan@mozilla.org Brendan Eich], [mailto:rginda@hacksrus.com Rob Ginda]<br />
|group=dev-apps-js-debugger<br />
|source_dirs=js/jsd/<br />
|url=http://www.mozilla.org/js/jsd<br />
|components=Other Applications::Venkman JS Debugger<br />
}}<br />
<br />
{{Module<br />
|name=js-ctypes<br />
|description=A foreign function interface which allows privileged JS code to interact with binary code without using XPCOM/XPConnect.<br />
|owner=[mailto:jorendorff@mozilla.com Jason Orendorff]<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:bobbyholley@gmail.com Bobby Holley]<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/src/ctypes/<br />
|url=https://wiki.mozilla.org/JSctypes<br />
|components=Core::js-ctypes<br />
}}<br />
<br />
{{Module<br />
|name=js-tests<br />
|description=JavaScript test suite<br />
|owner=[mailto:bclary@bclary.com Bob Clary]<br />
|peers=<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/tests/<br />
|url=http://www.mozilla.org/js/tests/library.html<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Layout Engine<br />
|description=rendering tree construction, layout (reflow), painting, etc.<br />
|owner=[mailto:roc+@cs.cmu.edu Robert O'Callahan]<br />
|peers=[mailto:bmlk@gmx.de Bernd Mielke], [mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:dbaron@dbaron.org David Baron], [mailto:smontagu@smontagu.org Simon Montagu]<br />
|group=dev-tech-layout<br />
|source_dirs=layout/%, layout/base/, layout/build/, layout/doc/, layout/forms/, layout/generic/, layout/html/, layout/macbuild/, layout/printing/, layout/tables/, layout/tools/<br />
|url=http://mozilla.org/newlayout/doc/ ,<br />
http://lxr.mozilla.org/mozilla/source/layout/doc/<br />
|components=Core::Layout, Core::Layout: Block and Inline, Core::Layout: Floats, Core::Layout: Form Controls, Core::Layout: HTML Frames, Core::Layout: Images, Core::Layout: Misc Code, Core::Layout: R & A Pos, Core::Layout: Tables, Core::Layout: Text, Core::Layout: View Rendering<br />
}}<br />
<br />
{{Module<br />
|name=libjar<br />
|description=The JAR handling code (protocol handler, stream implementation, and zipreader/zipwriter).<br />
|owner=[mailto:tglek@mozilla.com Taras Glek]<br />
|peers=[mailto:mwu@mozilla.com Michael Wu]<br />
|group=dev-platform<br />
|source_dirs=modules/libjar<br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=MathML<br />
|description=MathML is a low-level specification for describing mathematics which provides a foundation for the inclusion of mathematical expressions in Web pages.<br />
|owner=[mailto:karlt+@karlt.net Karl Tomlinson]<br />
|peers=[mailto:roc+@cs.cmu.edu Robert O'Callahan]<br />
|group=dev-tech-mathml<br />
|source_dirs=layout/mathml/<br />
|url=http://www.mozilla.org/projects/mathml/<br />
|components=Core::MathML<br />
}}<br />
<br />
{{Module<br />
|name=mfbt<br />
|description=mfbt is a collection of headers, macros, data structures, methods, and other functionality available for use and reuse throughout all Mozilla code (including SpiderMonkey and Gecko more broadly).<br />
|owner=[mailto:jwalden@mit.edu Jeff Walden]<br />
|peers=<br />
|group=dev-platform<br />
|source_dirs=mfbt/<br />
|url=<br />
|components=Core::MFBT<br />
}}<br />
<br />
{{Module<br />
|name=mozilla-toplevel<br />
|description=The top level directory for the mozilla tree.<br />
|owner=[mailto:brendan@mozilla.org Brendan Eich]<br />
|peers=<br />
|group=<br />
|source_dirs=tools/README<br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Necko<br />
|description=The Mozilla Networking Library<br />
|owner=[mailto:pmcmanus@mozilla.com Patrick McManus]<br />
|peers=[mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:jduell.mcbugs@gmail.com Jason Duell], [mailto:honzab.moz@firemni.cz Honza Bambas], [mailto:bsmith@mozilla.com Brian Smith], [mailto:mnovotny@mozilla.com Michal Novotny]<br />
|group=dev-tech-network<br />
|source_dirs=netwerk/%, netwerk/base/, netwerk/build/, netwerk/cache/, netwerk/dns/, netwerk/locales/, netwerk/mime/, netwerk/protocol/, netwerk/resources/, netwerk/socket/, netwerk/streamconv/, netwerk/system/, netwerk/test/, netwerk/testserver/<br />
|url=http://www.mozilla.org/projects/netlib/, https://developer.mozilla.org/en/Necko<br />
|components=Core::Networking, Core::Networking: Cache, Core::Networking: Cookies, Core::Networking: FTP, Core::Networking: File, Core::Networking: HTTP, Core::Networking: JAR, Core::Networking: Websockets<br />
}}<br />
<br />
{{Module<br />
|name=NSPR<br />
|description=Netscape Portable Runtime<br />
|owner=[mailto:nelson@bolyard.com Nelson Bolyard], [mailto:wtc@google.com Wan-Teh Chang]<br />
|peers=[mailto:ted.mielczarek@gmail.com Ted Mielczarek]<br />
|group=dev-tech-nspr<br />
|source_dirs=nsprpub/<br />
|url=http://www.mozilla.org/projects/nspr/<br />
http://www.mozilla.org/projects/nspr/reference/html/<br />
http://www.mozilla.org/projects/nspr/release-notes/<br />
|components=NSPR<br />
}}<br />
<br />
{{Module<br />
|name=PDF<br />
|description=Rendering code to display documents encoded in the ISO 32000-1 `PDF' format.<br />
|owner=[mailto:cjones@mozilla.com Chris Jones], [mailto:gal@mozilla.com Andreas Gal]<br />
|peers=[mailto:aadib@mozilla.com Artur Adib], [mailto:bdahl@mozilla.com Brendan Dahl], [mailto:vnicolas@mozilla.com Vivien Nicolas]<br />
|group=dev-platform<br />
|source_dirs=media/pdf/<br />
|url=https://github.com/mozilla/pdf.js<br />
|components=Core::PDF<br />
}}<br />
<br />
{{Module<br />
|name=Plugins<br />
|description= NPAPI Plugin support.<br />
|owner=[mailto:joshmoz@gmail.com Josh Aas]<br />
|peers=[mailto:jst@mozilla.org Johnny Stenback], [mailto:roc+@cs.cmu.edu Robert O'Callahan], [mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:jmathies@mozilla.com Jim Mathies], [mailto:jschoenick@mozilla.com John Schoenick]<br />
|group=<br />
|source_dirs=dom/plugins/, modules/plugin/<br />
|url=https://wiki.mozilla.org/Plugins<br />
|components=Core::Java-Implemented Plugins, Core::Plug-ins<br />
}}<br />
<br />
{{Module<br />
|name=Preferences<br />
|description=Preference library<br />
|owner=[mailto:dwitte@mozilla.com Dan Witte]<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg]<br />
|group=dev-platform<br />
|source_dirs=modules/libpref/<br />
|url=<br />
|components=Core::Preferences: Backend<br />
}}<br />
<br />
{{Module<br />
|name=Privilege Manager<br />
|description="caps"<br />
|owner=<br />
|peers=[mailto:brendan@mozilla.org Brendan Eich], [mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:dveditz@cruzio.com Dan Veditz], [mailto:jst@mozilla.org Johnny Stenback]<br />
|group=dev-tech-dom<br />
|source_dirs=caps/<br />
|url=http://www.mozilla.org/projects/security/components/index.html<br />
|components=Core::Security: CAPS<br />
}}<br />
<br />
{{Module<br />
|name=Push Notifications<br />
|description=Push is a way for application developers to send messages to their web applications.<br />
|owner=[mailto:doug.turner@gmail.com Doug Turner]<br />
|peers=[mailto:nsm.nikhil@gmail.com Nikhil Marathe], [mailto:justin.lebar@gmail.com Justin Lebar]<br />
|group=<br />
|source_dirs=dom/push<br />
|url=https://wiki.mozilla.org/WebAPI/SimplePush<br />
|components=<br />
}}<br />
<br />
<br />
{{Module<br />
|name=PyXPCOM<br />
|description=The Python to XPCOM bridge.<br />
|owner=[mailto:toddw@activestate.com Todd Whiteman]<br />
|peers=[mailto:mhammond@skippinet.com.au Mark Hammond]<br />
|group=<br />
|source_dirs=extension/python<br />
|url=https://developer.mozilla.org/en/PyXPCOM<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Qt-based gfx and widget<br />
|description=Qt-based rendering and widget code<br />
|owner=[mailto:romaxa@gmail.com Oleg Romashin]<br />
|peers=[mailto:mozilla@rosenauer.org Wolfgang Rosenauer], [mailto:doug.turner@gmail.com Doug Turner]<br />
|group=dev-tech-widget<br />
|source_dirs=widget/qt/<br />
|url=<br />
|components=Core::Widget: Qt<br />
}}<br />
<br />
{{Module<br />
|name=RDF<br />
|description=<br />
|owner=[mailto:axel@pike.org Axel Hecht]<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg]<br />
|group=dev-tech-rdf<br />
|source_dirs=rdf/<br />
|url=http://www.mozilla.org/rdf/doc/<br />
|components=Core::RDF<br />
}}<br />
<br />
{{Module<br />
|name=security<br />
|description=Crypto/PKI code, including NSS (Network Security Services) and JSS (NSS for Java)<br />
|owner=[mailto:rrelyea@redhat.com Bob Relyea], [mailto:wtc@google.com Wan-Teh Chang]<br />
|peers=[mailto:emaldona@redhat.com Elio Maldonado], [mailto:bsmith@mozilla.com Brian Smith], [mailto:kaie@kuix.de Kai Engert], [mailto:ryan.sleevi@gmail.com Ryan Sleevi]<br />
|group=dev-tech-crypto<br />
|source_dirs=dbm/, security/coreconf/, security/dbm/, security/jss/, security/nss/, security/tinderbox/, security/tinderlight/<br />
|url=http://mozilla.org/projects/security/pki/<br />
|components=NSS, JSS, Core::Security, Core::Security: S/MIME<br />
}}<br />
<br />
{{Module<br />
|name=Security - Mozilla PSM Glue<br />
|description=Personal Security Manager<br />
|owner=[mailto:bsmith@mozilla.com Brian Smith]<br />
|peers=[mailto:kaie@kuix.de Kai Engert], [mailto:honzab.moz@firemni.cz Honza Bambas], [mailto:rrelyea@redhat.com Bob Relyea], [mailto:wtc@google.com Wan-Teh Chang]<br />
|group=dev-tech-crypto<br />
|source_dirs=security/manager/<br />
|url=<br />
|components=Core::Security: PSM, Core::Security: UI<br />
}}<br />
<br />
{{Module<br />
|name=storage<br />
|description=Storage APIs with a SQLite backend<br />
|owner=[mailto:mak77@bonardo.net Marco Bonardo]<br />
|peers=[mailto:bugmail@asutherland.org Andrew Sutherland], [mailto:bent.mozillla@gmail.com Ben Turner]<br />
|group=dev-platform<br />
|source_dirs=db/sqlite3/, storage/<br />
|url=http://developer.mozilla.org/en/docs/Storage<br />
|components=Toolkit::Storage, Core::SQL<br />
}}<br />
<br />
{{Module<br />
|name=String<br />
|description=<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:jlebar@mozilla.com Justin Lebar]<br />
|group=dev-tech-xpcom<br />
|source_dirs=string/, xpcom/string/<br />
|url=https://developer.mozilla.org/En/Mozilla_internal_string_guide<br />
|components=Core::String<br />
}}<br />
<br />
{{Module<br />
|name=Style System<br />
|description=CSS style sheet handling; style data computation<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky]<br />
|group=dev-tech-layout<br />
|source_dirs=layout/style/<br />
|url=https://wiki.mozilla.org/Gecko:Overview#Style_System<br />
|components=Core::CSS Parsing and Computation<br />
}}<br />
<br />
{{Module<br />
|name=SVG<br />
|description=Scalable Vector Graphics<br />
|owner=[mailto:jwatt@jwatt.org Jonathan Watt]<br />
|peers=[mailto:longsonr@gmail.com Robert Longson], [mailto:roc+@cs.cmu.edu Robert O'Callahan], [mailto:dholbert@mozilla.com Daniel Holbert]<br />
|group=dev-tech-svg<br />
|source_dirs=content/svg/, layout/svg/<br />
|url=http://www.mozilla.org/projects/svg/<br />
|components=Core::SVG<br />
}}<br />
<br />
{{Module<br />
|name=Tamarin<br />
|description=VM for ActionScript and JavaScript<br />
|owner=[mailto:edwsmith@adobe.com Edwin Smith], [mailto:jodyer@adobe.com Jeff Dyer]<br />
|peers=[mailto:brendan@mozilla.org Brendan Eich], [mailto:stejohns@adobe.com Steven Johnson], [mailto:tierney@adobe.com Erik Tierney], [mailto:treilly@adobe.com Tom Reilly]<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/tamarin<br />
|url=http://www.mozilla.org/projects/tamarin/<br />
http://wiki.mozilla.org/tamarin/<br />
http://hg.mozilla.org/tamarin-central/<br />
http://hg.mozilla.org/tamarin-tracing/<br />
|components=Tamarin<br />
}}<br />
<br />
{{Module<br />
|name=Test Harness<br />
|description=In-tree test infrastructure and tools. Harnesses include, XPCShell, Mochitest (& Chrome), Reftest, JsREftest, Compiled Code Tests, Robocop, Mozmill and Marionette. Requests for new harnesses should go to Testing::General.<br />
|owner=[mailto:ted@mozilla.com Ted Mielczarek]<br />
|peers=[mailto:dbaron@dbaron.org David Baron] (reftest), [mailto:jwalden@mit.edu Jeff Walden] (httpd.js, jsreftest), [mailto:rcampbell@mozilla.com Rob Campbell] (mochitest, mochitest chrome, marionette), [mailto:jmaher@mozilla.com Joel Maher] (reftest, mochitest, jsreftest), [mailto:ctalbert@mozilla.com Clint Talbert] (reftest, compiled code, mozmill), [mailto:geoffbrown@mozilla.com Geoff Brown] (robocop), [mailto:hskupin@mozilla.com Henrik Skupin] (mozmill), [mailto:mdas@mozilla.com Malini Das] (marionette), [mailto:jgriffin Jonathan Griffin] (marionette), [mailto:jhammel@mozilla.com Jeffrey Hammel] (mozmill)<br />
|group=dev-quality<br />
|source_dirs=/testing<br />
|url=http://wiki.mozilla.org/SoftwareTesting<br />
|components=Testing::General, Testing::Mochitest, Testing::Mochitest Chrome, Testing::Marionette, Testing::Mozmill, Testing::Reftest, Testing::XPCShell Harness, Testing::httpd.js<br />
}}<br />
<br />
{{Module<br />
|name=Testing Infrastructure<br />
|description=Testing tools and infrastructure for Mozilla projects, harnesses for automated tests, stand-alone test tools. Talos, Graph Server, Mozbase, Pulse, WOO, Bughunter, SUTAgent, Eideticker<br />
|owner=[mailto:ctalbert@mozilla.com Clint Talbert]<br />
|peers=[mailto:bclary@bclary.com Bob Clary], [mailto:bhearsum@mozilla.com Ben Hearsum], [mailto:ccooper@deadsquid.com Chris Cooper], [mailto:ctalbert@mozilla.com Clint Talbert], [mailto:robert@roberthelmer.com Robert Helmer], [mailto:jmaher@mozilla.com Joel Maher], [mailto:rcampbell@mozilla.com Rob Campbell], [mailto:jhammel@mozilla.com Jeffrey Hammel], [mailto:wlach@mozilla.com William Lachance], [mailto:jeads@mozilla.com Jonathan Eads], [mailto:jgriffin Jonathan Griffin], [mailto:bmoss@mozilla.com Bob Moss], [mailto:mcote@mozilla.com Mark Côté]<br />
|group=dev-quality<br />
|source_dirs=testing/, tools/httptester/, tools/page-loader/, tools/test-harness/, tools/tests/, tools/testserver/, tools/testy/<br />
|url=http://wiki.mozilla.org/SoftwareTesting<br />
|components=Testing::Infrastructure<br />
}}<br />
<br />
{{Module<br />
|name=XPCShell Test Harness<br />
|description=The XPCShell Harness<br />
|owner=[mailto:ted.mielczarek@gmail.com Ted Mielczarek]<br />
|peers=[mailto:jmaher@mozilla.com Joel Maher]<br />
|source_dirs=testing/xpcshell<br />
|components=Testing::XPCShell Harness<br />
}}<br />
<br />
{{Module<br />
|name=Update Service<br />
|description=server code for Mozilla Update services (aus, addons, pfs)<br />
|owner=[mailto:morgamic@mozilla.com Mike Morgan]<br />
|peers=[mailto:jscott@mozilla.com Justin Scott], [mailto:shaver@mozilla.org Mike Shaver], [mailto:wclouser@mozilla.com Will Clouser]<br />
|group=dev-amo<br />
|source_dirs=webtools/addons/, webtools/aus/, webtools/update/<br />
|url=http://wiki.mozilla.org/wiki/AMO<br />
|components=AUS::Administration, AUS::Systems<br />
}}<br />
<br />
{{Module<br />
|name=View System<br />
|description=The View Manager is responsible for handling "heavyweight" rendering (some clipping, compositing) and event handling tasks.<br />
|owner=[mailto:roc+@cs.cmu.edu Robert O'Callahan]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:dbaron@dbaron.org David Baron]<br />
|group=dev-tech-layout<br />
|source_dirs=view/<br />
|url=<br />
|components=Core::Layout: View Rendering<br />
}}<br />
<br />
{{Module<br />
|name=Web Audio<br />
|description=Support for the W3C Web Audio API specification.<br />
|owner=[mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|peers=[mailto:roc+@cs.cmu.edu Robert O'Callahan], [mailto:padenot@mozilla.com Paul Adenot]<br />
|group=dev-platform<br />
|source_dirs=content/media/webaudio<br />
|url=https://wiki.mozilla.org/Web_Audio_API<br />
|components=Core::Web Audio<br />
}}<br />
<br />
{{Module<br />
|name=WebRTC<br />
|description=WebRTC is responsible for realtime audio and video communication, as well as related issues like low-level camera and microphone access (on desktop at least)<br />
|owner=[mailto:rjesup@mozilla.com Randell Jesup]<br />
|peers=[mailto:roc+@cs.cmu.edu Robert O'Callahan], [mailto:tterriberry@mozilla.com Tim Terriberry], [mailto:anant@mozilla.com Anant Narayanan]<br />
|group=dev-media<br />
|source_dirs=media/webrtc<br />
|url=https://wiki.mozilla.org/Media/webrtc<br />
|components=Core::WebRTC, Core::WebRTC (Audio/Video), Core::WebRTC (Networking), Core::WebRTC (Signaling)<br />
}}<br />
<br />
{{Module<br />
|name=Widget<br />
|description=<br />
|owner=[mailto:roc+@cs.cmu.edu Robert O'Callahan]<br />
|peers=[mailto:pavlov@pavlov.net Stuart Parmenter], [mailto:vladimir@pobox.com Vladimir Vukicevic]<br />
|group=dev-platform<br />
|source_dirs=widget/%, widget/public/, widget/%, widget/xpwidgets/<br />
|url=<br />
|components=Core::Drag and Drop, Core::Widget<br />
}}<br />
<br />
{{Module<br />
|name=Widget - Android<br />
|description=The Android Port<br />
|owner=[mailto:blassey.bugs@lassey.us Brad Lassey]<br />
|peers=[mailto:vladimir@mozilla.com Vladimir Vukicevic], [mailto:dougt@dougt.org Doug Turner], [mailto:mwu@mozilla.com Michael Wu]<br />
|group=dev-platform<br />
|source_dirs=widget/android/, embedding/android<br />
|url=<br />
|components=Core::Widget: Android<br />
}}<br />
<br />
{{Module<br />
|name=Widget - GTK<br />
|description=supported X widgetry and gfx<br />
|owner=[mailto:roc+@cs.cmu.edu Robert O'Callahan]<br />
|peers=[mailto:karlt+@karlt.net Karl Tomlinson]<br />
|group=dev-platform<br />
|source_dirs=widget/gtk/, widget/gtk2/, widget/gtksuperwin/, widget/gtkxtbin/<br />
|url=http://www.mozilla.org/unix/, http://www.gtk.org, http://www.mozilla.org/ports/gtk/<br />
|components=Core::Widget: Gtk<br />
}}<br />
<br />
{{Module<br />
|name=Widget - Mac OS X<br />
|description= Gecko's Mac OS X compatibility layer.<br />
|owner=[mailto:joshmoz@gmail.com Josh Aas]<br />
|peers=[mailto:mstange@themasta.com Markus Stange], [mailto:smichaud@pobox.com Steven Michaud], [mailto:bgirard@mozilla.com Benoit Girard], [mailto:spohl@mozilla.com Stephen Pohl]<br />
|group=dev-platform<br />
|source_dirs=widget/cocoa/<br />
|url=<br />
|components=Core::Widget: Cocoa<br />
}}<br />
<br />
{{Module<br />
|name=Widget - Windows<br />
|description=Windows widgets and desktop integration<br />
|owner=[mailto:jmathies@mozilla.com Jim Mathies]<br />
|peers=[mailto:blassey@mozilla.com Brad Lassey], [mailto:netzen@gmail.com Brian Bondy], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:dougt@meer.net Doug Turner], [mailto:neil@parkwaycc.co.uk Neil Rashbrook], [mailto:robarnold@cmu.edu Rob Arnold], [mailto:timeless@mozdev.org Josh 'timeless' Soref], [mailto:vladimir@pobox.com Vladimir Vukicevic]<br />
|group=dev-platform<br />
|source_dirs=widget/windows/<br />
|url=<br />
|components=Core::Widget: Win32<br />
}}<br />
<br />
{{Module<br />
|name=XBL<br />
|description=eXtensible Binding Language<br />
|owner=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:jonas@sicking.cc Jonas Sicking]<br />
|peers=[mailto:mrbkap@gmail.com Blake Kaplan]<br />
|group=dev-tech-xbl<br />
|source_dirs=content/xbl/%, content/xbl/public/, content/xbl/src/<br />
|url=http://www.mozilla.org/projects/xbl/<br />
|components=Core::XBL<br />
}}<br />
<br />
{{Module<br />
|name=XML<br />
|description=XML in Mozilla, including XML, XHTML, Namespaces in XML, Associating Style Sheets with XML Documents, XML Linking and XML Extras. XML-related things that are not covered by more specific projects.<br />
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:jonas@sicking.cc Jonas Sicking], [mailto:jst@mozilla.org Johnny Stenback]<br />
|group=dev-tech-xml<br />
|source_dirs=content/xml/, extensions/xmlextras/, parser/expat/<br />
|url=http://www.mozilla.org/newlayout/xml/<br />
|components=Core::XML<br />
}}<br />
<br />
{{Module<br />
|name=XPApps<br />
|description=Cross-Platform Applications, mostly Navigator front end and application shell.<br />
|owner=[mailto:neil@parkwaycc.co.uk Neil Rashbrook]<br />
|peers=[mailto:dean_tessman@hotmail.com Dean Tessman], [mailto:jag@tty.nl Peter Annema], [mailto:timeless@mozdev.org Josh 'timeless' Soref]<br />
|group=dev-apps-seamonkey<br />
|source_dirs=xpfe/<br />
|url=http://www.mozilla.org/xpapps/<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=XPCOM<br />
|description=The cross-platform object model and core data structures.<br />
|owner=[mailto:benjamin@smedbergs.us Benjamin Smedberg]<br />
|peers=[mailto:dougt@meer.net Doug Turner], [mailto:jlebar@mozilla.com Justin Lebar]<br />
|group=dev-platform<br />
|source_dirs=startupcache/, tools/wizards/, xpcom/%, xpcom/base/, xpcom/build/, xpcom/components/, xpcom/ds/, xpcom/glue/, xpcom/proxy/, xpcom/sample/, xpcom/stub/, xpcom/tests/, xpcom/threads/, xpcom/tools/, xpcom/windbgdlg/<br />
|url=http://developer.mozilla.org/en/XPCOM<br />
|components=Core::XPCOM<br />
}}<br />
<br />
{{Module<br />
|name=XPConnect<br />
|description=Deep Magic<br />
|owner=[mailto:bobbyholley@gmail.com Bobby Holley]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:gal@uci.edu Andreas Gal], [mailto:jst@mozilla.org Johnny Stenback], [mailto:peterv@propagandism.org Peter Van der Beken], [mailto:mrbkap@gmail.com Blake Kaplan]<br />
|group=<br />
|source_dirs=js/xpconnect/<br />
|url=<br />
|components=Core::XPConnect<br />
}}<br />
<br />
{{Module<br />
|name=XPIDL<br />
|description=Cross-platform IDL compiler; produces .h C++ header files and .xpt runtime type description files from .idl interface description files. Also produces .java interface files, as part of an experimental java<->xpcom connection layer.<br />
|owner=[mailto:BradleyJunk@cinci.rr.com BradleyJunk@cinci.rr.com]<br />
|peers=[mailto:jband@netscape.com(disabled) jband@netscape.com(disabled)], [mailto:shaver@mozilla.org Mike Shaver], [mailto:timeless@mozdev.org Josh 'timeless' Soref]<br />
|group=dev-tech-xpcom<br />
|source_dirs=xpcom/typelib/<br />
|url=http://www.mozilla.org/scriptable/xpidl<br />
http://www.mozilla.org/scriptable<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=XPInstall<br />
|description=<br />
|owner=[mailto:dveditz@cruzio.com Dan Veditz]<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg]<br />
|group=dev-tech-xpinstall<br />
|source_dirs=xpinstall/<br />
|url=<br />
|components=Core::Installer: XPInstall Engine<br />
}}<br />
<br />
{{Module<br />
|name=xptcall<br />
|description=XPTCall - platform-specific assembly for calling and implementing arbitrary XPCOM interfaces.<br />
|owner=[mailto:timeless@mozdev.org Josh 'timeless' Soref]<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:shaver@mozilla.org Mike Shaver]<br />
|group=dev-xpcom<br />
|source_dirs=xpcom/reflect/xptcall/<br />
|url=http://www.mozilla.org/scriptable/xptcall-faq.html<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=XPToolkit<br />
|description=Cross-platform user interface toolkit<br />
|owner=<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:hyatt@mozilla.org Dave Hyatt], [mailto:jag@tty.nl Peter Annema], [mailto:Jan.Varga@gmail.com Jan Varga]<br />
|group=dev-tech-xul<br />
|source_dirs=content/xul/, layout/xul/<br />
|url=http://www.mozilla.org/xpfe/<br />
|components=Core::XP Toolkit/Widgets: Menus, Core::XP Toolkit/Widgets: XUL<br />
}}<br />
<br />
{{Module<br />
|name=XSLT Processor<br />
|description=XSLT transformations processor<br />
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]<br />
|peers=[mailto:axel@pike.org Axel Hecht], [mailto:jonas@sicking.cc Jonas Sicking]<br />
|group=dev-tech-xslt<br />
|source_dirs=content/xslt/<br />
|url=http://www.mozilla.org/projects/xslt/, http://www.w3.org/TR/xslt.html<br />
|components=Core::XSLT<br />
}}<br />
<br />
{{Module<br />
|name=XTF<br />
|description=eXtensible Tag Framework<br />
|owner=<br />
|peers=[mailto:alex@croczilla.com alex@croczilla.com], [mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:jonas@sicking.cc Jonas Sicking]<br />
|group=dev-tech-xbl<br />
|source_dirs=content/xtf/, layout/xtf/<br />
|url=http://www.croczilla.com/bits_and_pieces/xtf/<br />
|components=Core::XTF<br />
}}<br />
<br />
===Submodules===<br />
{{Module<br />
|name=Build Config - moz.build Data Migration<br />
|description=Temporary submodule that covers just the data conversion aspects of the transition from Makefile.in to moz.build files. This does not cover establishing new symbols in the moz.build execution sandbox. This module will cease to exist once the moz.build migration is complete.<br />
|owner=[mailto:gps@mozilla.com Gregory Szorc]<br />
|peers=Same as Build Config plus [mailto:jarmstrong@mozilla.com Joey Armstrong] and [mailto:mshal@mozilla.com Mike Shal].<br />
|group=dev-builds<br />
|components=Core::Build Config<br />
}}<br />
<br />
<br />
<noinclude><br />
===Unassigned Bugzilla Components===<br />
<br />
The following Bugzilla components in the Core project have not been assigned to a module (this list is not exhaustive):<br />
<br />
<pre><br />
Core::Event Handling<br />
Core::File Handling<br />
Core::Find Backend<br />
Core::Gecko Profiler<br />
Core::General<br />
Core::HTML: Form Submission<br />
Core::History: Global<br />
Core::Identity<br />
Core::Image Blocking<br />
Core::JavaScript Debugging APIs<br />
Core::Localization<br />
Core::Nanojit<br />
Core::Networking: Domain Lists<br />
Core::Print Preview<br />
Core::Printing: Output<br />
Core::Printing: Setup<br />
Core::Profile: BackEnd<br />
Core::Profile: Migration<br />
Core::Profile: Roaming<br />
Core::QuickLaunch (AKA turbo mode)<br />
Core::Rewriting and Analysis<br />
Core::Selection<br />
Core::Serializers<br />
Core::Spelling checker<br />
Core::Tracking<br />
Core::Video/Audio<br />
Core::Web Services<br />
Core::WebDAV<br />
Core::Widget: OS/2<br />
Core::Widget: Photon<br />
Core::X-remote<br />
Core::XForms<br />
Core::XUL<br />
Core::jemalloc<br />
</pre><br />
</noinclude></div>Sicking