Search by property

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.

List of results

• Privacy/Features/DOMCryptAPI  + (==== Next Steps ==== * Get the discussion …
  ==== Next Steps ==== * Get the discussion going with other browser vendors, WHAT-WG, W3C, TC-39 ** Check! See the webkit bug: https://bugs.webkit.org/show_bug.cgi?id=62010 * Develop an implementation schedule * Port extension over to Firefox/DOM code: underway * Test suite - underway * Will integrate DOMCryptAPI with window.crypto ==== Background ==== * This code is heavily based on parts of WeaveCrypto that was excised from mozilla-central, when Sync switched to J-PAKE crypto
  ntral, when Sync switched to J-PAKE crypto)
• Features/Desktop/Panel Menu  + (====Open UI questions==== * In the panel U …
  ====Open UI questions==== * In the panel UI, should built-in widgets be separate from add-on widgets? ** Thinking no - why create artificial boundaries? * In customization UI, should built-in widgets be separate from add-on widgets? ** Thinking yes - for easier discovery * How do toolbars fit into the customization UI? ** Would be nice to have, as the current UI isn't friendly (have to right-click on a built-in toolbar - many addon toolbars have their own right-click menu) ** But we can't (reliably) get a preview of them * Scaling with many addons ** Customization UI is relatively easy to scale - scrolling, and maybe text search ** Panel UI harder to scale * Things add-ons will want: Everything. Only a subset of "everything" will fit in the Panel UI ** Allow addons to restrict where a widget can go? How is that expressed in the customization UI? ====Existing issues==== * Buttons added by add-ons aren't automatically available in the toolbar, add-ons need extra code and to make sure it's only run on first-run * Overlays don't play nicely with restartless add-ons * Customizing one window doesn't update other windows ====Interaction with Add-ons Manager==== * Adding widgets from add-ons kinda fits with the Add-ons Manager, but built-in widgets do not - doesn't make sense to have such a big split between the two ** Ergo, customization UI shouldn't be in the Add-ons Manager. * Customization UI includes lightweight themes (backgrounds), but probably shouldn't include heavyweight themes. The Add-ons Manager will keep supporting those, but the relevant UI will only shown if one is installed. ====Method 1 - Re-use existing method of overlaying toolbarpalette==== * Buttons aren't automatically added to the toolbar when added to the palette - add-ons need extra code to do that, and make sure it's only done on first run. Easy to get wrong. This occasionally causes issues with addons re-adding a button after a user has chosen to remove it. * Widgets from existing add-ons won't always fit into new panel UI - eg, a longer-than-usual button, a button that opens a dropdown panel, etc * Doesn't play well with restartless add-ons ====Method 2: Introduce new API==== Cu.import("resource://.../CustomizeableUI.jsm"); var button = CustomizeableUI.registerWidget({ id: "weather-indicator", // how to enforce reasonable value that should be unique? type: "button", name: "Weather", shortcut: "Ctrl-Alt-W", description: "The weather outside", defaultPlacement: "toolbar", allowedPlacement: ["toolbar"], icons: { 16: "chrome://weather-indicator/icon16.png", 32: "chrome://weather-indicator/icon32.png" } }); // Affect all windows: button.disable = false; // Affect one window: button.windows[window].disable = true; // .windows is a Map // When a restartless add-o is disabled, remove it: button.unregister(); Alternatively, it could use a manifest file in JSON format. But not sure how that would fit with other applications. And l10n becomes awkward. Benefits: * Application wide registration, not per window. * Fixes issue of default buttons (When addon is installed, is it's button visible? Where?) * Much easier for restartless addons * Harder for addons to screw up normal styling * Should be able to support existing add-ons, by detecting added widgets. But for safely, might only be able to show them in the toolbar (not the Panel UI) Drawbacks: * Another API * More difficult for custom widgets? (Might be good thing)
  for custom widgets? (Might be good thing))
