Labs/Jetpack/Weekly Meeting/2011-07-26

From MozillaWiki
Jump to: navigation, search



1.1 Status


  • 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


  • 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


  • 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


  • 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


  • 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


  • 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


  • 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


  • 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