Re: What if you could reinvent Firefox theming?
> The largest amount of responses (29.8%) said that it is a real pain to keep > these themes up-to-date and working > An overwhelming majority of the respondents insist that we don't need to > change a thing and that other apps don't offer grand alternatives at 36.5% I found these two an interesting contrast, although developers might have been thinking about different things. On 8 September 2016 at 15:41, Justin Dolske wrote: > > > On Thu, Sep 8, 2016 at 8:41 AM, Jared Wein wrote: >> >> [...] > > > Thanks for posting the results. A couple of observations... > >> >> Why do you install themes? >> [...] At 12% of responses was closer integration with the operating system > > > Do the raw responses have further detail on what OSes are involved, and what > kind of closer integration? > > I'm guessing this is mostly Linux (due to the gazillion different desktop > environments and OS themes), though I also see the 28th-most-used theme on > AMO is for making Firefox look like IE8. > >> >> What capabilities would you like themes to have? >> [...] Also at 3% of responses were requests from users who require larger >> icons and improved readability of the browser's user interface for improved >> accessibility. Not far behind, and ironically next in the order of >> responses, were requests for a smaller browser UI (2%). These users >> generally want to maximize the amount of screen space that web pages can >> use. > > > I'm a little surprised "make things smaller" came in so low! > > "Make things bigger" is somewhat curious... On Windows this is typically > done by adjusting the display scaling factor in the OS settings. I wonder if > people don't know about that, or are looking to make Firefox -- specifically > -- larger than normal. I'm unclear on what Linux offers these days, and > while I think OS X supports this internally it's not exposed in any UI. > (Apple's preferred route seems to be screen zooming. Which is neat, I use it > all the time and have normal vision.) So I'd be curious to understand this > use-case better. > > Separately from themes, I think it would be a good idea to consider adding > preferences UI for the default zoom-level of page content in Firefox. I > think it's technically easy to do the same thing with chrome, but that would > seem pretty strange to expose. > > Justin > > > ___ > firefox-dev mailing list > firefox-...@mozilla.org > https://mail.mozilla.org/listinfo/firefox-dev > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What if you could reinvent Firefox theming?
On Thu, Sep 8, 2016 at 8:41 AM, Jared Wein wrote: > [...] > Thanks for posting the results. A couple of observations... > Why do you install themes? > [...] At 12% of responses was closer integration with the operating system > Do the raw responses have further detail on what OSes are involved, and what kind of closer integration? I'm guessing this is mostly Linux (due to the gazillion different desktop environments and OS themes), though I also see the 28th-most-used theme on AMO is for making Firefox look like IE8. > What capabilities would you like themes to have? > [...] Also at 3% of responses were requests from users who require larger > icons and improved readability of the browser's user interface for improved > accessibility. Not far behind, and ironically next in the order of > responses, were requests for a smaller browser UI (2%). These users > generally want to maximize the amount of screen space that web pages can > use. > I'm a little surprised "make things smaller" came in so low! "Make things bigger" is somewhat curious... On Windows this is typically done by adjusting the display scaling factor in the OS settings. I wonder if people don't know about that, or are looking to make Firefox -- specifically -- larger than normal. I'm unclear on what Linux offers these days, and while I think OS X supports this internally it's not exposed in any UI. (Apple's preferred route seems to be screen zooming. Which is neat, I use it all the time and have normal vision.) So I'd be curious to understand this use-case better. Separately from themes, I think it would be a good idea to consider adding preferences UI for the default zoom-level of page content in Firefox. I think it's technically easy to do the same thing with chrome, but that would seem pretty strange to expose. Justin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Delay for 49 release to Sept. 20th
Hello Platform and Firefox teams, Because of two blocking issues and the need for a bit more time to evaluate the results of their fixes/backouts, we need to push back the upcoming merge and release dates. We will plan for merge day to be Monday Sept. 19th, with release planned for Tuesday Sept. 20th. 50 will continue as aurora, and 51 as nightly for next week. The 50 beta cycle was planned to be 8 weeks. We can afford to lose a week there and still aim to ship 50 as scheduled. We will need to build, test, and release a 49 RC3 (release candidate). I may aim for an RC3 build tomorrow, with release next Monday, Sept. 12. We also may wait to do the RC3 build on Monday for release the next day. Then we will have several days to evaluate telemetry data and other criteria, and have confidence we are shipping the best option to Firefox users. You can see the current list of blocking and other issues in play, here: https://public.etherpad-mozilla.org/p/49-blockers Please let me know if you have feedback or any questions, by email or on IRC on #release-drivers. Best, Liz -- Liz Henry (:lizzard) Firefox Release Manager lhe...@mozilla.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What if you could reinvent Firefox theming?
Thank you to those who have responded to the Firefox Theme survey [ https://goo.gl/forms/qUqQ4cAJ3oJueD5c2]. We received over 250 responses with some great feedback as to what people like about the current offerings of themes in Firefox as well as what they would like to see improved. We will be keeping the survey open and monitoring it for anybody that has not had a chance to reply yet, but we will not be sending out another summary email. The grouping of the results and more details can be found in our meeting notes [ https://github.com/mozilla/firefox-themes/blob/master/notes/09-08-2016.md]. Below is a summary of the responses to the survey. Have you made a lightweight theme before? 21.8% yes What do you like about lightweight themes? (48 responses) A strong majority (70%) of lightweight theme authors said that they liked how lightweight themes were simple and easy to make. The next group, at 6%, said that they liked how lightweight themes always remain compatible after Firefox updates. 4% of users also liked that they were easy to install with no restart required. A couple people complained that they were too simple and there was too much spam in the themes section of the Add-ons website. What do you feel was difficult to do or missing from lightweight themes? (47 responses) A little less than (42%) half of responses would have liked to do more than just a couple of images with lightweight themes. They would like to apply background images to other parts of the browser, change icons, buttons, and the size-of and location of browser components. The next group of responses (10%) wanted more support for scaling, repetition, animation, and position of background images. Improved documentation (8%) and a lack of a development environment such as an in-browser editor followed (6%). The last two groups of responses wanted the ability for themes to change based on external factors (2%) and separate images for the tabs and tab toolbar (2%). Have you made a XUL theme before? 23% yes What do you like about XUL themes? A strong majority of the respondents agreed firmly with 71.2% that XUL themes are awesome in allowing to touch and customize all the things. The second largest group of respondents seek out XUL themes because they offer more nuts and bolts to tinker with than lightweight themes at 11.5%, while the familiarity with the CSS styling language is the main reason to like them for 7.7% of the respondents. Two other notable groups are people who like dark themes, which are apparently only really available as XUL themes, and ones who feel that XUL themes are the easiest thing to make on this planet, each at 3.9%. What do you feel was difficult to do or missing from XUL themes? The largest amount of responses (29.8%) said that it is a real pain to keep these themes up-to-date and working, with the current fast release cycle of Firefox and the fast pace of development. 28.1% of the respondents rightfully complained that they need to use exotic, undocumented technologies and unknown CSS selectors in order to create a working XUL theme. Whilst 15.8% claimed there is nothing wrong with XUL themes and we should keep it as-is, another 12.3% is sad about the lack of documentation or any kind of manual to get started. Packaging and delivery of XUL themes is not considered optimal by 10.5% of respondents and that ultimately very few of these themes can be configured after installation (3.5%). Why do you install themes? About half (47%) of the survey responses want to personalize Firefox. These people said that they want to make Firefox "their own" and have fun showing it off. They enjoy having full control over the user interface through XUL themes and like the ability to set arbitrary CSS. The next set of responses (16%) asked for a "dark" Firefox, making it easier on the eyes at night. These responses were generally focused on the toolbars and menus of the browser being dark. At 12% of responses was closer integration with the operating system followed closely by 11% of responses saying that they felt the default theme was boring and bland. The last category of responses that received multiple votes was to allow themes to undo recent changes to the user interface, as an attempt to keep things the same that they've been for the past months/years. What capabilities would you like themes to have? More than half (56%) of the survey responses want full control over the browser UI. They would like to move and hide items, change tab shapes, replace icons, context menus, scrollbars, and more. Following this large group, we had close to 5% of respondents who wanted to simply change basic colors and another group, also close to 5%, that wanted to make it easy for users to make simple tweaks to their browser or an installed theme through a built-in menu or tool. Native OS integration, such as using platform-specific icons and scrollbars, followed closely at 3%. Also at 3% of responses were requests from users who requ
Re: Intent to ship: RC4 disabled by default in Firefox 44
On Tuesday, September 1, 2015 at 9:26:28 PM UTC+4:30, Richard Barnes wrote: > For a while now, we have been progressively disabling the known-insecure > RC4 cipher [0]. The security team has been discussing with other the > browser vendors when to turn off RC4 entirely, and there seems to be > agreement to take that action in late January / early February 2016, > following the release schedules of the various browsers. For Firefox, that > means version 44, currently scheduled for release on Jan 26. > > More details below. > > > # Current status > > Since Firefox 37, RC4 has been partly disabled in Firefox. It still works > in Beta and Release, but in Nightly and Aurora, it is allowed only for a > static whitelist of hosts [1][2]. Note that the whitelist is not > systematic; it was mainly built from compatibility bugs. > > RC4 support is controlled by three preferences: > > * security.tls.unrestricted_rc4_fallback - Allows use of RC4 with no > restrictions > * security.tls.insecure_fallback_hosts.use_static_list - Allow RC4 for > hosts on the static whitelist > * security.tls.insecure_fallback_hosts - A list of hosts for which RC4 is > allowed (empty by default) > > > # Proposal > > The proposed plan is to gradually reduce RC4 support by making the default > values of these preferences more restrictive: > > * 42/ASAP: Disable whitelist in Nightly/Aurora; no change in Beta/Release > * 43: Disable unrestricted fallback in Beta/Release (thus allowing RC4 only > for whitelisted hosts) > * 44: Disable all RC4 prefs by default, in all releases > > That is, as of Firefox 44, RC4 will be entirely disabled unless a user > explicitly enables it through one of the prefs. > > > # Compatibility impact > > Disabling RC4 will mean that Firefox will no longer connect to servers that > require RC4. The data we have indicate that while there are still a small > number of such servers, Firefox users encounter them at very low rates. > > Telemetry indicates that in the Beta and Release populations, which have no > restrictions on RC4 usage, RC4 is used for around 0.08% for Release and > around 0.05% for Beta [3][4]. For Nightly and Aurora, which are > restricted to the whitelist, the figure is more like 0.025% [5]. These > numbers are small enough that the histogram viewer on telemetry.mozilla.org > won't show them (that's why the below references are to my own telemetry > timeline tool, rather than telemetry.mozilla.org). > > That said, there is a small but measurable population of servers out there > that require RC4. Scans by Mozilla QA team find that with current Aurora > (whitelist enabled), around 0.41% of their test set require RC4, 820 sites > out of 211k. Disabling the whitelist only results in a further 26 sites > broken, totaling 0.4% of sites. I have heard some rumors about there being > a higher prevalence of RC4 among enterprise sites, but have no data to > support this. > > Users can still enable RC4 in any case by changing the above prefs, either > by turning on RC4 in general or by adding specific hosts to the > "insecure_fallback_hosts" whitelist. The security and UX teams are > discussing possibilities for UI that would automate whitelisting of sites > for users. > > [0] https://tools.ietf.org/html/rfc7465 > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1128227 > [2] > https://dxr.mozilla.org/mozilla-central/source/security/manager/ssl/IntolerantFallbackList.inc > [3] > https://ipv.sx/telemetry/general-v2.html?channels=release&measure=SSL_SYMMETRIC_CIPHER_FULL&target=1 > [4] > https://ipv.sx/telemetry/general-v2.html?channels=beta&measure=SSL_SYMMETRIC_CIPHER_FULL&target=1 > [5] > https://ipv.sx/telemetry/general-v2.html?channels=nightly%20aurora&measure=SSL_SYMMETRIC_CIPHER_FULL&target=1 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform