Digest for firefox-dev@mozilla.org - 6 updates in 3 topics

[firef...@mozilla.org]

firef...@mozilla.org

Google Groups

Topic digest
View all topics

• Intent to ship: Enabling the clear search button in <input type="search"> for privileged documents - 1 Update
• Upcoming changes to Firefox Security Advisories - 4 Updates
• Firefox desktop development meeting - 2025-05-13 - 1 Update

Intent to ship: Enabling the clear search button in <input type="search"> for privileged documents

Tim Giles <tgi...@mozilla.com>: May 13 02:52PM -0400 Hello all, I intend to enable the clear search button of the HTMLInputElement/<input type="search" in privileged documents at the start of Firefox 141.   What are the concerns/impacts of this change?   -   Web content will not be impacted by this change, only privileged documents will receive these improvements -   There will be duplicate UI elements where clear search buttons have been previously implemented. These places include: -   Firefox View -   DevTools -   GeckoView -   If your team was listed in the previous point and is impacted by these changes, I will reach out to your team so that myself and the Reusable Components/Acorn Design System Engineering team can help coordinate the work to prevent visual regressions when this work lands.     -   There may be other places that will have duplicate UI elements in search inputs that I am not aware of. Please either let me know in this thread or file a bug that will block Bug 1956634 - Enable <input type="search"> in privileged documents <https://bugzilla.mozilla.org/show_bug.cgi?id=1956634>. -   You can also add a patch to the stack on Bug 1956634 to help prevent visual regressions (which would be a huge help to me)     What's the motivation for this change?   -   This is being enabled as part of the Settings Redesign project, but anyone using `<input type="search">` in a privileged document will receive this improvement. -   This change will improve the accessibility of the clear search button in search inputs, bring the clear search button into the Acorn Design System, and move us closer to enabling this functionality in web content.     The bug for tracking this work is Bug 1956634 - Enable <input type="search"> in privileged documents <https://bugzilla.mozilla.org/show_bug.cgi?id=1956634>.   Thanks all,   Tim

Back to top

Upcoming changes to Firefox Security Advisories

Frederik Braun <fbr...@mozilla.com>: May 13 02:44PM +0200 Hi all,   For those who don't know, we publish detailed security advisories <https://www.mozilla.org/en-US/security/known-vulnerabilities/firefox/> for every new Firefox release. A typical advisory lists 10 to 20 security issues with a title, their severity, the reporter and a description. Writing these advisories is a cumbersome, manual process that takes too much time.   We believe that this is not time well spent. We don't believe that people should make their decisions whether to update Firefox based on the individual CVEs that were fixed in a specific release. As an evergreen product in a connected world, Firefox is only kept secure if full browser updates are applied as soon as possible and not weighed on the little information that we can include in our description. People that *do* need more information and are building software downstream of our source code may be nominated for our security group <https://www.mozilla.org/en-US/about/governance/policies/security-group/membership/>. This group gets insights into the actual bugs and their fixes ahead of release. We will continue to make security bugs public once they have been fixed and when a significant portion of our users had the chance to apply an update. This typically happens a couple of months after the specific release.   As a result of these considerations, we would like to switch our security advisory format to a simpler template that contains less details. We intend to keep the following information: CVE-ID, Severity, Reporter, Title, Component and a reference to the bug on bugzilla.   We do not plan to implement these changes right away and want to gather feedback before doing so. If you are someone who relies on the information that we currently provide, please reply to this thread on dev-platform. If the details are very sensitive, feel free to send to secu...@mozilla.org instead.   Thank you, Frederik Braun on behalf of the Firefox Application Security Team

Nick Alexander <nalex...@mozilla.com>: May 13 08:34AM -0700 Hello sec team!   On Tue, May 13, 2025 at 5:44 AM 'Frederik Braun' via firef...@mozilla.org > advisory format to a simpler template that contains less details. We intend > to keep the following information: CVE-ID, Severity, Reporter, Title, > Component and a reference to the bug on bugzilla.   I am not so familiar with our sec process details. When the advisory is published, is the information needed to write the description publicly available? I.e., is the "reference to the bug on bugzilla" -- a link to the bug, I assume -- open so that a motivated individual could plausibly produce the description themselves?   Thanks! Nick

Gijs Kruitbosch <gijskru...@gmail.com>: May 13 05:03PM +0100 > description publicly available? I.e., is the "reference to the bug on > bugzilla" -- a link to the bug, I assume -- open so that a motivated > individual could plausibly produce the description themselves?   No. Advisories are published around the time the release goes out, and bugs (which typically contain a lot more detail about the specifics of the issue and the fix) are not opened up until users have broadly updated to builds containing the fix for the security issue. This is to avoid exposing users that are still on older builds to exploitation.   ~ Gijs   On 13/05/2025 16:34, 'Nick Alexander' via firef...@mozilla.org wrote:

Nick Alexander <nalex...@mozilla.com>: May 13 09:19AM -0700 On Tue, May 13, 2025 at 9:03 AM Gijs Kruitbosch <gijskru...@gmail.com> wrote:   > issue and the fix) are not opened up until users have broadly updated to > builds containing the fix for the security issue. This is to avoid exposing > users that are still on older builds to exploitation.   Thanks for clarifying, Gijs. So: there is less information published, and a justification for that reduction based on the effort involved. Fine by me! Nick

Back to top

Firefox desktop development meeting - 2025-05-13

Maxx Crawford <mcra...@mozilla.com>: May 13 09:08AM -0500 Hey, hey Firefox fans!   Here are the details for today's meeting:   - When: http://arewemeetingyet.com/Los%20Angeles/2015-08-18/8:00/w/ Firefox%20desktop%20development%20meeting <http://arewemeetingyet.com/Los%20Angeles/2015-08-18/8:00/w/Firefox%20desktop%20development%20meeting> - Details: https://wiki.mozilla.org/Firefox/Meeting - Agenda: https://docs.google.com/document/d/1hM9bmIdIe0PeQEB4SbU7NG3m7MmjgLJjUB7Fzr7fGEU/edit?usp=sharing   Please feel free to join us and add topics to the agenda as needed. If you have a project update or have a round table item, please populate the agenda ahead of time.   See you all soon! 🤠   – Maxx

Back to top

You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to firefox-dev...@mozilla.org.