|
|
| Line 1: |
Line 1: |
| = Status =
| |
| ;Feature tracking bug
| |
| * {{bug|380415}}
| |
|
| |
| '' Has a design review been completed?''
| |
|
| |
| The design has been reviewed incrementally in {{bug|380415}}, its dependent bugs, and ongoing discussions in and newsgroups. A single, comprehensive, high-level review has not happened, and is not currently planned (other than this security review).
| |
|
| |
| '' When do you anticipate the feature landing''
| |
|
| |
| We were feature-complete in mid-September. Bug-fixing is ongoing.
| |
|
| |
| ''Any relevant status comments for the feature can be placed here.''
| |
|
| |
| = Overview =
| |
| It is now possible to have URIs with protocol schemes that are not handled internally (e.g. webcal:, mailto:, news:, etc.) handed off to web-based handlers in addition to desktop applications.
| |
|
| |
| == Use Cases ==
| |
| * Users who primarily use web mail should be able to click mailto: links and have them do the right thing (open their webmail applications in compose mode) rather than opening a compose window in a mail app that they don't use (e.g. Outlook Express).
| |
| * Users who primarily use web calendars should be able to click webcal: links and have them subscribe to the ICS calendars in question.
| |
| * (etc.)
| |
|
| |
| == Requirements ==
| |
| * Support web-based protocol handlers in the backend {{bug|380415}}
| |
| * Handlers should be selectable/configure from a dialog similar to the unknown content type handler for MIME types.
| |
| * Allow web sites to register new content handlers, including prompting user whether or not add requested protocol handlers
| |
| * Preferences API should exist for managing configured content handlers
| |
|
| |
| == UI Design Documentation ==
| |
| '' use cases and expected user knowledge (terminology, metaphors, etc) ''
| |
|
| |
| '' design mockups (of whatever fidelity is easiest) ''
| |
|
| |
| [[ContentHandling:User_Interface]]
| |
|
| |
| '' links to relevant user data, bugs, reports, examples, etc ''
| |
|
| |
| = Design Impact =
| |
|
| |
| == Security and Privacy == | | == Security and Privacy == |
|
| |
|
| * What security issues do you address in your project? | | * What security issues do you address in your project? |
|
| |
| **
| |
|
| |
|
| * Is system or subsystem security compromised in any way if your project's configuration files / prefs are corrupt or missing? | | * Is system or subsystem security compromised in any way if your project's configuration files / prefs are corrupt or missing? |
| Line 52: |
Line 11: |
|
| |
|
| * Include a thorough description of the security assumptions, capabilities and any potential risks (possible attack points) being introduced by your project. | | * Include a thorough description of the security assumptions, capabilities and any potential risks (possible attack points) being introduced by your project. |
| | | ** Assumptions |
| | | ** Capabilities |
| == Exported APIs ==
| | ** Potential Risks |
| * Please provide a table of exported interfaces (APIs, ABIs, protocols, UI, etc.) | | *** Phishy? (Encourages in-browser auth?) |
| * Does it interoperate with a web service? How will it do so? | | *** The HTML5 spec has a http://www.whatwg.org/specs/web-apps/current-work/#security3 list of possible security issues] that should be gone through |
| * Explain the significant file formats, names, syntax, and semantics. | | *** Uses of web-handled URIs in contexts other than in href attribute of a element |
| * Are the externally visible interfaces documented clearly enough for a non-Mozilla developer to use them successfully? | | **** object |
| * Does it change any existing interfaces? | | **** embed |
| == Web Compatibility ==
| | **** iframe (no status bar; even phishier than usual?) |
| * Does the feature had any impact on Web compatibility? | | **** script |
| == Performance ==
| | **** img |
| * How will the project contribute (positively or negatively) to "perceived performance"? | | **** others? |
| * What are the performance goals of the project? How were they evaluated? What is the test or reference platform and baseline results? | | *** old warning dialog has been removed |
| * Will it require large files/databases (for example, browsing history)? | | **** Logic: |
| == Reliability ==
| | ***** if it's that risky we shouldn't be doing it |
| * What failure modes or decision points are presented to the user? | | ***** unclear how much a warning dialog helps anyway" |
| * Can its files be corrupted by failures? Does it clean up any locks/files after crashes? | | ** Misc |
| == l10n and a11y ==
| | *** spec: "should NEVER send https URIs to third-party sites"; need to design fallback behavior or change. todo: ask hixie what this protects |
| * are any strings being changed or added? | | *** how do we handle URI leakage as per HTML5 4.10.2.1. todo: does fx2 handle this? sounds hard (impossible?) to fix |
| * are all UI elements available through accessibility technologies? | | *** credential leakage spec verbiage sounds unimplementable |
| | | *** figure out what URI schemes are acceptable for both source and target |
| == Installation, Upgrade/Downgrade/Sidegrade, and platform requirements ==
| |
| * Does it equally support all Tier-1 platforms? | |
| * Does is have a hardware requirement (or increase minimum requirements)? | |
| * Does it require changes to the installer? | |
| * Does it impact updates? | |
| *list the expected behavior of this feature/function when Firefox is upgraded to a newer minor release, downgraded by installation of an earlier revision, or re-installed (same version) | |
| | |
| == configuration ==
| |
| * Can the end user configure settings, via a UI or about:config? Hidden prefs? Environment variables? | |
| * Are there build options for developers? [#ifdefs, ac_add_options, etc.] | |
| * What ranges for the tunable are appropriate? How are they determined? | |
| * What are its on-going maintenance requirements (e.g. Web links, perishable data files)? | |
| == Relationships to other projects - are there related projects in the community? ==
| |
| * If so, what is the proposal's relationship to their work? Do you depend on others' work, or vice-versa? | |
| * Are you updating, copying or changing functional areas maintained by other groups? How are you coordinating and communicating with them? Do they "approve" of what you propose? | |
| | |
| == Documentation ==
| |
| * Do built-in Help pages need modified? | |
| * Documentation for developer.mozilla.org? | |
| | |
| == Other ==
| |
| ''any other implementation or design related documentation''
| |
| | |
| = Discussion & Implications =
| |
| | |
| == Caveats / What We've Tried Before ==
| |
| ''links to previous design documents, discussions, etc.''
| |
| | |
| == References ==
| |
| ''links to external documents that could inform the design of the feature''
| |