Jetpack/Weekly Meeting/2014-02-04

From MozillaWiki
Jump to: navigation, search


Agenda

Bugs

Triage Followups

No results.

0 Total; 0 Open (0%); 0 Resolved (0%); 0 Verified (0%);


Open Bugs

Attendees

  • Jeff
  • Mossop
  • DCamp
  • Irakli
  • Will
  • Erik
  • Matteo
  • Jordan
  • Zombie

Minutes

High Priority Work

Add-on Debugger

Jordan: waiting for help from devtools people.

Native Jetpack Support

Erik: not working on this last week.

node loader changes

Jordan: progress, working on getting the different bits wired up.

[Slaughterhouse] (needs public bug)

No Gabor this week.

Devtools SDK

Irakli: working on a prototype.

SDK 1.16

Erik will land mozrunner patch in the SDK. One bug waiting for info from Irakli: should we remove "strict": everyone: yes, we should.

Blockers?

Jordan has a few reviews waiting. Irakli has some things in his queue.

Roundtable

Australis bugs - should these be blockers?

  • bug 909349 - no button depressed state on OS X
  • bug 907450 panel can't be anchored to a button
  • state passed to onChange / onClick handlers for both toggle and action buttons should return the current window-level state - discuss.
  • there's something like a scrollbar in toolbars, if they have any content in them. Like this, from an add-on like this.

Let's create an etherpad for Australis bugs and discuss today. It will be increasingly hard to uplift changes. Worst case, we take the UX modules out of Firefox 29.

E10S

How important is e10s, and what should the Jetpack team do about it?

DCamp: e10s is important and if we can help, we should. But we need to understand where we can and cannot help. Most of the top 10 add-ons are not jetpacks. So fixing jetpack does not help them. The e10s team needs a story for XUL add-ons anyway.

bug 926264

intermittent test failure: sometimes tests complete but Firefox doesn't shut down, and we get a very generic error. can we make this less generic? Erik will take a look.

node shims for node modules

Jordan: should we have shims around our modules, to make them consumable by node applications? Especially for modules like event/target, that are very similar to, but different from, node modules like eventemitter. If we don't have core implementations, then npm modules cannot be used unless someone makes them, shares them, and others know where to find them and manually use them.