Firefox Core Engineering: Difference between revisions

update all the things
(updated Update Orphan remediation)
(update all the things)
Line 64: Line 64:
=== Get More Data Faster ===
=== Get More Data Faster ===
We need to reduce known blind spots and barriers to getting data AND commit to non-ADI based metrics. For this, our goals are to:
We need to reduce known blind spots and barriers to getting data AND commit to non-ADI based metrics. For this, our goals are to:
* <strike>enable client-side stackwalking and send basic stack traces with crash pings (beginning in Nightly/Aurora, see {{Bugzilla|1280484}})</strike>
* <strike>enable content process crash reports ({{Bugzilla|1293656}})</strike>
* <strike>differentiate between process types in crash pings ({{Bugzilla|1310664}})</strike>
* process stack data in crash pings into a queryable result ({{Bugzilla|1310695}})
* process stack data in crash pings into a queryable result ({{Bugzilla|1310695}})
* <strike>create pingSender to handle crash pings instead of Gecko ({{Bugzilla|1310703}})</strike>
* <strike>enable client-side stackwalking and send basic stack traces with crash pings on all channels</strike>


See the [[Firefox_Core_Engineering/Get_More_Data_Faster|roadmap here]].
See the [[Firefox_Core_Engineering/Get_More_Data_Faster|roadmap here]].
Line 76: Line 71:
This includes:
This includes:
* prefer fallback content to Flash ({{Bugzilla|1277346}})
* prefer fallback content to Flash ({{Bugzilla|1277346}})
* <strike>establish allowedlists and deniedlists ({{Bugzilla|1307604}}, {{Bugzilla|1307605}})</strike>
* <strike>use heuristics to control when Flash is set to Click To Activate ({{Bugzilla|1307606}})</strike>
* <strike>geography-specific SHIELD study in FF53 release to understand user response and impact ({{Bugzilla|1335232}})</strike>


See the [https://docs.google.com/document/d/1sYp0DNioPA5iF3iw9LHGf1uN5B5AgdCu7jJxAh0MiqA/edit details here].
See the [https://docs.google.com/document/d/1sYp0DNioPA5iF3iw9LHGf1uN5B5AgdCu7jJxAh0MiqA/edit details here].


<!--
=== XBL/XUL replacement ===
==== XUL performance tests ====
TBD with and after Browser Architecture's recommendations.
XUL is supposed to go away, but it would seem that we don't know what the performance implications could/will be. This work builds on Neil Deakin's 2015 experiment to shed some light on where we need to focus our optimization/change efforts.
 
-->
=== Policy Engine ===
When implemented, this should provide an API for pre-defined policies to support enterprise management of Firefox deployments.
 
=== Migration performance optimization ===
With bug {{Bugzilla|1332225}}, investigate and optimize the migration process for new users.
 


=== App Updater and Installers ===
=== App Updater and Installers ===
Line 93: Line 90:
* continue the download instead of starting over after other networking errors occur ({{Bugzilla|1309124}}, {{Bugzilla|1348087}})
* continue the download instead of starting over after other networking errors occur ({{Bugzilla|1309124}}, {{Bugzilla|1348087}})
* create an Update Agent, responsible for running independently, daily, and downloading an update if found ({{Bugzilla|1343669}})
* create an Update Agent, responsible for running independently, daily, and downloading an update if found ({{Bugzilla|1343669}})
* <strike>continue the download instead of starting over after NS_ERROR_DOCUMENT_NOT_CACHED occurs ({{Bugzilla|1272585}})</strike> (FF49)
* create a dashboard for non-orphan telemetry analysis
* <strike>download the update MAR file unthrottled (already landed) ({{Bugzilla|1309125}}, {{Bugzilla|1309668}})</strike>
* <strike>serve a partial MAR file to Firefox 43.0.1 clients ({{Bugzilla|1309130}})</strike>
* <strike>push either a system or hotfix add-on that changed the download throttle preference to 0 for FF 50+</strike>
* <strike>run another method (non sysaddon, non SHIELD?, etc) to urge 43.0.1 users to upgrade</strike>
* <strike>Updater UI is outdated, too big, and needs to be updated ({{Bugzilla|893505}}) (FF55)</strike>
* <strike>change compression to LZMA for updates ({{Bugzilla|641212}}) (FF56)</strike>
* <strike>move to SHA-384 for MAR signing ({{Bugzilla|1324498}}) (FF56)</strike>
 
==== Installer UI ====
* <strike>Streamlined installer testing in QX onboarding funnelcake ({{Bugzilla|1328445}})</strike>


==== Windows 64 ====
==== Installer ====
We want to start moving users to 64-bit when appropriate:
* rename installed links to "Firefox" instead of "Mozilla Firefox" ({{Bugzilla|1413295}})
* <strike>stub installer should automatically select 32-bit or 64-bit ({{Bugzilla|797208}})</strike>
* stub installer metrics ({{Bugzilla|995794}})
* investigate MSI-based (read: non-NSIS) installer




Line 133: Line 121:


* cmore is pitching that Firefox optimizes the user paths that support retention -- which could also include fixing paths where retention drops. This work probably involves a system add-on that initiates event-based recordation, as well as the analysis and remediation of the root cause (this is pending dcamp approval).
* cmore is pitching that Firefox optimizes the user paths that support retention -- which could also include fixing paths where retention drops. This work probably involves a system add-on that initiates event-based recordation, as well as the analysis and remediation of the root cause (this is pending dcamp approval).
* Firefox needs a "policy engine" (with API) to facilitate enterprise admins using Group Policies to ease deployment of Firefox in enterprise settings.
* Update (rstrong) needs help with https://bugzilla.mozilla.org/show_bug.cgi?id=1112937 -- ideally for FF58.
* DLL injection (see https://bugzilla.mozilla.org/show_bug.cgi?id=1306406) needs investigation/implementation of a dynamically updateable DLL blocklist (possibly using Kinto?).
* DLL injection (see https://bugzilla.mozilla.org/show_bug.cgi?id=1306406) needs investigation/implementation of a dynamically updateable DLL blocklist (possibly using Kinto?).
* On a personal note, if anyone experiences sluggishness in FF (on any channel) when you don’t restart it for a few days (maybe with several tabs open?), especially on Windows, please let me know ({{Bugzilla|1398652}}).
* Mossop (& browser arch) has begun the de-XBL. Overall browser architecture (& UI architecture) could be game in the near future.
* Mossop (& browser arch) has begun the de-XBL. Overall browser architecture (& UI architecture) could be game in the near future.


Confirmed users
746

edits