Search by property

Jump to: navigation, search

This page provides a simple browsing interface for finding entities described by a property and a named value. Other available search interfaces include the page property search, and the ask query builder.

Search by property

A list of all pages that have property "Feature requirements" with value " *Browser agnostic ". Since there have been only a few results, also nearby values are displayed.

Showing below up to 26 results starting with #1.

View (previous 50 | next 50) (20 | 50 | 100 | 250 | 500)


    

List of results

  • DevTools/Features/ConsoleObjectCompletion  + ( * The <tt>console</tt> object implements the portion of [http://getfirebug.com/wiki/index.php/Console_API the API] that is implemented by both Firebug and WebKit. Notably, this includes time, timeEnd, dir, group and groupEnd. )
  • Security/Features/Cert Blocklist via Update Ping  + ( * The ability to block root certificates, intermediate certificates, and end-entity certificates * The ability to block certificates using specific keys * The ability to undo a block should one be applied erroneously )
  • Features/Desktop/About Version  + ( * The feature must remove the version number. * If the user is up to date, the feature must say so * The feature must say when it last checked. )
  • Privacy/Features/Tracking alert  + ( * This should be unobtrustive and alerting mechanisms should be extensible by add-ons. )
  • Tip of the day  + ( * Tips of the day database )
  • Firefox Social Integration  + ( * To manage a list of social services (di
    * To manage a list of social services (discover, install, delete) * To display to the user which social services they are currently signed in to * To easily sign in and out of a service, and to switch which service the user is interacting with, or to switch off social interaction * To recommend the current page to their friends on a network - either as a standalone URL or with a comment. * To see which of a user's contacts are online * To initiate real-time communication with a contact through chat, voice, or video * To see updates from contacts and to be notified when new updates are available * To receive, at the user's discretion, ambient or immediate notification when interesting events have occurred
    ation when interesting events have occurred )
  • Features/Services/Notifications  + ( * Transparency: Process MUST be transpare
    * Transparency: Process MUST be transparent to user. For example, other than clicking "Yes" or "No" to a dialog of the web app requesting to send notifications, the user should not be aware of the underlying mechanics of the process. * Security: From the point a message leaves the sender until it arrives at its intended recipient, all communications may not be easily readable by unauthorized persons (e.g. anyone besides the sender and the recipient). By "easily" we mean it should not be trivial to decrypt a message, but take a long enough time and resources so that such effort is not viable. Encryption is optional, but the key should be provided by the client service. * Anonymity: Web apps MUST not know anything about user (insofar as the communication between the web app and server is concerned; if the user is logged in to GMail and signs up for notifications, then obviously Google can associate the resulting subscription with the user who created it). * Portability: Service MUST work with any device that supports the protocol. * Control: The user should be able to disable or delete any created notification channel. Upon deletion, the user should not see any additional messages sent to that channel. The sender should be notified that messages to that channel are no longer being accepted.
    that channel are no longer being accepted. )
  • Marketplace/Features/Anonymous App Installs  + ( * Users must log in to install both free
    * Users must log in to install both free and paid apps by default * Users can opt in to installing free apps without logging in ("anonymous installs") on a per-device basis * Users who enable anonymous installs must be warned of the consequences * Users who have enabled anonymous installs must still be allowed to log in if they choose * We must be able to analyze usage of this feature
    st be able to analyze usage of this feature )
  • Marketplace/Features/Country Stores  + ( * Users who visit the Marketplace have an
    * Users who visit the Marketplace have an experience tailored to their language and region. * The initial set of supported regions is available on the [[Marketplace/International|International page]]. * Initial language and region settings are guessed based on information available to us. * Users can change their language and region at any time and it will be remembered for subsequent visits.
    t will be remembered for subsequent visits. )
  • Privacy/Features/Site-based data management UI  + ( * We need to document existing data sources and mappings to the user interface * UI must be designed carefully, perhaps with a user study * Security and authenticity of the configuration UI must be verified and accessible to users. )
  • Labs/PAC/Delta  + ( * We need to document existing stream dat
    * We need to document existing stream data sources and APIs to make a natural and comprehensible API for developers * These API and data type definitions will drive mappings to the user interface * UI for both configuration and use must be designed carefully and with user studies * Security and authenticity of the configuration UI must be verified and accessible to users. * Plans for pulling data from streams and caching for responsiveness * API "translators" (so a request to Delta's API makes the correct call to, say, Facebook's API)
    s the correct call to, say, Facebook's API) )
  • Firefox/Features/Show infobar session restore  + ( * When (re)starting the browser with a saved session, an infobar should show if there's a custom home page defined — but not if about:home is the default. )
  • DevTools/Features/SourceMap  + ( * When a sourcemap is available, error me
    * When a sourcemap is available, error messages in console will link to the original source, not the generated JS * Likewise, console log output will link back to the original source * Patches for CoffeeScript will be used to produce examples * The Closure Compiler should generate compatible source maps * A specification for generated scripts to refer to their mappings and a mapping format * SpiderMonkey needs to output column in addition to source/line. * code that is loaded via eval() should also support sourcemaps
    d via eval() should also support sourcemaps )
  • Firefox/Features/Toolbarless  + ( * When making a page into an app tab, the
    * When making a page into an app tab, the toolbar should disappear. * It should be possible to right-click the tab and turn the toolbar back on. ** This setting should be remembered on a per-domain basis. * When using keyboard shortcuts to get to URL field or search field, it should be turned on for the duration of the interaction, then disappear again.
    n of the interaction, then disappear again. )
  • Labs/F1/Feature Blocks/F1  + ( * [[Labs/F1/Feature Blocks/Twitter | Twitter]] )
  • Fennec/Features/langchoice  + ( * [http://etherpad.mozilla.com:9000/VLDiPkfl8p Summary of our most recent discussion] )
  • Privacy/Features/Tracking Map  + ( * clear what the graph/map represents. * actionable (you can do more than just learn with it). * efficient (no perceived slow-down for those who don't use the tool) * accurate (must not misrepresent sites as "malicious" if they're not) )
  • Firefox/Features/keywordurl follows searchbar  + ( * detect change of default search engine
    * detect change of default search engine (browser.search.defaultenginename) on startup, add-on install, search engine install, or user change * on detection of change, modify keyword.URL parameter (or equivalent) to match selected/default search engine such that location bar searches will use the same search service * optionally drop keyword.URL parameter and replace with a location bar search pref and/or do a straight follow of the selected/default search plugin * allow location-bar specific Param or MozParam to override or append search query attributes to queries originating from the Location Bar
    o queries originating from the Location Bar )
  • DevTools/Features/CSSDoctor  + ( * integrates with nodes selected via the
    * integrates with nodes selected via the Highlighter, GCLI or other means * can provide answers for a "substantial" set of node/rule combos. Problems of the sort: ** selector didn't match or was overridden ** error in CSS (some errors require the context of a node) ** layout problems (Shaver's list: too indented, not indented enough, too narrow, too wide, not aligned with something else, etc.)
    ide, not aligned with something else, etc.) )
  • DevTools/Features/ConsoleQueuedMessages  + ( * messages logged using <tt>console.*</tt> methods should be displayed on open of Web Console (subject to limitations to avoid a queue that's too large) )
  • Firefox/Features/Generic Thumbnail Service  + ( * one thumbnail service for all features * caching across the whole browser * edge-case handling at one place not re-implemented for every feature )
  • DevTools/Features/ViewSource  + ( * this feature should be behind a pref so
    * this feature should be behind a pref so that it can be turned on when it's ready * Fast, even on large files * Performs well for single line files * syntax highlighting ** For just HTML and XML? Also for CSS and JS? * Navigate to other files referenced in the source file * Can view selection source * Can do a find in the source text * View "Original" (as downloaded) and "Current" markup (after JS manipulation). The "Current" view would be provided using the [[DevTools/Features/HTMLTreeEditor|HTML Tree]] * Be able to view HTML/JS/CSS * Display the image if pointed to an image * navigate with keyboard and mouse * be able to switch from viewing CSS to editing CSS using the [[DevTools/Features/CSSEditor|Style Editor]] ==== Nice to Have ==== These features are desirable but do not absolutely need to be there for the first iteration. * line numbering * Open in tab rather than window (open in sidebar option?) 1 * Ability to open source links in separate tabs in the view source window (for example, if you want to open the CSS in a separate tab while keeping the HTML source open in the first tab) * Optionally beautify HTML/JS/CSS * works without accessing network (a much requested feature for View Source) ** what's this about? it already does, unless the page uses cache-control:no-store. ** I believe people want the original source that was loaded, regardless of cache-control * quick navigation to other files loaded in that tab * Be able to view JSON/XML (for use as a view elsewhere) * HTML/CSS/JS error reporting 2 ==== More for Further Triage ==== These came from feedback that Paul Rouget got from Twitter. * Disable links so that the text can be selected (view source currently turns all links in the source into active links instead of selectable text... generally the right answer, but some would like to be able to select the text) * open a link in a new tab (view source in a separate window with this ability sounds very nice!) * edit source and reload page from edited source * API for addons to access raw source code * navigation (awesomebar) in the View Source window * background color configuration (themes) * more detailed HTML syntax highlighting (for things like classes and rel which are space separated, for example) * MDN links for HTML tags, attributes and common microformats * enable/disable refreshing of the tree if the page is changing * preview image, video, audio when hovering its link (similar to what Firebug is doing on network panel) with information (dimensions, size, format, compression weight etc.) * sourcemap support * beautify compressed source * search elements with a query selector * table of contents in a sidebar * highlight elements on the page if you hover over it in the source * split window to view multiple sources * view source in context menu on pages with a canvas covering the page * some option to show HTTP headers from within view source * code folding * url()s in CSS are linked * ability to jump to the definition of a CSS class on an element * ability to see the CSS rules applied to an element * ability to view the event handlers attached to an element * intra-document navigation via #id URLs * display favicons as images. right now, view source displays binary data for .ico files * editing * breakpoint for DOM mutations * ability to view source for add-ons Footnotes: # Opening in a separate window should be the default, with the ability to drag into a tab. If the user does drag to a tab, we should remember that and open in tabs by default. # Henri Sivonen's redo of view source using the HTML5 parser can produce HTML error reports
    f view source using the HTML5 parser can produce HTML error reports )
  • Services/Sync/EOL Sync Add On Phase 2  + ( *(More of a task than requirement) Disable the Firefox Sync Add-on AMO page )
  • Silent Update not now prompt  + ( *All users without Add-ons or have all co
    *All users without Add-ons or have all compatible Add-ons are updated to the latest version of Firefox on release date ** ITYM "eligible to update, modulo checking frequency and [https://wiki.mozilla.org/Firefox/Features/Lessen_App_Update_Displayed_UI prompts for long sessions]" -Jesse *For users with 1 or more incompatible Add-ons, we will offer a 10-day grace period with no prompt to update Firefox (assuming this passes security review) *As Add-ons become compatible on subsequent days post release, users will auto update anytime within the 10-day grace period when all of their incompatible Add-ons become compatible *On the 10th day of the grace period if there are still incompatible Add-ons, we will prompt the user with the two options: **"Update now" -- We ask users to update now and inform them that their browser is insecure and they are more vulnerable to attacks. We will disable all incompatible add-ons (we will not remove them) at the time of updating. **"Remind me later" -- We will defer the update for 10 additional days and on day 20, we will update users automatically. However, we will notify users via the notification bar with the following message: ***"For security reasons, Firefox has been upgraded, but certain add-ons have been disabled. Please contact the add-on authors for more info. [Link to add-ons manager]" *Some additional requirements we discussed: **In the preferences dialog under Advanced > Update, remove the "never check for updates" radio button option. **In the preferences dialog under Advanced > Update, remove the "Warn me if this will disable any of my add ons" check box. Now that we've moved to add-ons default to compatible, the only add-ons that will be incompatible are ones with binary components. This logic should be included in the 'recommended' update selection. **Create an add-on that allows users who want to have the option to disable the ability for Firefox check for updates.
    isable the ability for Firefox check for updates. )
  • B2G App Security Model  + ( *An app store needs to be able to approve
    *An app store needs to be able to approve an application, implying they can verify the permissions, integrity and authenticity of the app *App store needs to be able to revoke an app *App store must be able to set the default permissions for an app *A user needs to be able to make a trust decision at install time, so they also need to be able to verify the authenticity, integrity and privileges of an app *User has control of the permissions of the app throughout its lifecycle, overriding those set by the app store if desired *Apps should be able to discover their privileges and degrade gracefully in a limited privilege environment *Permissions need to be expressed to the user in a way that they can realistically be expected to comprehend (perhaps with options for power-users) *Permissions requested / set need to be enforced. *Apps should not be vulnerable to common web vulnerabilities when granted significant privileges *Ability to grant trust for certain highly sensitive privileges (such as phone dialing) may be restricted at the OS level to specific trusted parties
    at the OS level to specific trusted parties )
  • DevTools/Features/Workspaces  + ( *Convert the add-on into a browser feature with tests *Add a pref to remove the content/chrome switch from view Aurora backout strategy: there is a pref to turn off the feature (devtools.workspace.enabled) )
  • Firefox/Features/50ms ASSERT  + ( *Does not affect performance in production or beta builds *Can be logged to screen or file *Logging has been added to all primary user interface events )
  • Support/Firefox Features/Clean up user profile  + ( *Easy to use *Easy to discover (Ideally the user shouldn't have to go to SUMO to figure this out) )
  • Silent Update updater  + ( *Install all non-active components into t
    *Install all non-active components into the browser during the active session *On the next Firefox reload, install the remaining update bits *The delay on start-up for the next session should be minimized as far as is humanly possible, approaching normal cold start times. *[https://bugzilla.mozilla.org/show_bug.cgi?id=685614 bug 685614] - Turn off the installation progress bar window
    rn off the installation progress bar window )
  • Services/Sync/Features/Addon Sync  + ( *When a user installs an add-on, the add-
    *When a user installs an add-on, the add-on will be installed on all the user's devices connected with Sync. *When a user uninstalls an add-on, the add-on will be uninstalled on all the user's devices connected with Sync *When a user disables an add-on, the add-on will be disabled on all the user's devices connected with Sync *When a user enables an add-on, the add-on will be enabled on all the user's devices connected with Sync *Not sure about the update version requirement. ; Non-impact on add-on manager metrics : The presence of Sync should not skew the metrics in the add-on manager and addons.mozilla.org. Currently, some APIs on the AddonManager upload metrics.
    me APIs on the AddonManager upload metrics. )
  • Privacy/Features/Pref to limit number of fonts loaded per tab  + (- Must not break (as in make unreadable) i
    - Must not break (as in make unreadable) international sites. - Must not leak any extra information per page load (solutions might leak information to the same site between loads are not acceptable). - It must stop CSS and Javascript leaks. - Must not prevent chrome from using local fonts.
    not prevent chrome from using local fonts.)
  • Privacy/Features/Limit CSS3 resolution  + (-CSS properties must not reveal browser side.)
  • Security/Features/PasswordManagerImprovements  + (1) Preventing active network attacks: * [h
    1) Preventing active network attacks: * [https://bugzilla.mozilla.org/show_bug.cgi?id=1118511 Bug 1118511] Do not autofill the username/password stored in password manager on any pages. Provide alternative UX - UX help needed. If automatically filling the password must be an option, then at least do not fill in the following cases. (Note this does not secure the user from xss attacks, third party javascript, etc.) ** For http sites (IE 11 has this security feature) ** https sites that have mixed active content ** https sites that require a cert override (chrome does this) ** in iframed sites (where the parent and frame are not same orign, or always?) (safari does this for non-same origin, chrome does this for all frames). (Open Issue - what about third party widgets that allow users to login and post comments.) ** Invisible form fields (visibility and opacity, although this isn't going to prevent clickjacking attacks to autofill the passwords) * [https://bugzilla.mozilla.org/show_bug.cgi?id=748193 Bug 748193] Warn users when they are entering their passwords on HTTP sites. UX help needed for this. Some options: ** warning icon in the password field ** Fill-and-submit button is a different color ** On mouseover of the fill in submit button, the user can read a tooltip that warns them that their password can be seen in the clear. ** [https://bugzilla.mozilla.org/show_bug.cgi?id=1118558 Bug 1118558] Flag in the Password Manager User Interface that shows all saved logins. ** See also [https://wiki.mozilla.org/Security/Features/HighlightCleartextPasswords Highlight Cleartext Passwords]. * [https://bugzilla.mozilla.org/show_bug.cgi?id=1118540 Bug 1118540] Secure Filling 1.0 - Passwords that are saved by the password manager should not be available to javascript on the page. The actual password values should only be sent on submit. This protects the password from attacks via xss, 3rd party javascript, etc. Implementation details: when a password is filled in on a form, fill hash(uri, username, salt) instead of the actual password. On submit, lookup the actual password value for that url and send that instead. Username is included for cases where there are multiple usernames. 2) Preventing local attacks: * [https://bugzilla.mozilla.org/show_bug.cgi?id=1118549 Bug 1118549] Encryption - Explore solutions for encrypting the passwords stored locally in the password manager (for example, make use of keychain or encryption mechanisms that come with the OS). 3) [https://bugzilla.mozilla.org/show_bug.cgi?id=1118553 Bug 1118553] Duplicate Passwords - Protecting users from password reuse attacks * Create UI around alerting users that they are reusing the same passwords 4) [https://bugzilla.mozilla.org/show_bug.cgi?id=1119555 Bug 1119555] HSTS: If a site is HSTS, then there is no reason to have http data for that site. Hence, if a site is marked HSTS, and the user has any data (cookies, passwords, etc) that are not https-only/secure, immediately mark that data as https-only. (Note that we'd need some way to indicate that the site has been STS for at least X weeks to prevent deleting data from a site that goes HSTS as a beta test and then goes back to non-HSTS.) More about Autofill: If we must allow autofilling in certain cases, then we also need the following security features: * If an identical password is stored for both the http version and https version of a specific website (or domain), and it is not used on the http site for X months, expire the http version after alerting the user. (This can help in cases where the website has upgraded to https, but the user's http password manager entry still exists and is open to attack). * When the password field name is different from the name when the password was saved, don't allow filling & submit. Moreover, don't allow javascript to dynamically change the name of the form?? See [https://www.usenix.org/system/files/conference/usenixsecurity14/sec14-paper-silver.pdf section 5.2, Preventing self exfiltration attacks]. * Consider not autofilling in cases where the page has multiple login forms. Future Work: * Support [https://mikewest.github.io/credentialmanagement/spec/ Credential Management Specification] so websites can opt into better detection and protection. * Prefer secure origins - If a password is stored in an http version of a site, see if the https version exists. If it does, prompt the user to redirect to the https version of the site and store their password there instead. (Issue here is that we don't always know if changing the url to https will work, or if a site is set up to have a different domain or path for their secure version) * [https://bugzilla.mozilla.org/show_bug.cgi?id=1118540 Bug 1118540] Secure Filling 2.0 ** Do not give javascript access to any password fields (regardless of whether the password manager saves the password) - the actual password the user enters is only used on submit. The problem with this is with registration pages that use javascript to test the password strength. [https://bugzilla.mozilla.org/show_bug.cgi?id=653132 Bug 653132]. Can we detect registration pages? If a page a registration page has only one password field (they don't ask you to confirm your password by entering it twice) do they really use javascript to test password strength? Since they aren't asking you to confirm your password, they probably aren't too concerned with special characters.
    confirm your password, they probably aren't too concerned with special characters.)
  • Additional distribution points  + (1. Registration costs 2. setting up automatic updating for these distribution points. 3. to be filled in)
  • Web Apps integration  + (;Discovery * Firefox App Store launcher in
    ;Discovery * Firefox App Store launcher in the Home Tab ;Install Experience * Install prompt is in Firefox chrome * After install has been completed, the user is shown where the app can be found ; Launch Requirements: * Native launch works in Windows 7 and Mac OS X ;Offline Requirements: * Apps should be able to run offline in the same manner that Web apps are able to run offline ;Uninstall Requirements: * Uninstall from system uninstaller, appropriate to the OS
    system uninstaller, appropriate to the OS)
  • Features/Desktop/Firefox Home Tab  + (;Phase 1: *The work here is focused on the
    ;Phase 1: *The work here is focused on the content of the about:home page *Tab infrastructure does not change and about:home will remain as a tab (vs. a pinned tab) *In this phase we will introduce launchers to the the Firefox Home page. See the UX spec below to see what this looks like. These launchers will serve as a starting point to access common activities for Firefox users today. *[https://bugzilla.mozilla.org/show_bug.cgi?id=711157 Bug 711157] - Home Tab phase 1 *Assuming a Fx13 launch target date of 6/5, the "Apps Marketplace" launcher will need to be pref'ed off until the Marketplace goes GA at the end of Q2. *When Apps Marketplace launches, we'll need to flip the pref for the Marketplace icon to appear for a specific set of launch locales. **Specific locales to be determined by Apps product team. ;Phase 2 *Tab infrastructure will change and about:home will become a pinned tab *The pinned tab will behave like any current pinned tab and will be removable by the user *Enhances the Home Tab content with the intro of the Apps Marketplace as well as additional modules that allow users to customize their page with content that matters to them *UX is working on a wireframe for what the 'final' design will look like as well as creating more detailed specs for the various modules that will live on the page itself for phase 2 *More detail to come shortly *Wireframes for stage 2: **[https://wiki.mozilla.org/File:Wireframe1_justchat.png Basic: content and chat] **[https://wiki.mozilla.org/File:Wireframe2_conversation.png With a chat window open, large top bar] **[https://wiki.mozilla.org/File:Wireframe3_smalltop.png With a Top Apps section] **[https://wiki.mozilla.org/File:Wireframe4_largeapps.png With additional apps displayed]
    geapps.png With additional apps displayed])
  • Silent Update whatsnew  + (<b>Engagement/PMM Feature Requiremen
    Engagement/PMM Feature Requirements: *Be able to tell people What's New within Firefox (updatable) *Engagement touchpoints - email, Twitter, Facebook *Promo spots for campaigns (ex. Webify Me) and products (mobile, apps, add-ons, etc) *User alerts (ex. "Your Flash is out-of-date") **(all of the above have the standard features of a web page - easily updatable; flexible in terms of A-B testing, rotating content, etc...vs something hard-coded into the browser chrome) *Ability to push people off older versions (ex. warning people to upgrade from 3.6) *A/B test who sees the what's new page (i.e. 95% see it, 5% don't see it) and track their engagement
    5% see it, 5% don't see it) and track their engagement)
  • Services/Sync/Sync Setup Improvements Desktop  + (<table class="fullwidth-table" style="w
    Must Have Requirement Notes
    X The user is reassured that sync data is secure
    X The user is not confused by any step in set up
    X The value of Sync is clear to the user
    X For initial Sync setup, the user must know that Sync is working before set up is complete
    X When setting up a subsequent desktop browser, the user must know that Sync is set up See in Mock up how personas should be updated. Still not clear. Adding to issues list.
    For a Sync user, reinforce how Sync works in the background This is not part of set up, hence why it would be nice to have. It is not a blocker to completing this feature.
    For a Sync user, reinforce the Sync data is secure This is not part of set up, hence why it would be nice to have. It is not a blocker to completing this feature.
    ckground</td> <td>This is not part of set up, hence why it would be nice to have. It is not a blocker to completing this feature.</td> </tr> <tr> <td></td> <td>For a Sync user, reinforce the Sync data is secure</td> <td>This is not part of set up, hence why it would be nice to have. It is not a blocker to completing this feature.</td> </tr> </table>)
  • Services/Sync/Sync Setup Improvements Mobile  + (<table class="fullwidth-table" style="w
    Must Have Requirement Notes
    X The user has a streamlined set up experience
    X The user is reassured that sync data is secure
    X The user is not confused by any step in set up
    X The value of Sync is clear to the user
    X For initial Sync setup, the user must know that Sync is working before set up is complete
    X When setting up a subsequent desktop browser, the user must know that Sync is set up See in Mock up how personas should be updated. Still not clear. Adding to issues list.
    For a Sync user, reinforce how Sync works in the background This is not part of set up, hence why it would be nice to have. It is not a blocker to completing this feature.
    For a Sync user, reinforce the Sync data is secure This is not part of set up, hence why it would be nice to have. It is not a blocker to completing this feature.
    a Sync user, reinforce how Sync works in the background</td> <td>This is not part of set up, hence why it would be nice to have. It is not a blocker to completing this feature.</td> </tr> <tr> <td></td> <td>For a Sync user, reinforce the Sync data is secure</td> <td>This is not part of set up, hence why it would be nice to have. It is not a blocker to completing this feature.</td> </tr> </table>)
  • Identity/Features/Verified Email Service  + (<table class="fullwidth-table"> <
    '''Item''' '''Bug''' '''Status'''
    R3.1 Service uses Firefox Sync IDs as its auth backend - -
    R3.2 registerVerifiedEmail / registerVerifiedEmailCertificate support - -
    R3.3 API for clients to create new accounts (without necessarily provisioning Sync) - -
    R3.4 API for clients to add/remove email addresses to/from an existing account - -
    R3.5 API for clients to send/re-send verification emails - -
    R3.6 API for clients to list verified/pending emails - -
    R3.7 Service implements APIs for verifying identity assertions (for sites) - -
    send/re-send verification emails </td><td> - </td><td> - </td> </tr> <tr> <td> R3.6 API for clients to list verified/pending emails </td><td> - </td><td> - </td> </tr> <tr> <td> R3.7 Service implements APIs for verifying identity assertions (for sites) </td><td> - </td><td> - </td> </tr> </table>)
  • Identity/Features/Web-based Verified Email Client  + (<table width="100%" cellpadding="3">
    '''Item''' '''Bug''' '''Status'''
    Core VEP client implementation (can handshake w/ server register an email, generate keys, receive a cert, generate assertion; no UI, no cert refresh) 664598 -
    Relying party wrapper implementation (can handle getVerifiedEmail call and interact w/ core VEP client in a popup window; still no UI nor cert refresh) 664597 -
    Identity authority wrapper implementation (can handler registerVerifiedEmail and registerVerifiedEmailCertificate calls and can interact w/ core VEP client in parent window, still no UI nor cert refresh) 669455 -
    UI interaction through account creation / login / release of one email address (most UI will be generated by the server) 664594 -
    Email selection UI (mostly generated by UA) and integration into VEP process 664599 -
    Certificate refresh, successful only 668620 -
    Certificate refresh w/ failure 668625 -
    ========= OLDER (OBSOLETE?) MILESTONES BELOW ==========
    Relying party API - -
    Sign-in pop-up - -
    Email disclosure pop-up - -
    Email verification pop-up - -
    Account creation pop-up - -
    Account creation UX polish[1] - -
    HTML client popups support multiple emails - -
    HTML client allows adding a new email to an existing account - -
    [1] ''e.g., password strength meter, pop-up auto-closes upon email verification''
    lt;/td><td> - </td><td> - </td> </tr> <tr> <td> Email verification pop-up </td><td> - </td><td> - </td> </tr> <tr> <td> Account creation pop-up </td><td> - </td><td> - </td> </tr> <tr> <td> Account creation UX polish[1] </td><td> - </td><td> - </td> </tr> <tr> <td> HTML client popups support multiple emails </td><td> - </td><td> - </td> </tr> <tr> <td> HTML client allows adding a new email to an existing account </td><td> - </td><td> - </td> </tr> </table> [1] ''e.g., password strength meter, pop-up auto-closes upon email verification'')
  • Fennec/Features/Reader  + (==== Read anywhere ==== * Your reading li
    ==== Read anywhere ==== * Your reading list is synced across your devices. * Your furthest-read position in each article is synced across devices. * Articles from your reading list are saved for reading offline. ** We could limit to reduce bandwidth and disk issues without impacting the main use case. For example, we could save the 20 most recent articles for offline reading by default, and this could be configurable. ==== Readable ==== * Reading mode is full screen with no distractions. * Pagination instead of scrolling, with a quick tap to change pages. (Reduces swiping fatigue in long articles.) * Beautiful typography, with typefaces and layouts optimized separately for phone, tablet, and desktop displays. ** We could ship our own high-quality fonts (in WOFF format?). * Pinch zoom adjusts font size while keeping text formatted to fit the screen. ==== Usable ==== * Built-in feature, not an add-on. (This is necessary for the "read anywhere" magic to work without going through set-up steps on multiple devices.) * Zero set-up. Reader works on one device without a sync account, and any time you pair two devices your reading list will sync automatically. * Discoverable through the core interface. * Fast and responsive. * Smooth animated transitions in and out of reading mode. * Double-tap to enter full-screen mode. ** On Maemo this was a zooming gesture, but Android has pinch as the core zooming gesture. ** Other Android apps like YouTube use double-tap to enter full screen mode. ** Double-tap on forms or navigation elements should zoom them to a touchable size; double-tap on image, video, or text content should activate special full-screen image, video, or "reader" modes.
    ll-screen image, video, or "reader" modes.)
  • Firefox/Features/New Tab Page  + (==Phase 1: Minimal Needed for Release== D
    ==Phase 1: Minimal Needed for Release== Display: * Titles of top sites Customization: * Ability to remove a particular top site from new tab page ** Ability for user to undo removal of a site from new tab page * Ability to disable new tab page and restore blank page Performance: * No performance impact in browsing session * Loads instantly ==Phase 2: Main Functionality in Place== Customization: * Ability to reorder displayed top sites * Ability to modify the titles of top sites * Ability to to “lock” a site into place * Ability to add a new site to new tab page * Ability to replace displayed items with recent bookmarks, recently closed tabs, history, etc ==Phase 3: Future== Features: * Possibly Partial thumbnails of top sites (pending testing) * Ability to bookmark an item from the new tab page itself * Sites synced across devices and profiles * Ability replace sites with tabs from other computers * Possible ability to add a persona or background image to new tabs * Ability to navigate sites wholly via keyboard * Possible display of large icons rather than thumbnails, dependent on wide availability of high-resolution artwork, either provided by sites or generated by us Spinoffs: * Similar-but-mobile new tab page on mobile Firefox ==== Next Steps ==== * Iterate on prototype in UX branch * Use feedback from prototype and user research to generate final design
    and user research to generate final design)
  • In-content preferences  + (A fully-integrated, usable, redesigned Firefox Preferences which displays in the content area of the browser.)
  • Firefox/Features/URL Autocomplete  + (A working, tested implementation that satisfies the design specification in [https://bugzilla.mozilla.org/show_bug.cgi?id=566489 bug 566489].)
  • Improve find-in-page  + (A working, tested implementation that satisfies the design specification in [https://bugzilla.mozilla.org/show_bug.cgi?id=565552 bug 565552].)
  • Security/Features/Strange SSL Cert Change Alert  + (Any combination of suspicion and notary must not be an effective tool to spy on users. If suspicion leads to distrust, the heuristics should not have high false-positive rates.)
  • DevTools/Features/HTMLTreeEditor  + (Be able to: # add or remove a class (addi
    Be able to: # add or remove a class (adding the class attribute if there isn't one) # [https://bugzilla.mozilla.org/show_bug.cgi?id=705323 bug 705323] change text # add/edit other attributes # edit tag name Optional for the first round (but made it in as part of an earlier feature)): # [https://bugzilla.mozilla.org/show_bug.cgi?id=705847 bug 705847] copy innerHTML/outerHTML for an element # be able to remove nodes these were not done in the first release: # be able to add nodes # be able to move nodes # [https://bugzilla.mozilla.org/show_bug.cgi?id=703383 bug 703383] ability to get a CSS selector for an element # handle elements like script and link appropriately # style tag editing in-place # validation of attributes # autocompletion # focus on an element
    tes # autocompletion # focus on an element)
  • Features/Platform/CSP Sandbox  + (Comply with the CSP spec's description of this feature)
  • Identity/Features/Firefox-native Verified Email Client  + (Content APIs in place for web sites to: *
    Content APIs in place for web sites to: * Request a verified email from the browser ** Support for signing new identity assertions in-browser * Be proactively given a verified email * Advertise active/passive sign-in user sessions and sign-out method * Register a verified email certificate (primary/secondary authority API) ** Support for keeping certificates in the browser ** Support for refreshing certificates as needed Browser UI in place to: * Create a Firefox Account * Sign into a Firefox Account * Add an email address to a Firefox Account, and verify it * Sign into a site by disclosing an email, whether the process is started from chrome or content * Display active session(s) with the site, and sign-out
    ive session(s) with the site, and sign-out)