Add-ons/WorkWeek2013

From MozillaWiki
Jump to: navigation, search

Tuesday, July 16

Intro

Mobile add-ons

  • Goal: Make it easy to develop for mobile. Process, documentation, and tools should be streamlined and approachable.
  • Developer survey
  • Analyze contest submissions
  • User studies
  • Target content-related mobile add-ons
  • Challenges
  • Tools and documentation lacking/not integrated- organization of existing docs is the largest problem
  • No testing environment
  • Not enough users to know how to target
  • Action items:
    • Include themes on new add-on tab

Documentation

  • Discoverability is major challenge
  • Work-arounds until it becomes easier to find docs on MDN?
  • Move most of devhub to MDN.
  • Start making add-ons -> Guide page on MDN.
  • This page should highlight the SDK, but provide some perspective about XUL extensions.
  • Developer activity has remained stable along the years.

Future of Add-ons on Firefox OS

  • Add-ons might make sense where apps don't fill the gap
  • Customization for end users and manufacturers.
  • Stronger case for themes
    • Technical complexity
    • Theme file size
  • Extensions
    • AdBlock Plus
    • Content scripts
    • Extensions could have manifests that declare which apps they work with
  • What are the top 5 things users want to customize?

Marketplace

  • Right now, no pressure to converge add-ons with Marketplace
  • Focus is on apps, don't want to confuse people with so many choices
  • Nothing concrete until we have a strategy for apps on desktop
  • Now that there are no immmediate plans for convergence, we should move AMO forward

Wednesday, July 17

Add-on Developer Experience

Devtools API

Devtools extensibility

  • The API PRD above explains the plans for extensibility.
  • Extensibility is a big feature in Firebug. YSlow, FirePHP are popular extensions.
  • Millions of users still using Firebug.
  • What is our message to devs?
  • Web Console is first step for extensibility, then move into new devtool panels.
  • Panels depend on making it easy to replicate the experience in the default panels, which might require Web Components or reusable stylesheets.
  • Firebug will continue to be supported until it's usage become negligible.
  • We should gather data about actual Firebug usage: Test Pilot?

Upcoming technical challenges

e10s

Metro

  • Initial plan not to support add-ons and see if users complained about it.
  • Metro interface is XUL, based on original Fennec, so it is possible to support add-ons.
  • Supporting add-ons requires adding an add-on install UI. Should only bootstrapped add-ons be allowed?

Australis

  • Most add-ons that add toolbar buttons should continue to work.
  • Add-on Bar and statusbar are both gone.
  • Current plan is to bake on Nightly for two cycles, and release on 26.
  • We want to approach developers when it hits Aurora.

Sandboxing

Deprecation of XUL add-ons

  • Nope
    • no reason to do this, but no hope for xul outside of desktop.

Roadmap meeting

  • (Q3 -> *) Infrastructure.
  • (Q3) File registration
  • Docs: https://wiki.mozilla.org/Features/Desktop/Improve_Add-on_Monitoring
    • Validator
    • Admin interface - CRUD / reporting
    • User (developer) interface - UX
    • API
    • Platform - Mossop, UX
  • Better documentation
    • (Q3) Landing page for devs on MDN - sheppy, holly (UX)
    • (Q4) SDK docs - Luke Crouch
  • (Q3 - Q4) Mobile add-ons
    • Contest
    • Market requirements
    • Stats - Metrics (download counts for mobile), webdev (~2 weeks)
    • Developer survey
  • (Q3) Australis
    • Ongoing into Q4.
  • (Q3) Indiegogo
  • (Q4) Retiring the Add-on Builder
  • (Q1 - Q2) AMO Feature / bug work.

Add-on Performance

  • Profiler can be modified to tell apart add-on code.
  • Memory usage is probably the biggest problem in performance, causing jank and other problems.
  • AV add-ons do many things that cause performance problems.
  • Making the slow startup notification better.
  • Firefox self-healing / reset.
  • Slow SQLite queries.
  • Power usage graphs.
  • Test day? Reach out through users through communication channels?

Thursday, July 18

Squeaky

  • https://bugzilla.mozilla.org/show_bug.cgi?id=775253 Gather statistics on add-ons installed after changes to extensions.autoDisableScopes
  • With FHR we'll know which installs are enabled.
  • Consider prompting users to clean up their add-on installs again (bug 596343).

Add-on Install Process

Dealing with malicious and unwanted add-ons

  • Integrate extension blocklist and file registration
  • Should we only check hashes on install?

Blocklisting

  • bug ? - Increase blocklist refresh rate to twice a day. -> Easy, but P3
  • bug ? - Make Add-ons Manager look for suitable upgrades or downgrades before issuing a block. -> P2, easy (might need work on AMO side)
  • bug ? - Expand blocklist features.
    • Support warnings for policy violations and performance problems, support custom URLs (SUMO pages, blog posts). P2
    • Bug 802434 - Support reverting settings (homepage, default search, keyword URL). P1, being worked on.
    • bug 897735 More filtering options: name, developer (regular expressions). P1

Third party add-ons

  • Remove deletion requirement until it becomes a problem.
  • Remove requirement of optional AMO code review. -> Version 2
  • Separate from add-ons table.
  • Use metadata ping on install.
  • No warning on install of unregistered file.
  • TODO: mockups for Admin tools.
  • Add Telemetry for add-ons bypassing the registration mechanism.
  • Deploy during 3 releases: first show a warning in the Web Console, secondly show a warning with opt-in, and finally close the list.
  • The override system should be more robust than a preference.
  • How will this work with the blocklist?

Statistics gathering

  • https://dataviz.mozilla.org - yummy dashboards!
  • Get more data for developers (crash, fhr) from Metrics to AMO.
  • TODO: figure out exactly what kind of data we want to gather.
Retrieved from "https://wiki.mozilla.org/index.php?title=Add-ons/WorkWeek2013&oldid=684598"