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 "Level of difficulty: hard. Skills required: JS, HTML". 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

  • 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)
  • Opt-in activation for plugins  + (Core requirements * Mitigate drive-by atta
    Core requirements * Mitigate drive-by attacks for vulnerable (out of date) plugins * Reduce resource consumption by plugins * Drive update of plugins Optional requirements * Manage plugin run settings on a per-site basis * Control plugins on a per-plugin basis for a given site * Mitigate attacks where user interacts with site (clickjacking, or simply wants to run vulnerable plugin)
    or simply wants to run vulnerable plugin))
  • App Vertical Tuts  + (Create an entry point for developers seeking to build web apps that quickly gets them into the vertical-specific app creation track they are looking for.)
  • OS X 10.7 support  + (Currently identified features that should
    Currently identified features that should probably be broken into separate feature pages: * Full-screen mode button in the main window [DONE] * The new conditional/disappearing scroll bars [IN PROGRESS] * Gestures need to be re-mapped (Lion "steals" some of our existing ones) * Resume support (possibly in place of session restore?) [NOT STARTED] https://bugzilla.mozilla.org/show_bug.cgi?id=639707 "[10.7] add resume support for Mac OS X 10.7 Lion" * Double tap zoom support (smart zoom) — I assume Fennec has something like this already * Animate opening window [DONE] * Better scrolling acceleration model, rubber "bounce" at the end * Possibly look into sandboxing (security) for content process, decoding video, etc: http://arstechnica.com/apple/reviews/2011/07/mac-os-x-10-7.ars/9 — Electrolysis might already be handling this? * HiDPI support (doubling of the icons and interface) [NOT STARTED] https://bugzilla.mozilla.org/show_bug.cgi?id=674373 ("[10.7] Support HiDPI mode on OS X Lion" * Search tokens (for search engines and keywords) * Ability to keep parts of the application in memory even when user shuts it down We should also evaluate whether availability in the Mac App Store is important for adoption, if Apple ends up making that the default way to get software on the Mac. Note that there is already a feature page tracking the Mac App store integration. Also see the Chromium issue about full screen mode to see some of the reasons why we can't just hook up our existing fullscreen implementation to the new button: http://code.google.com/p/chromium/issues/detail?id=74065&q=os%3DMac&sort=-modified&colspec=ID%20Stars%20Pri%20Area%20Feature%20Type%20Status%20Summary%20Modified%20Owner%20Mstone%20OS
    pe%20Status%20Summary%20Modified%20Owner%20Mstone%20OS)
  • Security/CSP/Confidentiality  + (Even if an attacker achieves code injection, she should not be able to exfiltrate <i>any</i> data to an origin other than the ones in the whiltelist, save for the non-goals listed below.)
  • Features/Desktop/Enhanced Customization APIs  + (External installers should also have the possibility of using these APIs. Some make these setting changes without installing add-ons.)
  • Input Addon Developers  + (Firefox Client * If an Add-on Developer ha
    Firefox Client * If an Add-on Developer has explicitly stated they want to received feedback, the praise/issue/idea buttons should show on their detail view on the add-ons manager. * On click of any of these buttons, the corresponding input.mozilla.com/feedback submission page should load with the add-on's name pre-loaded onto the comment field. input.mozilla.org * On submission, the comment should show within Input's main dashboard under the requisite product/version/language/feedback_type. addons.mozilla.org * On submission, the comment should show within the add-on developer's developer hub on AMO.
    e add-on developer's developer hub on AMO.)
  • Platform/Features/Camera API - Phase 2 (getUserMedia)  + (For first release: The ability to take a still image shot (without preview or video).)
  • Platform/Features/Camera API  + (For mobile we should use an external app for performance reasons. For desktop we should be able to take an image snapshot.)
  • Security/Features/CA pinning functionality  + (Google has had CA pinning for a while; we
    Google has had CA pinning for a while; we should talk to them about their experience and any risks/problems with current proposals. (We need to separate issues with having a hard-coded list, which we aren't planning to do, from issues with the idea of pinning itself.)
    m issues with the idea of pinning itself.))
  • Thunderbird Metro  + (Hard to define. Ideally, as many features
    Hard to define. Ideally, as many features from mainline Thunderbird as possible. However, if required, the following features can be skipped: search features, chat, big files. All of the windowed components for Thunderbird will need to be moved to the tab infrastructure for Metro, but should remain as preferred in classic. We will also need to figure out how to work with the suspend system. While support for Add-ons should be included by default, inter-compatibility with Thunderbird Classic add-ons may not be viable. Naturally, we will need a version of lightning or an equivalent for this.
    on of lightning or an equivalent for this.)
  • Features/Desktop/TelemetryOptIn  + (If we are going to intrupt the user, we need to at least show them some good artwork, this dialog box requires some Sean Martell artwork.)
  • Features/Desktop/IdentityIntegration  + (Integrate the Identity features in Firefox itself.)
  • Platform/Features/SPDY  + (Interoperate with other spdy/2 implementations using high levels of concurrency.)
  • Thunderbird "Get Satisfaction" Support Dashboard  + (Level of difficulty: easy to medium</br> Skills needed: JavaScript; Helpful: MongoDB & Information Visualization in the browser using JS and an infoviz toolkit like [http://mbostock.github.com/protovis/ protovis] or [http://mbostock.github.com/d3/ D3])
  • Investigate Alternate Composition Window  + (Level of difficulty: hard Skills needed: JavaScript; HTML (no XUL))
  • Thunderbird Profile Backup or Transfer  + (Level of difficulty: hard Skills required: JS, C++, XPCOM, XUL)
  • Implement Other Pluggable Mail Stores  + (Level of difficulty: hard Skills required: JS or C++.)
  • Compose In A Tab  + (Level of difficulty: hard. Skills needed
    Level of difficulty: hard. Skills needed: will require writing XUL (menus will probably need to be moved out into an [https://developer.mozilla.org/en/XUL_Overlays overlay]), JavaScript (passing [https://developer.mozilla.org/en/XUL_Tutorial/Commands menu commands] down to the child iframe) and CSS (to fix theming issues) and writing unit tests to ensure that things work as expected. Since Mac OS X has a global menu, getting it right might require more work. ''You will need access to a Mac for your proposal to be accepted.''.
    a Mac for your proposal to be accepted.''.)
  • Thunderbird Profile Discovery and/or Recovery  + (Level of difficulty: medium Skills required, JS and/or C++)
  • URL Preview within Thunderbird  + (Level of difficulty: medium (easy if initial groundworks is available))
  • Big File Providers  + (Level of difficulty: medium to hard, depending on the provider API and how well it maps to our provider interface Skills required: JS)
  • Platform/Features/WebRTC  + (Must Have: * Security design review * Sec
    Must Have: * Security design review * Security implementation review * The ability to make a call from a web page using a machine's built-in mic and camera. * Should be able to work with most (80-90%) of NAT setups across all geographies. Note that certain configurations will require a relay. * Support for royalty-free voice-friendly audio codecs. Opus strongly preferred. * Support for royalty-free video codecs * Audio/Video/Data must be secure (note that no security is absolute) * A Web API that's been sent to the public working groups for feedback. * A Web API and transport for data that accompanies the audio and video. * Congestion control (Automatic bandwidth adjustment) required to be in and debugged prior to Firefox's WebRTC code's fire release * Ability to add/remove video from an active call and prior to a call being placed or received Nice to Have: * Video resolution switching * If hardware support exists for encoding & decoding VP8, support for video on Mobile.
    mp; decoding VP8, support for video on Mobile.)
  • Firefox/Features/Persist Panorama Groups  + (Open Firefox with multiple windows with groups in them, close one window at a time, start Firefox again — you shouldn't lose your groups, ever.)
  • Firefox/Features/Panorama Global Storage  + (Panorama's storage is global and window-independent but still passes all existing tests.)
  • Privacy/Features/mozCipherAddressbook  + (Parsing the DOM on idle to discover "addressbook-entry" meta tags would make the most sense - there is a little bit of research to do here on perf.)
  • Features/Security/Low rights Firefox  + (Protect users against the following threat
    Protect users against the following threats to whatever degree we can : * Local Filesystem/Registry Read ** A compromised Firefox can read any file or registry key/value that the Firefox user has access to - this includes stealing their cookies, local storage, saved passwords and other private information for all sites as well as reading the user's browser history * Local Filesystem/Registry Write ** A compromised Firefox can write any file or registry key/value that the Firefox user has access to - this includes modifying Firefox's trusted SSL certificates and Firefox settings, which could affect product updates, network proxies, or other bits of security or privacy sensitive browser configuration. Other threats includes poisoning the browser's network cache or HTML5 appcache * Launch New Processes ** A compromised Firefox could launch additional malicious processes to possibly escalate the attacker's privilege or attempt to make the compromise more permanent * Network Access (including remote filesystem access) ** A compromised Firefox can send and receive network traffic - this can be used to attack and exploit other hosts, including hosts only reachable from the internal network where the compromised Firefox is running. This can also be used as a command and control channel or to download additional post-exploitation payloads or instructions or to exfiltrate data from the compromised system. * Loading additional libraries into content process ** A compromised Firefox can load additional libraries into the compromised content process - these could be used to snoop on the user or steal passwords or cookies. ** The existing DLL blocklist is a small amount of mitigation here, but this can be worked around easily by changing the DLL name, for example. ** This requires that either the attacker places libraries on the target machine via the compromised process' ability to write to the filesystem or dynamically modifies the content process' memory to install hooks * IPC (shared memory / window messages) based attacks against other processes ** A compromised Firefox can send Windows messages to privileged applications on the same desktop vulnerable to these types of attacks to elevate privileges ** A compromised Firefox can write to shared memory accessible to its process, potentially conducting attacks against other processes * Kernel mode attack surface - WebGL, other OS graphics API's ** A compromised Firefox can make syscalls or call any WebGL or OS supplied graphics API (when they are implemented in kernel mode drivers) - these drivers or the kernel may contain vulnerabiliities allowing escalation to ring 0/kernel level privileges * Channel to trusted/broker/medium-privilege process ** A sandboxed content process needs a channel to the trusted/higher privilege process to perform sensitive operations - this channel itself may contain exploitable implementation flaws ** Proxy/broker APIs either need to be totally harmless or to have some way of validating the arguments that are passed to them - remoting the call to the broker process doesn't add any security if a compromised process can do what it wants by simply calling exposed API's in the broker
    simply calling exposed API's in the broker)
  • Features/Firefox/In-content UI Visual Unification  + (Relevant in-content UI is able to use the shared resources to look consistent with other in-content UI.)
  • Firefox/Features/InstallerUIRewrite  + (See UX specs here: https://bug651965.bugzilla.mozilla.org/attachment.cgi?id=543348)
  • Extension Manager:Projects:Improve Add-on Installation  + (Several user experience improvements detailed in [https://bugzilla.mozilla.org/show_bug.cgi?id=646602 bug 646602].)
  • Firefox/Features/Panorama Groups On Demand  + (Starting Firefox with multiple Panorama groups should not result in all of them being loaded on startup.)
  • Addon Console  + (The Add-on Console will allow add-on autho
    The Add-on Console will allow add-on authors to view logged objects and messages in a console GUI on par with, or identical to, the console we provide to web content. The console will allow for rich inspection of logged objects, as opposed to the current Firefox error console's simple string output.
    efox error console's simple string output.)
  • Features/Desktop/Downloads API  + (The concrete goal is to ensure that SQL statements involving <code>moz_downloads</code> no longer appear in the "slow SQL" Telemetry dashboard.)
  • Features/Jetpack/Add-on SDK Localization API and Service  + (The feature must enable localization of addons and distribution of localized addons without requiring the developer of an addon to do anything other than identify the strings needing localization and submit the addon to AMO.)
  • Features/Jetpack/SDK Support for Firefox for Mobile Addons  + (The feature must load an addon built using
    The feature must load an addon built using the SDK in both FFD and FFM. It should make addons that use only the high-level APIs provided by the SDK work by default on both FFD and FFM, although it may require addons to provide browser-specific code if it is not possible to make all APIs "just work" in both browsers. It must enable an addon to determine which browser the addon is loaded in. It may provide additional API features that are specific to mobile devices. We must also continue the work that has already begun to reduce the footprint of an add-on built with jetpack.
    footprint of an add-on built with jetpack.)
  • Features/Jetpack/Out-of-Process Addons  + (The feature must load an addon built using
    The feature must load an addon built using the SDK in a separate process by default. It must support the existing high-level APIs as provided by the first stable release of the SDK (Add-on SDK 1.0), which use content scripts to give addons access to content and abstract away the details of Firefox chrome modification. It must also support similar high-level APIs that land in subsequent stable releases. It may support simpler alternatives to the existing high-level APIs, such as cross-process proxies that provide access to DOM objects in the addon process. It may allow addon developers to disable the feature to accommodate addons that use second- and third-party APIs that are not OOP-compatible.
    rd-party APIs that are not OOP-compatible.)
  • Features/Jetpack/Traditional Addon Conversion to SDK Platform  + (The feature should make it possible to run
    The feature should make it possible to run, test, and package a traditional addon using the SDK's functionality. It should automatically convert addon metadata from the traditional format to the new one. It should provide developers with documentation that explains which SDK features map to which features of the traditional platform and gives tips and tutorials for converting a traditional addon to an SDK-based addon. It should identify kinds of chrome modification and suggest SDK APIs that developers can use to make similar kinds of modifications. It should identify XPCOM services and automatically convert them to CommonJS modules. It should identify code that runs at startup and automatically convert it to the addon's main code.
    cally convert it to the addon's main code.)
  • Services/Sync/Push to device  + (The following data is sent across devices: * Session cookies * Form fields * Page position (element, not pixel position - to avoid form factor mismatch))
  • Security/Features/XSS Filter  + (The goal of this feature is to automatical
    The goal of this feature is to automatically protect users from reflected XSS attacks. Characteristics: * The filter should have low overhead. We are currently implementing it in plain C++, avoiding XPCOM overhead where possible. * The filter should have almost no false positives (that is, it should not break existing websites in absence of an actual attack). * The filter should not rely on user input. A false positive cannot be considered a "minor annoyance" just because the user can be shown a dialog to decide whether to actually block the script. In fact, if the filter is compatible enough, it should not be easily disabled. * The filter should not introduce new vulnerabilities in existing websites (i.e. universal XSS a la IE8).
    ng websites (i.e. universal XSS a la IE8).)
  • Security/Features/SameDomainCookie  + (The goal of this feature is to provide a robust CSRF protection mechanism which is simple to understand and easy for site owners to implement. (more detail to follow))
  • Features/Platform/Graphite font shaping  + (The presence of Graphite support must not
    The presence of Graphite support must not regress behavior or performance for non-Graphite fonts. Rendering text with a Graphite font should have equivalent performance to rendering with an OpenType font of similar complexity. (Dual-technology fonts such as Charis SIL could be used to compare.)
    h as Charis SIL could be used to compare.))
  • Convert remaining window-modal dialogs to tab-modal  + (The various dialogs will require slightly
    The various dialogs will require slightly different approaches since they have varying capabilities and roles, but overall they should never block the entire window, at most just the relevant tab, and at best not be shown at all (like when you have saved password and HTTP auth).
    en you have saved password and HTTP auth).)
  • SMS support  + (This feature should allow Thunderbird users to send SMS messages to users of all major carriers, and eachother in a reasonably reliable, and not-completely insecure manner; and allow them to view these messages the same.)
  • Features/Platform/Iframe Sandbox  + (This feature should be designed and implem
    This feature should be designed and implemented in a way that makes it usable for also implementing the sandboxing required to support the CSP (Content Security Policy) sandbox value also. This feature requires a comprehensive test suite, as automated as possible for inclusion in the Firefox unit tests - Boris Zbarsky has suggested we also submit this test suite to the W3C for inclusion in their HTML5 test suite.
    C for inclusion in their HTML5 test suite.)