Bug 1728914 - Convert a few uses of AsLayerManager to use WebRenderLayerManager. r=gfx-reviewers,aosmond

Depends on D124419

Differential Revision: https://phabricator.services.mozilla.com/D124420

Differential Revision: https://phabricator.services.mozilla.com/D123595

Backed out 2 changesets (bug 1727488, bug 1727489) for causing bustages on KnowsCompositor.cpp. CLOSED TREE

Backed out changeset 5a00db1b7a6a (bug 1727489)
Backed out changeset 13686567e748 (bug 1727488)

Differential Revision: https://phabricator.services.mozilla.com/D123595

Differential Revision: https://phabricator.services.mozilla.com/D122930

Backed out changeset e111894317cc (bug 1726291) for causing assertion failures on WebRenderCommandBuilder.cpp. CLOSED TREE

Differential Revision: https://phabricator.services.mozilla.com/D122930

Differential Revision: https://phabricator.services.mozilla.com/D120920

Backed out changeset cf8a1175abd1 (bug 1722258)
Backed out changeset 41176d476eb7 (bug 1722258)
Backed out changeset 4149d596d03d (bug 1722258)

Differential Revision: https://phabricator.services.mozilla.com/D120920

Depends on D120439

Differential Revision: https://phabricator.services.mozilla.com/D120440

Bug 1645528 - Connect nsRefreshDrivers in content processes with a widget-local vsync source r=mattwoodrow,emilio

To allow `requestAnimationFrame()` and similar things to run at monitor
speed if there is only a window-specific vsyncsource available.
This is the case for Wayland and, in the future, EGL/X11. Other backends
may opt for window specific vsyncsources as well at some point.

The idea is to, instead of using global vsync objects, expose a vsyncsource
from nsWindow and use it for refresh drivers. For the content process, move
VsyncChild to BrowserChild, so for each Browserchild there is only one
VsyncChild to which all refresh drivers connect.

IPC in managed either by PBrowser or PBackground. Right now, PBrowser is
only used on Wayland, as both PBrowser and the Wayland vsyncsource run
on the main thread. Other backends keep using the background thread for
now.

While at it, make it so that we constantly update the refresh rate. This
is necessary for Wayland, but also on other platforms variable refresh rates
are increasingly common. Do that by transimitting the vsync rate `SendNotify()`.

How to test:
 - run the Wayland backend
 - enable `widget.wayland_vsync.enabled`
 - optionally: disable `privacy.reduceTimerPrecision`
 - run `vsynctester.com` or `testufo.com`

Expected results:
Instead of fixed 60Hz, things should update at monitor refresh rate -
e.g. 144Hz

Original patch by Kenny Levinsen.

Depends on D98254

Differential Revision: https://phabricator.services.mozilla.com/D93173

Backed out changeset 986bd930bab7 (bug 1645528)
Backed out changeset 2fbe8c11cecb (bug 1645528)

Bug 1645528 - Connect nsRefreshDrivers in content processes with a widget-local vsync source r=mattwoodrow,emilio

To allow `requestAnimationFrame()` and similar things to run at monitor
speed if there is only a window-specific vsyncsource available.
This is the case for Wayland and, in the future, EGL/X11. Other backends
may opt for window specific vsyncsources as well at some point.

The idea is to, instead of using global vsync objects, expose a vsyncsource
from nsWindow and use it for refresh drivers. For the content process, move
VsyncChild to BrowserChild, so for each Browserchild there is only one
VsyncChild to which all refresh drivers connect.

IPC in managed either by PBrowser or PBackground. Right now, PBrowser is
only used on Wayland, as both PBrowser and the Wayland vsyncsource run
on the main thread. Other backends keep using the background thread for
now.

While at it, make it so that we constantly update the refresh rate. This
is necessary for Wayland, but also on other platforms variable refresh rates
are increasingly common. Do that by transimitting the vsync rate `SendNotify()`.

How to test:
 - run the Wayland backend
 - enable `widget.wayland_vsync.enabled`
 - optionally: disable `privacy.reduceTimerPrecision`
 - run `vsynctester.com` or `testufo.com`

