share: chrome vs. web content
James Burke
bug 645802:
https://bugzilla.mozilla.org/show_bug.cgi?id=645802
show the account config happening as part of the Firefox preferences
UI, in a new section.
This leads to a question on how that share config UI should be
constructed. Right now it is done by web content, although the UI mock
has it looking like chrome content. It will still be possible to add
accounts from the web content via the share panel, and the mock shows
that add/remove/management of accounts in that share area in the
Firefox prefs.
Segmenting the account management into both chrome and web space is
going to be troublesome. The work should only be done in one place
(web or chrome) to avoid extra work and problems with API version
upgrades.
This brings up the larger question about how much of the share UI
should be done in web vs. chrome content. It would be better to choose
one or the other instead of trying to blend them both. The current
implementation uses vary minimal chrome, just enough to house the
share UI. Some chrome work will always need to be there, to allow the
best presentation of the UI, but the heavy lifting of the UI logic and
account data presentation should just be done in one place.
Reasons for doing it all in web content:
* Allows the UI to be upgraded more seamlessly than inside chrome.
* There is an OAuth jump that requires a web window anyway.
* This feature is about sharing, and at some point there will be a web
content API that sites can call to do sharing. We will need to make
this UI usable in web content by other browsers that are not Firefox,
so it makes it easy for content sites to adopt it (just include this
script tag, and enable better sharing no matter what browser, with
some extra nice UI in Firefox).
Challenges for it happening in web content:
* This implies there will be a web content area for at least part of
the Share UI in the Firefox pref. This seems like something new, so
there likely be implementation difficulties.
* Matching OS platform styles may require extra care?
* Or, reconsider the UI so that it will work for the
content-API/outside firefox future.
Reasons for doing it all in chrome:
* It is what most of the folks working on Firefox are used to doing,
so more likely to get to some definition of finished sooner.
Challenges for doing it all in chrome:
* The OAuth jump.
* Makes it harder to support the non-firefox web content API case later.
Larger picture soapbox:
Mozilla needs to get comfortable with having part of its browser
implementation on the web. It allows easier translation of the feature
to more mobile clients, and it allows Mozilla a foot in the door onto
devices that have significant restrictions to installing software on
the device: like iOS and Chrome OS. For share, it allows us to bring a
better share implementation to web sites that could work in all
browsers without needing a browser change/install. Sync has been
building some of those footpaths, and the sharing service is a great
way to continue to do it, even if it may be a bit awkward to work out
the mechanics at first.
While the web content API is not on the short list of first
requirements for share, it fits in with Mozilla's broader goals, and I
do not want to have to rip out a bunch of code later to meet that use
case. This is notable given Bryan's feedback about some sites wanting
to be able to know anonymous share stats: the broader we can get this
sharing adopted (by allowing non-Firefox usage) the better it fits
with all of those goals.
James
_______________________________________________
Services-dev mailing list
Servic...@mozilla.com
https://mail.mozilla.org/listinfo/services-dev