Consider making updateCurrentBrowser interruptible

NEW
Unassigned

Status

()

enhancement
P4
normal
2 years ago
a year ago

People

(Reporter: florian, Unassigned)

Tracking

(Blocks 3 bugs)

unspecified
Points:
---
Dependency tree / graph
Bug Flags:
qe-verify +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [fxperf:p3])

Reporter

Description

2 years ago
In bug 1349822 we are discussing removing from updateCurrentBrowser the things that may be slower than they need to be, or that may not be useful (eg. add-on sdk overhead), but I think at some point we'll run out of things to optimize there.

I'm under the impression that the slowness of updateCurrentBrowser is the most user-perceptible when we call it several times in a row, for example when the user presses Cmd+w several times. When this happens, I think we could probably skip most of the work updateCurrentBrowser does as soon as we know we are about to change the current browser again. To do this, I think we should make updateCurrentBrowser let some events be processed while it's running, and return early if it has been called again due to a new user event.

In pseudo code, I'm thinking something like this:

var gUpdateId = 0;
async function updateCurrentBrowser() {
  let id = ++gUpdateId;

  let instructions = [
   () => { stuff(); },
...
   () => { stuff(); },
  ];
  for (let instruction of instructions) {
    if (gUpdateId != id)
      break;
    instruction();
    await executeSoon();
  }
}

This isn't a fully thought through idea yet, but I'm filing a bug so that we don't forget to evaluate it once we are done optimizing away the slow things we don't need.

One tricky thing we should pay attention to is that any keyboard event that isn't related to switching the current tab should be processed after the focus has reached the correct element. This likely means that we would need to add an additional key event listener, and force updateCurrentBrowser to finish synchronously when receiving an event that needs to be processed.
Flags: qe-verify?
Priority: -- → P2
Whiteboard: [photon-performance]
Reporter

Updated

2 years ago
No longer blocks: photon-performance-triage
Flags: qe-verify? → qe-verify+
QA Contact: adrian.florinescu
Priority: P2 → P3
Whiteboard: [photon-performance] → [reserve-photon-performance]
Priority: P3 → P4
Whiteboard: [reserve-photon-performance] → [reserve-photon-performance] [fxperf]

Updated

a year ago
Whiteboard: [reserve-photon-performance] [fxperf] → [reserve-photon-performance] [fxperf:p3]
Whiteboard: [reserve-photon-performance] [fxperf:p3] → [fxperf:p3]
You need to log in before you can comment on or make changes to this bug.