Expected results:
Instead of fixed 60Hz, things should update at monitor refresh rate -
e.g. 144Hz

Original patch by Kenny Levinsen.

Differential Revision: https://phabricator.services.mozilla.com/D93173

Backed out changeset 08cd8d747c33 (bug 1645528)
Backed out changeset 4bc8953d9bed (bug 1645528)

Bug 1645528 - Connect nsRefreshDrivers in content processes with a widget-local vsync source r=mattwoodrow,emilio

To allow `requestAnimationFrame()` and similar things to run at monitor
speed if there is only a window-specific vsyncsource available.
This is the case for Wayland and, in the future, EGL/X11. Other backends
may opt for window specific vsyncsources as well at some point.

The idea is to, instead of using global vsync objects, expose a vsyncsource
from nsWindow and use it for refresh drivers. For the content process, move
VsyncChild to BrowserChild, so for each Browserchild there is only one
VsyncChild to which all refresh drivers connect.

IPC in managed either by PBrowser or PBackground. Right now, PBrowser is
only used on Wayland, as both PBrowser and the Wayland vsyncsource run
on the main thread. Other backends keep using the background thread for
now.

While at it, make it so that we constantly update the refresh rate. This
is necessary for Wayland, but also on other platforms variable refresh rates
are increasingly common. Do that by transimitting the vsync rate `SendNotify()`.

How to test:
 - run the Wayland backend
 - enable `widget.wayland_vsync.enabled`
 - optionally: disable `privacy.reduceTimerPrecision`
 - run `vsynctester.com` or `testufo.com`

Expected results:
Instead of fixed 60Hz, things should update at monitor refresh rate -
e.g. 144Hz

Original patch by Kenny Levinsen.

Differential Revision: https://phabricator.services.mozilla.com/D93173

Backed out changeset 3a9dce735340 (bug 1645528) for causing crashes with nsRefreshDriver CLOSED TREE

Bug 1645528 - Connect nsRefreshDrivers in content processes with a widget-local vsync source r=mattwoodrow,emilio

To allow `requestAnimationFrame()` and similar things to run at monitor
speed if there is only a window-specific vsyncsource available.
This is the case for Wayland and, in the future, EGL/X11. Other backends
may opt for window specific vsyncsources as well at some point.

The idea is to, instead of using global vsync objects, expose a vsyncsource
from nsWindow and use it for refresh drivers. For the content process, move
VsyncChild to BrowserChild, so for each Browserchild there is only one
VsyncChild to which all refresh drivers connect.

IPC in managed either by PBrowser or PBackground. Right now, PBrowser is
only used on Wayland, as both PBrowser and the Wayland vsyncsource run
on the main thread. Other backends keep using the background thread for
now.

While at it, make it so that we constantly update the refresh rate. This
is necessary for Wayland, but also on other platforms variable refresh rates
are increasingly common. When using PVsync, limit updates to once in every
250ms in order to minimize overhead while still updating fast.

How to test:
 - run the Wayland backend
 - enable `widget.wayland_vsync.enabled`
 - optionally: disable `privacy.reduceTimerPrecision`
 - run `vsynctester.com` or `testufo.com`

Expected results:
Instead of fixed 60Hz, things should update at monitor refresh rate -
e.g. 144Hz

Original patch by Kenny Levinsen.

Differential Revision: https://phabricator.services.mozilla.com/D93173

Backed out changeset df3577321bfe (bug 1645528)
Backed out changeset fbc13c3ea551 (bug 1645528)

Bug 1645528 - Connect nsRefreshDrivers in content processes with a widget-local vsync source r=mattwoodrow,emilio

To allow `requestAnimationFrame()` and similar things to run at monitor
speed if there is only a window-specific vsyncsource available.
This is the case for Wayland and, in the future, EGL/X11. Other backends
may opt for window specific vsyncsources as well at some point.

The idea is to, instead of using global vsync objects, expose a vsyncsource
from nsWindow and use it for refresh drivers. For the content process, move
VsyncChild to BrowserChild, so for each Browserchild there is only one
VsyncChild to which all refresh drivers connect.

