commit ce9cc4bc4eaf2c705d0d0ea15f23e15dc60938a0
author Primiano Tucci <primiano@google.com> Tue Sep 10 12:35:02 2024 +0100
committer Primiano Tucci <primiano@google.com> Tue Sep 10 11:37:32 2024 +0000
tree ab193fb12f69b0b6de4800ee4f4a572a2d45b26b
parent bea7f2f92cb9ecf6923ecea52120c312840494a0

ui: a plugin is forever (and is deterministic)

Get rid of the disable-plugins-at-runtime feature. It's a mixture
of pure utopia and unnecessary complexity:
- Why would a user disable a plugin? Probably because it crashed or
  is too slow during trace load. In both cases, runtime disablement
  is useless. If the trace loaded... it's too late. If it crashes,
  the app is in a broken state.
- Handling plugin disablement at runtime is extremely complicated.
  In a GC-ed language it's impossible to guarrantee that some object
  is really destroyed. Plugins can outlive their disablement in
  bazilion ways (by attaching DOM handlers, scheduling promises,
  passing a refernce to a piece of themselves to some other part of
  the UI). Supporting this properly would require intensive auditing.
  This is more likely to cause more bugs in practice.
- Also remove randomization of plugins. It makes tests flakier and
  harder to reason about (I hit this while trying to add more tests)
  especially when there are things we don't care about, like relative
  order of tracks added with the same sortIndex.


Change-Id: I6a19483a6d09a15069349d0d4ac41878afe7cf05