1. IMPLEMENTING NEW WEBAPIS
Gregor Wagner (gwagner@mozilla.com)
Julian Viereck (jviereck@mozilla.com)
2. DISCALIMER
• No API designing/standadization here
• Talk about making the implementation happen!
• 55” not enough to get you going
• Reach out to us and do “hands-on” hacking
3. OUTLINE
• General Introduction
• How To Implement New API
• JS
• C++
• Make your work land
• Q&A
5. GENERAL INTRODUCTION
• Build on two previous presentations
• JS: David Dahl’s “From Web Developer to Firefox
Hacker” [1]
• C++: Bobby Holley’s “Hacking Gecko” [2]
• [1]: http://people.mozilla.com/~ddahl/pages/HackingFirefox/
template.html
• [2]: http://people.mozilla.com/~bholley/hacking-gecko-
fosdem2012/hacking-gecko.html
6. GENERAL INTRODUCTION
• Need to build Firefox
• Run build:
• Linux/Windows: objdir/dist/bin/firefox
• OSX:
objdir/dist/AppName.app/Contents/
MacOS/firefox
• options: -ProfileManager, -no-remote
8. GENERAL INTRODUCTION
• Don’t get lost in the details
• Ask for an implementation outline
• There is documentation, overview
• Über-Weapon: Ask for help
• IRC: https://wiki.mozilla.org/IRC, #developers
• Mailing list:
https://lists.mozilla.org/listinfo, dev-webapi
16. GENERAL INTRODUCTION
• whenever you do communication
• try to be precise
• give reasoning to your arguments
• get
only short answer - don’t take it wrong,
people are really busy
• dump whatever you have (crashback/patch...)
17. GENERAL INTRODUCTION
• don’t be afraid to ping people
• might get hint to ping someone else
• tell people you're new to hacking JS/Gecko
• look/ask for bugs that do similar things you try
to solve
19. FIREFOX OS WEBAPI
Wifi Browser Battery
Telephony
Settings Idle
Power
Contacts Bluetooth
Vibrator Webapps
many more to come....
https://wiki.mozilla.org/WebAPI/
23. MAPPING JS VS C++
• Read other APIs
• Interfaces are defined in dom/interfaces
• Implementations mostly in dom/*, content/*
• c++ implementations use common inheritance
• JS implementations use manifest file
24. TIME TO FILE A BUG
Bugzilla: DOM:Device Interfaces
32. FIREFOX OS PROCESS MODEL
• Parent
- Child • Nested process
Processes structure not possible
(yet)
• Only one parent
• Parent is trusted
• Browser is in parent,
content pages are • Child
can be
children compromised
• Securitycritical code
has to run in parent
33. SYSTEM MESSAGE MANAGER
• Use for child-parent
communication
• Child:
childProcessMessageManager.sendAsyncMessage("message-name", {"foo": 2});
var response = sendSyncMessage("message-name", {"foo": 1});
Parent:
•receiveMessage: function(aMessage) {
switch (aMessage.name) {
[...]
parentProcessMessageManager.sendAsynMessage(“return-message-name”, [...])
}
}
34. DOMREQUESTS
var pending = navigator.mozApps.install(manifestUrl);
pending.onsuccess = function () {
// Save the App object that is returned
var appRecord = this.result;
alert('Installation successful!')
};
pending.onerror = function () {
// Display the name of the error
alert('Install failed, error: ' + this.error.name);
};
39. INTERFACES Taken from
bug #745025
te [scriptable, uuid(a7062fca-41c6-4520-b777-3bb30fd77273)]
interface nsIDOMHTMLCanvasElement : nsIDOMHTMLElement
bu
{
tri
[...]
At
// A Mozilla-only callback that is called during the printing process.
attribute nsIPrintCallback mozPrintCallback;
};
k
ac
[scriptable, function, uuid(8d5fb8a0-7782-11e1-b0c4-0800200c9a66)]
llb
interface nsIPrintCallback : nsISupports
Ca
{
void render(in nsIDOMMozCanvasPrintState ctx);
};
te
ta
[scriptable, builtinclass, uuid(8d5fb8a0-7782-11e1-b0c4-0800200c9a67)]
tS
interface nsIDOMMozCanvasPrintState : nsISupports
in
{
Pr
// A canvas rendering context.
readonly attribute nsISupports context;
// To be called when rendering to the context is done.
void done();
};
41. MEMORY MANAGEMENT
• C++ doesn’t have a garbage collector :(
• In Gecko: Reference counting & cycle collector
• Reference counting:
• nsCOMPtr (for interfaces), nsREFPtr
• use getter_AddRefs
• NS_IF_ADDREF & NS_IF_RELEASE
42. MEMORY MANAGEMENT
• Reference counting doesn’t work always
• Make use of Gecko’s cycle collector
• Better cycle then maybe leak
43. DEBUGGING
• Make sure to have a debug build
• Enable logging (example)
• Watch for assertion in logs
• Insert printfs
• There is documentation how to use debugger
44. OVERVIEW OF SOME TREES
• Frame Tree: Frames on page
• Content Tree: Content going with frames
• View Tree: Connecting views
47. DIFFERENT TYPE OF TESTS
• Reftests
• Crashtests
• XPCShell Tests
• Mochitests
• JS tests
• Compiled code tests :-(
• Marionette tests
48. MOCHITEST
•/path/to/objdir $ TEST_PATH=dom/
contacts/tests make mochitest-plain
•/path/to/objdir $ TEST_PATH=dom/
Text
contacts/tests/test_contacts.html
make mochitest-plain
49. TIME FOR REVIEW
• Makesure the patch is • Whenuploading a new
formatted according to version:
the guidelines:
• address
*all* review
•8 lines of context comments
• correctcommitter • obsolete the old
info (name + email) patch
• correct
checking • run tests again
message
50. REVIEW
• Make sure your patch is clean
• Patch should be green on try-push
• WIP: State what’s working/what not/what’s next
• Review might take some time (~1 week?)
• If longer, ping person, switch review person
• Except r-, don’t worry!