IPC in managed either by PBrowser or PBackground. Right now, PBrowser is
only used on Wayland, as both PBrowser and the Wayland vsyncsource run
on the main thread. Other backends keep using the background thread for
now.

While at it, make it so that we constantly update the refresh rate. This
is necessary for Wayland, but also on other platforms variable refresh rates
are increasingly common. When using PVsync, limit updates to once in every
250ms in order to minimize overhead while still updating fast.

How to test:
 - run the Wayland backend
 - enable `widget.wayland_vsync.enabled`
 - optionally: disable `privacy.reduceTimerPrecision`
 - run `vsynctester.com` or `testufo.com`

Expected results:
Instead of fixed 60Hz, things should update at monitor refresh rate -
e.g. 144Hz

Original patch by Kenny Levinsen.

Differential Revision: https://phabricator.services.mozilla.com/D93173

Bug 1645528 - Connect nsRefreshDrivers in content processes with a widget-local vsync source r=mattwoodrow,emilio

To allow `requestAnimationFrame()` and similar things to run at monitor
speed if there is only a window-specific vsyncsource available.
This is the case for Wayland and, in the future, EGL/X11. Other backends
may opt for window specific vsyncsources as well at some point.

The idea is to, instead of using global vsync objects, expose a vsyncsource
from nsWindow and use it for refresh drivers. For the content process, move
VsyncChild to BrowserChild, so for each Browserchild there is only one
VsyncChild to which all refresh drivers connect.

IPC in managed either by PBrowser or PBackground. Right now, PBrowser is
only used on Wayland, as both PBrowser and the Wayland vsyncsource run
on the main thread. Other backends keep using the background thread for
now.

While at it, make it so that we constantly update the refresh rate. This
is necessary for Wayland, but also on other platforms variable refresh rates
are increasingly common. When using PVsync, limit updates to once in every
250ms in order to minimize overhead while still updating fast.

How to test:
 - run the Wayland backend
 - enable `widget.wayland_vsync.enabled`
 - optionally: disable `privacy.reduceTimerPrecision`
 - run `vsynctester.com` or `testufo.com`

Expected results:
Instead of fixed 60Hz, things should update at monitor refresh rate -
e.g. 144Hz

Original patch by Kenny Levinsen.

Differential Revision: https://phabricator.services.mozilla.com/D93173

Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.

To produce this patch I did all of the following:

1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.

2. Run ./mach lint --linter black --fix

3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.

4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.

5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).

# ignore-this-changeset

Differential Revision: https://phabricator.services.mozilla.com/D94045

Backed out 10 changesets (bug 1654103, bug 1672023, bug 1518999) for PanZoomControllerTest.touchEventForResult gv-junit failures CLOSED TREE

Backed out changeset ff3fb0b4a512 (bug 1672023)
Backed out changeset e7834b600201 (bug 1654103)
Backed out changeset 807893ca8069 (bug 1518999)
Backed out changeset 13e6b92440e9 (bug 1518999)
Backed out changeset 8b2ac5a6c98a (bug 1518999)
Backed out changeset 575748295752 (bug 1518999)
Backed out changeset 65f07ce7b39b (bug 1518999)
Backed out changeset 4bb80556158d (bug 1518999)
Backed out changeset 8ac8461d7bd7 (bug 1518999)
Backed out changeset e8ba13ee17f5 (bug 1518999)

Bug 1654103: Standardize on Black for Python code in `mozilla-central`. r=remote-protocol-reviewers,marionette-reviewers,webdriver-reviewers,perftest-reviewers,devtools-backward-compat-reviewers,jgilbert,preferences-reviewers,sylvestre,maja_zf,webcompat-reviewers,denschub,ntim,whimboo,sparky

Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.

To produce this patch I did all of the following:

1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.

2. Run ./mach lint --linter black --fix

3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.

4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.

5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).

# ignore-this-changeset

Differential Revision: https://phabricator.services.mozilla.com/D94045

