In Attendance

Agenda

myk: microsummaries should be added as a P3 item
- P2 - ability for extension authors to define microsummary information
- P2 - ability for page authors to encode microsummary
- P3/4? - ability for user to build their own microsummary
- gerv: will we make this a big name feature for Fx2?
- beltzner: we'll know closer to RC1, I guess
schrep: I think we need to ensure that there's a compelling enough reason to move to places if the only aspect of it that's P1 is the backend change
- API pieces need to be moved to P1
- beltzner: if we move the new Places UI to P1, will that be bad?
- ben: that less tags as P1 shouldn't affect ship date
- shaver: that's not really on the requirements list atm, and it should be

the usability study should be a P1
shaver: is the scope of session restore just the content, or will hooks be available to extension authors?
- dietrich: current scope is content area only
- bsmedberg: we're also just storing the URL and pulling from cache, but not storing the DOM
- dietrich: we are storing some form data (inputs, textareas, checkboxes)
- shaver: I'm interested in the extension hooks because it would allow for a deeper type of restore; could be an event, category of observers for serialize/deserialize; I'd propose a P2
- P2 - ability for extension authors to contribute to the session saving structures
- axel: we also want to be avoid the crash-reload-crash loop as well, that should be added as a requirement
spellcheck should bump down a P-level
jhughes: I'd like to see the browsermessage stuff promoted to being a product requirement, P2
shaver: the restore defaults thing from search should be promoted to a profile-wide thing; P3? P2?
need to add back the notification area requirement (general area in browser UI for application and extensions to notify users of ... something)

it's based on the SAX parser
beltzner: we're gonna drop the requirement for "chrome priv'd controls" since that's a design solution, not a requirement
dietrich, ben and others: combine feed items #2, 3 and 5 into a single higher-priority item, eliminate item #1 (it's an implementation detail)

beltzner needs to remove his implementation details
P5s need to be rendered differently, hard to see it was deleted
improve the UE around application updates for extension updates
bsmedberg: locale packs need to be P1'd to support the download size requirement
make first item P1, less implementation detail-y
shaver: support for new add on types as P3
shaver: we should rephrase items 1-4 into three seperate entities: management experience, install experience, update experience

s/adding and removing/managing/
shaver: leave restore defaults in, but it should be profile-wide
s/shadow text/discoverability/
schrep: search bar update toolbars have had a lot of innovation, should we be uplifting?
ben: a couple of additions
- P3: combine bookmark keywords and keyword search (ie: single provider for search)

rephrase EULA requirement so that it's more understandable
P2s providing 110n'd EULAs
P3s legally binding l10n'd version of the EULA
the bits around anti-phishing should move down to the anti-phishing section, duh
need to add MSI support at low priority just to get it back on the radar

remove the "respect and protect" item (it's part of the FFx charter)
rephrase "data model" to talk about requirement to document, fact it's not just UI instrument data
reprioritize the API and hooks to P3, add "for extensions"
performance section needs to be revamped entirely
most people agreed that performance around memory should be a P1
schrep: the issue is around getting benchmarks to make it crisper; we need to capture a better idea of what's pissing people off about our memory usage, and fix that as compared to our competitors
shaver: "market acceptable" memory usage?
choffmann: we also need to be testing more appropriately, with interactions instead of static content
cbeard: set benchmarks, align to use cases

totally didn't get to it

totally didn't get to it