As per our discussions on https://bugzilla.mozilla.org/show_bug.cgi?id=1495389 -- it would make sense to make target.getFront assume the front is asynchronous rather than handling sync and async fronts.

Depends on D11885

Animations panel also had a sync getTarget location. Unfortunately this animation front was used in a number of locations. In this case, I used getFront in each call location, as these were always async. I am not sure if this was the best way Depends on D11887

ChangesView was challenging because the async call was in the constructor. I moved it out of the constructor to the init method, and do a check to see if its been initialized in the destroy method. Depends on D11886

Depends on D11888

Depends on D11898

Pushed by ystartsev@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/71901cdb0b85 account for async fronts when we destroy; r=ochameau https://hg.mozilla.org/integration/autoland/rev/1eff56366820 add await to all target.getFront calls in async callsites; r=ochameau https://hg.mozilla.org/integration/autoland/rev/5990eabd1096 make changesView have an async init method; r=ochameau https://hg.mozilla.org/integration/autoland/rev/8ae189519358 make getting animation front async in animation panel; r=ochameau https://hg.mozilla.org/integration/autoland/rev/d65ba27b4b5d make getting reflow front async; r=ochameau https://hg.mozilla.org/integration/autoland/rev/cc898cd43aea make getting accessibility front async in inspector; r=ochameau

https://hg.mozilla.org/mozilla-central/rev/71901cdb0b85 https://hg.mozilla.org/mozilla-central/rev/1eff56366820 https://hg.mozilla.org/mozilla-central/rev/5990eabd1096 https://hg.mozilla.org/mozilla-central/rev/8ae189519358 https://hg.mozilla.org/mozilla-central/rev/d65ba27b4b5d https://hg.mozilla.org/mozilla-central/rev/cc898cd43aea