Bug 1654103: Standardize on Black for Python code in `mozilla-central`. r=remote-protocol-reviewers,marionette-reviewers,webdriver-reviewers,perftest-reviewers,devtools-backward-compat-reviewers,jgilbert,preferences-reviewers,sylvestre,maja_zf,webcompat-reviewers,denschub,ntim,whimboo,sparky

Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.

To produce this patch I did all of the following:

1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.

2. Run ./mach lint --linter black --fix

3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.

4. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).

# ignore-this-changeset

Differential Revision: https://phabricator.services.mozilla.com/D94045

Differential Revision: https://phabricator.services.mozilla.com/D66016

--HG--
extra : moz-landing-system : lando

--HG--
extra : histedit_source : b2c748e31e0f6ba8fcf9960a336e0bbd361b07e6

Patch by bhackett and jlaster. Also reviewed by mccr8.

Differential Revision: https://phabricator.services.mozilla.com/D60197

--HG--
extra : moz-landing-system : lando

Patch by bhackett and jlaster. Also reviewed by mccr8.

Differential Revision: https://phabricator.services.mozilla.com/D60197

--HG--
extra : moz-landing-system : lando

Differential Revision: https://phabricator.services.mozilla.com/D60980

--HG--
extra : moz-landing-system : lando

Backed out changeset 0c982bc69cb3 (bug 1611415) for causing build bustages in /builds/worker/workspace/build/src/obj-firefox/dist/include/nsCOMPtr CLOSED TREE

Differential Revision: https://phabricator.services.mozilla.com/D60980

--HG--
extra : moz-landing-system : lando

Done with:
./mach static-analysis check --checks="-*, modernize-concat-nested-namespaces" --fix .
and then clang-format on the files

Differential Revision: https://phabricator.services.mozilla.com/D58217

--HG--
extra : moz-landing-system : lando

Backed out changeset bbb39655cf71 (bug 1605934) for build bustage in widget/gtk/mozwayland/mozwayland.c

Done with:
./mach static-analysis check --checks="-*, modernize-concat-nested-namespaces" --fix .
and then clang-format on the files

Differential Revision: https://phabricator.services.mozilla.com/D58217

--HG--
extra : moz-landing-system : lando

Bug 1600545 -  Remove useless inclusions of header files generated from IDL files in accessible/, browser/, caps/, chrome/, devtools/, docshell/, editor/, extensions/, gfx/, hal/, image/, intl/, ipc/, js/, layout/, and media/ r=Ehsan

The inclusions were removed with the following very crude script and the
resulting breakage was fixed up by hand. The manual fixups did either
revert the changes done by the script, replace a generic header with a more
specific one or replace a header with a forward declaration.

find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
    interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
    if [ -n "$interfaces" ]; then
        if [[ "$interfaces" == *$'\n'* ]]; then
          regexp="\("
          for i in $interfaces; do regexp="$regexp$i\|"; done
          regexp="${regexp%%\\\|}\)"
        else
          regexp="$interfaces"
        fi
        interface=$(basename "$path")
        rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
            hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
            if [ $hits -eq 0 ]; then
                echo "Removing ${interface} from ${path2}"
                grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
                mv -f "$path2".tmp "$path2"
            fi
        done
    fi
done

Differential Revision: https://phabricator.services.mozilla.com/D55443

--HG--
extra : moz-landing-system : lando

RenderFrame is a very poor name for what this class does. RemoteLayerTreeOwner
isn't perfect (it's not the only thing that owns layer trees), but it's
hopefully clearer.

Differential Revision: https://phabricator.services.mozilla.com/D33564

--HG--
rename : layout/ipc/RenderFrame.cpp => layout/ipc/RemoteLayerTreeOwner.cpp
rename : layout/ipc/RenderFrame.h => layout/ipc/RemoteLayerTreeOwner.h
extra : rebase_source : 890e54b93f5979a2430c35028110aa7f2091c550
extra : source : f50dd4cde03beb99ed27397e06f81748ae87b727
extra : histedit_source : 2d7eed25156829b2502f1712880df962a781adcf