Agenda

• FlightDeck 0.9.7 status
• SDK 1.1 status
• Development Process
• Add-on Builder Workshops
• Roundtable
  • Prototyping E10S API
  • Simple module loader
  • sandboxes vs jsm
  • too many compartments

Minutes

1.1 Status

Will

• working on making the docs server redundant
• got review from Brian yesterday
• patch probably needs a couple more rounds of review
• question of whether or not to implement Makefile-like behavior

• also looked at doc Alex wrote about content script proxies
• not yet ready, need to talk to Alex to talk about what's going on

• want to document security model for SDK addons
• what sort of access addons and content scripts have
• worried about just pointing people at unsafeWindow

• Irakli: i can be helpful in talking about content proxy
• Will to talk to Irakli about it

• talking to someone in UX team

Gábor

• started work on a number of small issues
  • bug 646575 memory leak bug, commented in bug; learned a lot about memory introspection
  • pretty sure there isn't an object leaking, more like memory fragmentation
  • really would like someone more expert reading my ideas and responding
  • Irakli: mrbkap and agal might be good candidates to respond
  • mossop to find someone to look at it and respond

• bug 672443: too many compartments
  • are we sure all compartments are coming from sandboxes?
  • seen some compartments being created in XPCOM as workaround
  • so perhaps we aren't actually creating as many compartments due to sandboxes as we think

• bug 658909: Incorrect |this| binding when using call() with XRayWrappers
  • got up to the point where the last guy got stuck
  • complex code, need time to become familiar with it
  • think i know where it's happening, not yet sure why it's implemented the way it is
  • quite messy, has some problematic areas, but super-important

Matteo

• spent last week with Irakli

• selections problem
  • there was some behavior where it wasn't clear if it's a bug or not
  • still some question, spec isn't clear
  • going to fix it in the SDK the way myk and matteo agreed
  • working on a patch to implement that behavior

Irakli

• some of this we already discussed last week

• simplified module loader
  • some discussion on mailing list; created pull request
  • got some feedback from Nickolay Ponomarev
  • he had recommended JSMs, but after a second look and benchmarking, he has second thoughts
  • regardless, i think it's good to have a simplified module loader
  • simplifications are priority per recent feature discussions
  • the prototype implements those simplifications, should be easy to port to sandboxes if we want to stick with those instead
  • irakli wants to know what to do next with prototype

• bugs on list
  • they were in dietrich's review queue
  • got his reviews last week and landed changes

• worked on modules bugs
  • making require statements explicit: had patch last week, needed some work, work done, patch landed
  • use strict: want to use strict in our modules; landed, broke on nightly, did more work to identify issues and fix them
  • freezing module exports for tamper-proofness: blocked by bug 674195, have new patch that works around issue
  • created separate bug for documentation side; in will's review queue

• created pseudo-code for e10s model
• wanted to implement prototype, but blocked by module loader

Eddy

• finished measurements, talked to bsmedberg, posted in dev.platform
• getting some feedback, but not 100% sure how to proceed
• started working on several e10s bugs
• ran into the same problems as Gábor: it's hard to start with stuff like that
• so moved to some simpler bugs in SpiderMonkey
• two hours ago i just posted my first patch
• plan to move to several other bugs and slowly work to more e10s stuff to get progressively more familiar with what i need to know

• dev.platform discussion: mostly suggestions for improving measurements
• also suggestion that we can improve on content process footprint significantly
• not clear if footprint is just data or includes code segment
• will get info from e10s team on their plans

Brian

• polishing off review queue, getting back to bugs
• closed some 1.1 bugs as wontfix

• some bugs are too hard and not important enough to fix
  • require detector should be comment-aware: do folks really care, or can we wontfix it
  • removing packaging from globals

• highest priority work this week is to look over irakli's loader proposal and e10s stuff

Myk

• review and email queues
  • making progress, but not caught up yet

• release engineering work to get tests passing on test automation
  • folks have been fixing test failure bugs
  • getting to the point where remaining failures require access to buildslaves to diagnose
  • lukas ready to give access to buildslaves when i say the word

• disabling compatibility check when running tests to avoid test automation bustage when Firefox version changes on Firefox/Gecko development branches
  • Wes: is this as easy as setting a checkCompatibility flag?
  • Myk: it might be!

Development Process

• no significant change from last week
• plan to be finalized soon, but don't expect any changes
• that means 1.1 merge from dev to stabilization branch happens next Tuesday
• but that doesn't mean it's time to crash-land patches!
• land only what's ready, the next release is right around the corner
• that's the point of having a rapid release process; releases every six weeks

• mossop, dveditz: how are we tracking features for 1.1?
• myk: picture unclear, as we're transitioning from dev plan pages to feature pages
• in the meantime, work (both features and bugs) is being tracked in bugs targeted at 1.1

• dveditz: are page-mods intended to protect users from malicious addons or addons from malicious web pages?
• warner: the latter
• dveditz: ok, good, as expected

Add-on Builder Workshops

• we're doing workshops in two locations: London and SF Bay Area
• London workshop is happening September 29 6-10:30pm
• three sessions: Interacting with Web Content, Adding to the Firefox UI, and Libraries and Modules
• possible advanced topic session: using API Utils and other Advanced Platform Services

• need leaders and assistants for sessions
• everyone should think about leading or assisting a session
• get back to Myk and mossop within the next day or two about it

Roundtable

• Irakli looking for feedback on:
  • Prototyping E10S API
  • Simple module loader
  • sandboxes vs jsm
  • too many compartments
• E10S API is particularly important
• Myk: everyone working on E10S should look at it and provide feedback to Irakli
• Brian to look at it and provide feedback in the next couple days