Minutes from August 8 Mobile Tech Leads Meeting, Socorro edition

[Nicholas Alexander]

Hi folks,

On Thursday, August 8, James Willcox, Sebastian Kaspari, and I (Nick
Alexander) met with William Kahn-Greene and Chris Lonnen to discuss using
Socorro/crash-stats to analyse crashes in non-Firefox contexts.  You can
read the mostly complete detailed notes

.

The worldview for determining stability

Mozilla has been pushing towards a two pronged aggregate analysis approach:

   1.

   We use “crash pings”, which are a high-volume, low-specificity Telemetry
   signal to understand Firefox stability.
   2.

   We use “crash reports”, which are a low-volume, high-specificity,
   highly-biased Socorro signal to understand specific stability issues.


The critical facts about Socorro, as I understand them:

   -

   Socorro is excellent at processing minidumps
   -

   Socorro has a robust security model for controlling access to PII
   -

   Socorro is not a strong platform for aggregate analysis of crashes


>From this baseline, the discussion split into two contexts:


   1.

   Using Socorro to understand the health of the GeckoView-consuming
   Android App ecosystem (flagship browser for Android, Firefox Reality,
   potential third-party Apps)


   -

  Technically possible right now: need ops to whitelist “application
  name”, but can aggregate minidumps across consuming Apps.
  -

  Strong support for non-Gecko native code crashes (e.g., Firefox
  Reality); symbol server largely stands alone and scales to new uses.
  -

  Minimal support right now, and no long-term plan for investment into
  future support, for first-class support of “managed code” reports (e.g.,
  Java stacktraces or JavaScript stacktraces).
  -

   Using Socorro to understand the health of non-Gecko/non-GeckoView
   Android Apps (Notes, Lockbox for Android).
   -

  Socorro is not a good platform for understanding “managed code”
  reports.
  -

  Considered better to push non-Gecko native code crashes through
  Sentry than to use Socorro: more problems in managed code than in native
  code long term.


The immediate next steps are:

   1.

   William to investigate pushing “bare” minidumps to Socorro to understand
   what, e.g., Firefox Reality actually needs to upload
   2.

   James (snorp) to investigate pushing Gecko minidumps first to Sentry and
   then on to Socorro to understand whether, e.g., Focus (GeckoView) can
   leverage Sentry for managed code crashes while still feeding Gecko
   stability problems into the larger Socorro tool.


Many thanks to William and Lonnen for their ongoing attention to this
effort!  Everybody, please correct errors introduced by your interlocutor.

Yours,

Nick (for James, Sebastian, William, and Lonnen)
___
Dev-fxacct mailing list
Dev-fxacct@mozilla.org
https://mail.mozilla.org/listinfo/dev-fxacct

Minutes from August 7 Mobile Tech Leads Meeting, Necko edition

[Nicholas Alexander]

Hi folks,

On Wednesday, August 7, Matt Miller and I (Nick Alexander) met with Jason
Duell and Valentin Gosu to discuss using Necko in non-Gecko contexts.
Sadly I was unable to record the discussion, but I was able to take partial
notes

.

The discussion split into two contexts:


   1.

   Necko in non-GeckoView Android Apps like Notes and Lockbox for Android.
   -

  Desirable, but there will (almost) always be two network stacks: the
  built-in WebView stack and the “other” stack used for FxA, Sync, other
  services.
  -

  Engineering work to “slim down” the equivalent of `libxul.so` to be
  feasible to ship is too great to invest in now.
  -

  Jason suggested a Rust binding to `libcurl` might be a better
  approach.
  2.

   Necko in GeckoView-consuming Android Apps for non-Gecko uses.
   -

  Desirable to avoid “second network stack” problems that we have in
  Firefox for Android: dated cipher suites, inconsistent SNI support, proxy
  configuration mismatches.
  -

  Engineering work to stage XPCOM startup so that Necko is available to
  background services (like Sync) without starting the entire
browser is seen
  as feasible and is in line with existing efforts to start Gecko headless
  before upgrading to headed functionality for, e.g., push
notifications and
  service workers.


The immediate next step is for Jason to meet with the GeckoView team to
plan investigations into item 2).  For item 1), the relevant non-GeckoView
Android Apps intend to ship as many network stacks as are needed.

Many thanks to Jason and Valentin for their patience and expertise!

Yours,

Nick (for Matt, Jason, and Valentin)
___
Dev-fxacct mailing list
Dev-fxacct@mozilla.org
https://mail.mozilla.org/listinfo/dev-fxacct