Pinning or unpinning a persistent widget, such as Jitsi, could cause the
PiP view and the app drawer to fight for control over the widget, since
the PiP view never realized that it was supposed to relinquish control.
This was due to a race between the WidgetLayoutStore update and the
AppTile lifecycle tracking update.
* Don't assume that widget IDs are unique
Signed-off-by: Robin Townsend <robin@robin.town>
* Don't remove live tiles that don't exist
Signed-off-by: Robin Townsend <robin@robin.town>
* Add unit test for AppTile's live tile tracking
Signed-off-by: Robin Townsend <robin@robin.town>
Fix https://github.com/vector-im/element-web/issues/21262
Optimizations:
1. Don't update the `style` (positioning) of hidden tooltips
1. Don't add DOM elements to the page for hidden tooltips
> ## Performance problems broken down
>
>
> ### Hidden tooltips rendering on `scroll`
>
> You can see that the Tooltip render is attached to the `scroll` event at [`src/components/views/elements/Tooltip.tsx#L78-L81`](31f0a37ca2/src/components/views/elements/Tooltip.tsx (L78-L81))
>
> The rendering calls [`src/components/views/elements/Tooltip.tsx#L101` -> `updatePosition`](36adba101c/src/components/views/elements/Tooltip.tsx (L101)) which ends up as an expensive "Recalculate Style" because it uses [`Element.getBoundingClientRect()`](https://developer.mozilla.org/en-US/docs/Web/API/Element/getBoundingClientRect). This happens many many times within a single `scroll` event. Probably once for each tooltip within the room list **even though no tooltips are event visible as I scroll**. I can see that we're just updating the `style` attribute for a bunch of `.mx_Tooltip_invisible` elements at the end of the document.
>
> Each one of the purple spans below the `scroll` span ends up as a call to `updatePosition`. And a `scroll` event takes 35ms to 60ms to complete which is way over the 16.6ms 60 FPS budget (on a powerful desktop PC), granted these times are with the performance profiling running. This is without the Passbolt extension explained below.
>
> And the room list contains about 141 rooms (`document.querySelectorAll('.mx_RoomTile').length`):
>
> ![](https://user-images.githubusercontent.com/558581/156273551-e744d3d6-93c6-4b07-bb12-6aad361f96a2.png)
>
>
>
> ### Passbolt Chrome browser extension exacerbates the problem
>
> In order to login to Passbolt, it requires a browser extension which defaults to mucking up all pages:
>
> <img src="https://user-images.githubusercontent.com/558581/156275644-bc26b1f5-5d99-4eae-b74b-c2028f2f1baf.png" width="300">
>
>
> The extension source seems to be available: https://github.com/passbolt/passbolt_browser_extension
>
> The Passbolt Chrome extension has a `MutationObserver` listening to all attribute and element changes to the whole `<body>` of the `document` so it can `findAndSetAuthenticationFields` (find form elements and autofill).
>
>
> [`passbolt/passbolt_styleguide` -> `src/react-web-integration/lib/InForm/InFormManager.js#L143`](1c5eddc910/src/react-web-integration/lib/InForm/InFormManager.js (L143))
> ```js
> this.mutationObserver.observe(document.body, { attributes: true, childList: true, subtree: true });
> ```
>
> This causes a bunch of `Forced reflow` because the Tooltip `updatePosition` is mutating the element `style` attribute and Passbolt `MutationObserver` callbacks are querying the whole DOM looking for form elements all in the same frame.
>
> Under the `scroll` event, all of the little spans are the `MutationObserver` -> `findAndSetAuthenticationFields`. With the Passbolt extension, scrolling is verrrrry crunchy and bad.
>
> ![](https://user-images.githubusercontent.com/558581/156144998-8cf7686f-3c7b-42f8-8d81-ff780bae0ab5.png)
>
>
> #### Workaround
>
> Instead of running Passbolt on all sites, we can enable the extension to only run on the domain for Passbolt instance itself. I'm guessing the Passbolt extension also does autofill stuff on sites but I always login manually to the Passbolt instance so this solution works for me �
>
> **Extensions** -> **Passbolt** -> **Details** -> Change **Site access** to `On specific sites` -> Enter in your Passbolt instance `https://passbolt.example.com/`
>
> ![](https://user-images.githubusercontent.com/558581/156275630-a53ef6a1-c058-4ac9-aa08-ae50b90e72c9.png)
>
> *-- https://github.com/vector-im/element-web/issues/21262*
* react-focus-lock to 2.5.1
Signed-off-by: Kerry Archibald <kerrya@element.io>
* use enzyme in ASSD test so focus lock finds active element
Signed-off-by: Kerry Archibald <kerrya@element.io>
* findById and flushPromises to test utils
Signed-off-by: Kerry Archibald <kerrya@element.io>
Previously, the `left` positioning seemed to only work with icons which are all about the same size so the arbitrary offset worked. Now we actually position off to the left of the element and we have equal `margin-left` and `margin-right` to determine the offset.
Spawned from https://github.com/matrix-org/matrix-react-sdk/pull/7339#discussion_r767154349