As a long-time Firefox user, I went to ESR because I prefer stability to new features, and I especially don't like gratuitous changes to the User Interface. The move to Tabs on Top was ugly: I think Google started it so that users would view the Web (and hence Google) as their computing environment, rather than Windows et al. But at least Classic Theme Restorer could fix that.
The move to Quantum killed much of the ability to make Firefox look the way the user wanted and was used to. This has meant that users had to learn the new interface rather than doing useful work (sort of like The Microsoft Office "Ribbon" debacle). And the modern fad of replacing text-labeled icons with pure icons means that no one can know for sure what they mean, no matter what language they speak. (Plus, "hovering" over the icon to get the tool-tip wastes more time.) Not all users have to make do with tiny smartphone screens which don't have the space for labeled icons. The move to Quantum also required some really critical add-ons, such as NoScript, to be totally reimplemented, and made many other add-ons (such as Classic Theme Restore) apparently impossible. In the case of NoScript, there may have been a period where the overall security of using Firefox suffered in spite of the more secure internal structure of Quantum. And speaking of security, although the idea of requiring add-ons to be signed by Mozilla (only!) may be good for the consumer versions of Firefox, it is totally inappropriate for the *Enterprise* version (ESR). It means that any organization that wants add-ons that *need* to be kept private can't use Firefox at all. The notion that they could use a local build or an unofficial build (daily etc.) could mean that they are violating some other corporate or government regulation concerning what software they are allowed to use. And how would one even *find* the daily etc. build that is essentially identical to the release build? Since ESR is for enterprise use, surely it should be possible to allow enterprise-private add-ons to be loaded in ESR if their *hash* is signed by Mozilla. (Mozilla should not be in the business of trying to protect enterprises from software they themselves write.) In other words, an enterprise would just submit a hash of the add-on XPI to Mozilla the way they now can submit the whole XPI. Then if so configured (e.g., via about:config) the ESR version of Firefox would allow the add-on to be loaded iff its hash passed the signature test. To add to "public safety", Firefox could display a caveat stating that the add-on belongs to XYZ Corp. and is in no way certified by Mozilla. Plus, of course, such hash-signed add-ons would never be hosted by Mozilla. On Sat, 17 Aug 2019 00:54:28 +0000 Ramkrishna Reddy D S <[email protected]> wrote: > Hi Mike, > > Less major updates would be good as it's hard for us to manage. > > Regards, > Ram > > Sent from Workspace ONE Boxer > > On 17-Aug-2019 12:16 AM, Mike Kaply <[email protected]> wrote: > I know this is generally considered a support list, but I have a > couple things I'd like to let you know about. Going forward, if you'd > like to continue to receive these kind of updates, you can follow the > instructions at the end of this email. > > Legacy Browser Support for Windows now > available!<https://protect2.fireeye.com/url?k=0ab11a4d-5665120e-0ab15ad6-86a1150bc3ba-e41f2431dfb71a8b&q=1&u=https%3A%2F%2Fgithub.com%2Fmozilla%2Flegacy-browser-support%2Freleases%2Ftag%2Fv1.0> > > It is quite possible that you still require the use of websites and > apps running ActiveX, Java, or Silverlight that need a legacy browser > for it to work. You can now get Legacy Browser Support which will > allow you to easily switch between Firefox and your legacy browser of > choice. You can add websites to the policy and when your users try to > access the site via the URL bar or a link, it will open in the legacy > browser automatically. Legacy Browser Support requires a native > component installed via MSI as well as an extension. > > Share your thoughts on ESR Release Cadence > > We would love your feedback in our current cadence of Firefox > Extended Support releases. > > Today, an ESR life cycle spans between 9 months to a year. We would > like to understand if a shorter life cycle, with more releases each > year, would help meet the needs of you and your organization. > > We believe faster cycles will allow more flexibility to back port > features and functionality to the ESR and will reduce occurrence of > web app compatibility issues that arise due to the ESR being too > outdated. While the ESR helps lower QA overhead through less frequent > updates, would a biannual release bring more benefits to you? Please > chime in on this feedback form<https://forms.gle/jdwWYKQ3inqP3jwL9>. > > Want to receive enterprise news? > > This is our second note to you in the past few weeks and we would > like to share more news about our enterprise work as new features and > offerings are developed. If my recent emails have been helpful, I’d > love to have you complete this brief > form<https://www.mozilla.org/en-US/firefox/enterprise/signup/> to > receive periodic news from our enterprise team. > > Thanks > [https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif] > Mike Kaply > Technical Lead, Enterprise Firefox _______________________________________________ Enterprise mailing list [email protected] https://mail.mozilla.org/listinfo/enterprise To unsubscribe from this list, please visit https://mail.mozilla.org/listinfo/enterprise or send an email to [email protected] with a subject of "unsubscribe"