• Features/Jetpack/Add-on SDK Localization API and Service  + (A good deal of work to implement this has …
  A good deal of work to implement this has already been done by Gandalf - what is missing is the coordination among Jetpack, Gandalf, and AMO as was originally planned. In addition, AMO's time to work on this is very limited and perhaps too far away for us to effectively launch this feature in a timely manner. To that end, we may want to move the "pushing to the 3rd party service" side of this to the Add-on Builder. In addition, since most of the hard work has been done, we can launch this in phases: '''Phase 1:''' The initial step is simply to land gandalf's "Common Pool" module. This will allow devs to flag strings to translate with a _("string to translate") - When done, the dev can then upload the xpi to https://l10n.mozillalabs.com/projects/p/mozilla-jetpacks/upload/ and the strings will enter the common pool to be translated, and returned to the developer. '''Phase 2:''' In this stage we should iterate on the l10n support, including taking a look at localizing html files (a method for hosted html as well as included html). At the same time, we should look at adding automatic uploads to transifex directly from the Online Builder so that devs don't have to worry about doing that themselves. '''Phase 3:''' when the AMO devs have time to implement it, we should have the automatic uploads work directly from AMO when a dev uploads his/her xpi to AMO.
  AMO when a dev uploads his/her xpi to AMO.)
• Labs/F1/Feature Blocks/F1  + (A third share account to the working share feature, creating 3 working account types.)
• Complete Send In Background  + (At its heart, this feature uses the send l …
  At its heart, this feature uses the send later functionality to operate. When enabled, emails are saved in the Outbox (in Local Folders) without the "Queued" flag set on them. nsMsgSendLater then detects the presence of the email and sends it in the background, with status reporting to the activity manager. Currently the basic implementation works, but error and edge cases aren't correctly handled. For testing purposes mailnews.sendInBackground can be set to true. [https://bugzilla.mozilla.org/show_bug.cgi?id=511079 bug 511079] is the tracking bug with dependencies showing the current issues.
  h dependencies showing the current issues.)
• Features/Jetpack/Add-on SDK: the Missing Pieces  + (Due to the UI mapping nature of supporting …
  Due to the UI mapping nature of supporting Firefox mobile, we will start only with the Preferences API until we have mobile support. Once we have that we should have a better understanding of how UI elements will map from desktop to mobile and be able to handle the remaining features in the Overview section.
  emaining features in the Overview section.)
• Features/Thunderbird/Improved Build System  + (For the build-config part, there's several …
  For the build-config part, there's several possible stages: 1) In comm-central, prototype the extraction of Thunderbird and Mailnews specific arguments into a sub-configure file that is called from the configure file, but is as minimal as possible and does not duplicate the build system into the sub-configure ([https://bugzilla.mozilla.org/show_bug.cgi?id=648980 bug 648980]) 2) Reduce the differences between the main comm-central and mozilla-central configures. 3) Investigate keeping comm-central in sync with mozilla-central using scripts or modified files. 4) Assuming that's not viable, investigate fully switching comm-central to be a sub-directory under mozilla-central ([https://bugzilla.mozilla.org/show_bug.cgi?id=648979 bug 648979]) Also, for packaging system, there's a couple of bugs worth trying to fix: - [https://bugzilla.mozilla.org/show_bug.cgi?id=713133 bug 713133] This will make package failures fatal, so if we're trying to package things that no longer exist, we'll get warned about it. - [https://bugzilla.mozilla.org/show_bug.cgi?id=526333 bug 526333] Defines a core package-manifest for all apps to use and share, which helps with reducing breakages when core items are added.
  ucing breakages when core items are added.)
• DevTools/Features/PseudoClassLock  + (Implementation is going on in [https://bugzilla.mozilla.org/show_bug.cgi?id=707740 bug 707740].)

• AddonSDKCryptoAPI  + (Implementation plan is being worked on now (July 6 2011))

• Privacy/Features/HttpsGoogleSearch  + (Land on nightly, then update other Google search plugins (other locales, etc) to use HTTPS as well.)
• Security/Features/Application Reputation  + (Lets do this in stages: # Implement prefed …
  Lets do this in stages: # Implement prefed-off support for downloading and updating Google's reputation whitelists # Implement easier UI (or none) for downloads matching the whitelist # Run tests to see how often unknown URLs are transmitted to the API # Based on tests, perhaps enable the feature by default # Eventually provide pluggable support for other reputation systems (like the search plugins)
  putation systems (like the search plugins))
• Features/Jetpack/Simplify the Add-on SDK  + (Many of the items listed in the overview w …
  Many of the items listed in the overview will begin in conjunction with our P1 work so developers do not have to devote 100% of their time to just one feature. Therefore, the status of this full-set feature will be in progress until all items are completed or determined to be part of another feature, or no longer needed or wanted.
  er feature, or no longer needed or wanted.)
• Add-on SDK in Firefox  + (Meta-bug: [https://bugzilla.mozilla.org/sh …
  Meta-bug: [https://bugzilla.mozilla.org/show_bug.cgi?id=731779 bug 731779] * Set up Git->HG syncing infrastructure (Non-blocking: If not ready by landing time, can do weekly drops.) * Work with browser/toolkit module owners to determine code location in each component. * Land CommonJS loader in Firefox (In toolkit, have Mossop to review.) * Jetpack housecleaning required before landing ** Misc cleanup (removing window-utils, etc.) ** Packagelessness ** Separate core APIs into Browser and Toolkit sets * Land core APIs in Firefox Each of these Loader usage scenarios should be supported and documented with code samples: * Inclusion into XUL window scope * Inclusion into non-window scopes (JS XPCOM, JS Modules) * Support shared & private instances
  Modules) * Support shared & private instances)
• Platform/Features/Camera API  + (Mobile implementation is almost landed. M …
  Mobile implementation is almost landed. Main bug for desktop: [https://bugzilla.mozilla.org/show_bug.cgi?id=692955 Bug 692955] Currently waiting on three things to happen for desktop: * Implementation of the Chrome UI (fabrice) * Implementation of the in-page UI (mounir or dholbert) * WebRTC integration and landing (jesup): ** Landing Windows build support (ted) ** Pruning code base for image capture (as needed) (jesup) ** Legal review (under way, no problems expected) ** Security review of code paths needed for image capture (jesup, curtis) ** Picking a 'stable point' in WebRTC upstream to use as the mergepoint (jesup) ** Landing review of the capture code from webrtc (jesup) ** Post-landing testing and debugging (jesup, fabrice, qa, etc) Ignore stuff below this line, here for history only. Android support landed: * https://bugzilla.mozilla.org/show_bug.cgi?id=659188 * https://bugzilla.mozilla.org/show_bug.cgi?id=621915
  ugzilla.mozilla.org/show_bug.cgi?id=621915)
• Features/Desktop/IdentityIntegration  + (More detail once scope of work is determin …
  More detail once scope of work is determined, but this is the high-level plan: * Acquire a project branch to work on * Land the Identity add-on on the project branch, bundled as add-on with Firefox * Determine the delta from a landable state with regard to Talos results and unit test failures * Scope work required to get to landable state: File bugs, get estimates for them * Re-evaluate feasibility * Coordinate work between Identity, Firefox, Jetpack and Platform teams
  ntity, Firefox, Jetpack and Platform teams)
• Features/Platform/OfflineApps  + (Must-have bugs: * HTML5 App Cache: [https …
  Must-have bugs: * HTML5 App Cache: [https://bugzilla.mozilla.org/show_bug.cgi?id=683794 We do not fire the onupdateready event] - needs investigation & a test * [https://bugzilla.mozilla.org/show_bug.cgi?id=687361 IndexedDB: Set Version API will change] * [https://bugzilla.mozilla.org/show_bug.cgi?id=625071 IndexedDB: Can't delete a database] - do this with Set Version * IndexedDB: [https://bugzilla.mozilla.org/show_bug.cgi?id=661877 Enable storing files] See also: [Features/Platform/LargeFilesForIndexedDB feature page for this bug] - Jan is working on this * App Cache: [https://bugzilla.mozilla.org/show_bug.cgi?id=538595 Clear Recent History should be able to clear offline cache] - Who? Waiting on specs from Jonas & Robert: * Need an API for querying permission to make a Database * Need an API for revoking permission to make a Database (shared computer use case.) * Jonas will be working on a testing plan to test IndexedDB performance with Clint. Nice-to-have bugs: * AppCache: [https://bugzilla.mozilla.org/show_bug.cgi?id=687758 Remote @font-face fails when used with appcache] * IndexedDB: [https://bugzilla.mozilla.org/show_bug.cgi?id=692614 Can only create simple key types] * IndexedDB: [https://bugzilla.mozilla.org/show_bug.cgi?id=686477 Can only create indexes on the root object] * API to trigger asking for the data storage permission dialog (HTML5 App Cache) or stop asking * There's no easy way to know if you're getting the offline/cached version of a file or the one off the network. (Nice to have for testing.) * Support for [https://bugzilla.mozilla.org/show_bug.cgi?id=679267 LevelDB]
  gzilla.mozilla.org/show_bug.cgi?id=679267 LevelDB])
• Support/Firefox Features/Clean up user profile  + (Notes to keep in mind: * There are two dif …
  Notes to keep in mind: * There are two different kinds of startup crashes: *# Caused by a user's profile *# Caused by code that loads in all profiles - may still crash on a new profile *#* I think that third-party code (except plugins) wouldn't get loaded in safe mode but if malware has infected Firefox install files then this will still be a problem. *#** The installer repair workflow may fix some of this. * The Reset Firefox process should run in safe mode to prevent crashes – runs in a new profile instead and pulls data * Non goal: Another option is to add a button to restart in safe mode from about:sessionrestore when it had trouble restoring the session. [https://bugzilla.mozilla.org/show_bug.cgi?id=347680 bug 347680] * Safe mode should always be used before reset since reset causes data loss which may be unnecessary if safe mode would have solved the problem. As a result, I think that a button to restart in safe mode is a higher priority for about:support than going directly to a reset. ** The safe mode dialog could provide a method to reset the profile ** Less discoverable * We need to make the distinction between the reset process and making permanent changes in safe mode more clear as they appear to do the same thing in the UI. In reality, resetting involves more data loss since it's actually going to migrate only high priority data to a new profile. * Use prefs in the profile to keep track of crashes for startup crash detection * Add command-line argument(s) and/or environment variable(s) to launch the reset process ** This is needed so that the installer has a way of telling Firefox to repair after installation * Migration to a new profile ** Use profile migrator infrastructure *** Can only migrate from the default/selected profile since the Toolkit Profile Service is going to be replaced in [https://bugzilla.mozilla.org/show_bug.cgi?id=214675 bug 214675] * Migration of Places data (notes from rnewman) ** Queries refer directly to a Places ID. If you do a low-level migration to a new DB, make sure that you don't break those foreign pseudo-keys! ** Note that Sync relies on the GUIDs assigned to records. Those must persist. ** For now, the entire places.sqlite file and bookmarkbackups directory are copied to the new profile. * Interaction with Sync (notes from rnewman; feel free to ask for clarification): **

  [TODO] N.B.

  , clearing all user-set prefs will eliminate the user's Sync configuration, with unpleasant consequences. (Take a look in about:config for services.sync.*.) If you start a blank profile, it'll pull down all the old prefs from the Sync server. If you preserve timestamps, the new values won't necessarily be uploaded, unless you send Sync the correct observer notifications for change events. ** Note that Sync whitelists prefs to sync between devices (services.sync.prefs.*). You might want to think about that. ** Similar caveats apply to other data stored in Sync. Making this feature work correctly with Sync will need a little bit of thought. * DONE - Make sure that UI isn't exposed in cases where we won't migrate due to ToolkitProfileService limitations
  posed in cases where we won't migrate due to ToolkitProfileService limitations)
• Marketplace/Features/Country Stores  + (Phase 1: For June, the features above except for the regional popularity score and dependencies (regional popular lists and search results) are included. Phase 2: At a later date TBD, the regional popularity score and dependencies should be completed.)
• Opt-in activation for plugins  + (Phase 1: Users can turn on a preference to …
  Phase 1: Users can turn on a preference to require click to play for all plugins globally Phase 2: Mozilla can remotely configure the user's browser to require click to play for specific plugins that are out-of-date and/or vulnerable. (Note that we may allow vendors a few days or a week to update their users before remotely requiring click to play on a plugin. This will depend on the severity of the vulnerabilities in the plugin.). Phase 3: Fix the bugs that prevent click-to-play from being awesome (see [https://bugzilla.mozilla.org/show_bug.cgi?id=774937 bug 774937]). These bugs are, for example, click-to-play breaking Youtube on OS X. Phase 4: Explore possible future Use Cases 1-3. This needs more research. Can we leverage user behavior to define a heuristic of when a plugin should be click to play? Can we collect Telemetry data to help us understand how often plugins are used?
  us understand how often plugins are used?)
• Security/Features/Browser CRL  + (Previously this feature request was called …
  Previously this feature request was called "Cert BLocklist via Update Ping" https://wiki.mozilla.org/Security/Features/Cert_Blocklist_via_Update_Ping It was originally thought that the easiest way to implement this feature would be to piggyback on the blocklist. Whoever works on creating this Browser CRL feature should consider that, as well as other implementation strategies.
  s well as other implementation strategies.)
• Features/Security/Low rights Firefox  + (Right now we are focused on researching th …
  Right now we are focused on researching the issues with running Java out-of-process and finding out what APIs the top 100 addons on addons.mozilla.org use and how they use them. Our goal is to understand possible approaches to working around or solving these problems with respect to sandboxing the Firefox.exe process without needing to have a whitelist so permissive that it has an extremely diluted security benefit. Additionally, we are working on a proof-of-concept implementation of a build of Firefox that runs in a low-right, sandboxed process, using the Chromium sandbox library.
  ocess, using the Chromium sandbox library.)
• DevTools/Features/JavaScriptProfiling  + (See [https://bugzilla.mozilla.org/show_bug.cgi?id=795268 bug 795268] for the details of the integration.)
• Features/Fennec/Android Snippets  + (See [https://bugzilla.mozilla.org/show_bug …
  See [https://bugzilla.mozilla.org/show_bug.cgi?id=774497 bug 774497] and dependencies. Server-side work not yet tracked. Snippets will be periodically fetched via HTTP, with server-side filtering based on client attribute. Client-side filtering, caching, and presentation. Background Android alarm to manage periodic fetches.
  Android alarm to manage periodic fetches.)
• DevTools/Features/Layout  + (See [https://bugzilla.mozilla.org/show_bug.cgi?id=683954 bug 683954])
• Firefox Social Integration  + (See the design spec for some thoughts. A …
  See the design spec for some thoughts. A GitHub repo containing a full working implementation of the feature, as an addon, is at [https://github.com/mozilla/socialapi-dev/]. A GitHub repo containing just the backend pieces, is at [https://github.com/mozilla/socialapi-core].
  ttps://github.com/mozilla/socialapi-core].)
• Security/Features/Strange SSL Cert Change Alert  + (The MVP for this feature is: - whenever we …
  The MVP for this feature is: - whenever we see a trusted certificate, remember its CA; - whenever we see a new certificate for a site, if the new CA is different from the old CA, treat the new certificate as being untrusted. We can potentially add more complexity in subsequent releases. Additional heuristics to identify a "suspicious" certificate might include: - this certificate is new, and the old one was nowhere near expiry; - this certificate is new, and the old one was from a different intermeiate CA of this CA. Additional actions to take if a certificate is suspicious might include: - provide the user with a soft warning; - contact a Perspectives-Convergence-style notary run by Mozilla, to see whether we see the same certificate; - contact a Mozilla-run notary to report a suspected attack.
  a-run notary to report a suspected attack.)
• Features/Jetpack/Module-Sharing  + (The implementation for this system will be …
  The implementation for this system will be done in Three stages: ''Phase One:'' Create the foundations for sharing to happen the way we envision it. This will include having a place for dependencies to live and making sure that the loader will know how to pull in those dependencies. ''Phase Two:'' In this phase, we will work on making sure the tools know how to discover and use external & system modules. ''Phase Three:'' In this phase we will tackle the area of how and where developers find modules. We hope that once we have the first two phases working, we will have a better sense from the community on how they see this system working and will help us better define what this looks like. More details on descriptions and implementation [https://github.com/mozilla/addon-sdk/wiki/JEP-packageless can be found in this proposal]
  JEP-packageless can be found in this proposal])
• Features/Jetpack/Add-onTab-API  + (The implementation of this API should be f …
  The implementation of this API should be fairly straight-forward as the page content implementation should be similar, if not the same, as the content allowed in currently in a panel. Therefore, new implementation should just be the creation of a new tab, and the creation of the reduced-chrome interface for that tab.
  the reduced-chrome interface for that tab.)
• Security/Features/CA pinning functionality  + (The pinning data will be stored as a site …
  The pinning data will be stored as a site pref. And it will be implemented in a way similar to STS. The first stage would be to enhance the preferences to be able to store blobs or strings. Shall this be included in the STS .idl file? Dont know yet. We shall notice that this is an HTTP extension. Not an TLS/SSL extension. There are 3 parts fo the implementation: 1. Enhance permission manager to include strings for storage (https://bugzilla.mozilla.org/show_bug.cgi?id=744212 ) 2. Ability to "Note" a pinning when presented over an error free TLS connection 3. Ability to use the permission manager at chain building time to ensure a valid (from the pinning perspective planner exists).
  m the pinning perspective planner exists).)
• Features/Desktop/Firefox reset option on reinstall  + (There are two major approaches: # Firefox …
  There are two major approaches: # Firefox itself detects the re-install. (Cross-platform and written in JS) #* Firefox can remember file modification times and the last version used to detect a re-install. # The Windows installer detects the re-install. (Windows-only using NSIS)
  the re-install. (Windows-only using NSIS))
• Platform/Features/Input video  + (This is Rainbow: http://mozillalabs.com/rainbow/)
• Features/Jetpack/CFX in JS  + (This work can easily be splitted in multip …
  This work can easily be splitted in multiple, eventually parallel steps: - Be able to execute Javascript code hosted in an addon from cfx in python Then we would be able do implement following CFX workflow steps in JS: - Install and execute an Addon - Generate the XPI out of the manifest - Compute the manifest out of packages/modules - Read/seek for packages/modules on filesystem - Interpret command line options - Build a command line application with mozilla-platform/Firefox - Write shell/bash scripts in order to setup cfx environnement (equivalent of source bin/activate)
  nement (equivalent of source bin/activate))
• Features/Thunderbird/Instant messaging in Thunderbird  + (To move forward quickly, the most practica …
  To move forward quickly, the most practicable plan is to put Instantbird's code into a Thunderbird build, and then iterate to remove what can't be shipped (GPL'ed code) and improve the integration. Main tasks: * remove the dependency of the IM core of Instantbird on libpurple. (almost done, work tracked in Instantbird [https://bugzilla.instantbird.org/show_bug.cgi?id=759 bug 759]) * integrate more protocol plugins implemented in JavaScript. ** Instantbird 1.0 and 1.1 shipped with only Twitter implemented in JavaScript. ** An XMPP implementation in JS has been developed this summer by a Google Summer of Code student. (currently being reviewed in Instantbird [https://bugzilla.instantbird.org/show_bug.cgi?id=1171 bug 1171]) ** An IRC implementation in JS has been developed by an Instantbird developer. (needs a review, tracked in Instantbird [https://bugzilla.instantbird.org/show_bug.cgi?id=507 bug 507]) * conversation logs should be written in an easily parsable format (best candidate seems JSON), and indexed in gloda. * integration into the current address book * UI integration, the current plan, designed so that we can try a working prototype as soon as possible, is roughly: ** start by the changes needed so that IM accounts can be added/configured ** then add the UI where conversations can happen ** finally, iterate on other integration points and polish details until we are satisfied.
  and polish details until we are satisfied.)
• Show PDF inline  + (Use the [[PDF.js]] renderer Alternatives …
  Use the [[PDF.js]] renderer Alternatives that were considered, but decided against: # Use the platform support for PDF in the cases where it's available, e.g. on Mac OS X via PDFkit: http://code.google.com/p/firefox-mac-pdf/ # We could also do a hybrid approach, e.g. use Adobe plugin on Windows, and PDFkit on the Mac.
  plugin on Windows, and PDFkit on the Mac.)