Here's the stack: resize@moz-extension://58e2758a-efad-4ad8-8551-36cb12e93495/js/popup.js:604:1 Async*resizeAsync@moz-extension://58e2758a-efad-4ad8-8551-36cb12e93495/js/popup.js:617:23 EventListener.handleEvent*renderOnce@moz-extension://58e2758a-efad-4ad8-8551-36cb12e93495/js/popup.js:619:5 onDataReceived@moz-extension://58e2758a-efad-4ad8-8551-36cb12e93495/js/popup.js:1003:9 messageListener@moz-extension://58e2758a-efad-4ad8-8551-36cb12e93495/js/vapi-client.js:132:17 applySafeWithoutClone@resource://gre/modules/ExtensionCommon.jsm:234:16 addListener/asyncWithoutClone/<@resource://gre/modules/ExtensionCommon.jsm:1918:20 promise callback*asyncWithoutClone@resource://gre/modules/ExtensionCommon.jsm:1916:16 api/register/publicAPI.onMessage<@resource://gre/modules/ExtensionChild.jsm:200:13 receiveMessage@resource://gre/modules/ExtensionChild.jsm:259:11 _handleMessage/</<@resource://gre/modules/MessageChannel.jsm:912:19 _handleMessage/<@resource://gre/modules/MessageChannel.jsm:911:9 _handleMessage@resource://gre/modules/MessageChannel.jsm:909:7 receiveMessage/<@resource://gre/modules/MessageChannel.jsm:208:9 receiveMessage@resource://gre/modules/MessageChannel.jsm:201:5 MessageListener.receiveMessage*FilteringMessageManager@resource://gre/modules/MessageChannel.jsm:191:5 get@resource://gre/modules/MessageChannel.jsm:426:14 setupMessageManagers@resource://gre/modules/MessageChannel.jsm:653:7 init@jar:file:///home/geeknik/firefox/omni.ja!/components/extension-process-script.js:286:5 @jar:file:///home/geeknik/firefox/omni.ja!/components/extension-process-script.js:525:1 @data:,Components.classes['@mozilla.org/webextensions/extension-process-script;1'].getService():1:1 @resource://gre/modules/AddonManager.jsm:83:1 amManager@jar:file:///home/geeknik/firefox/omni.ja!/components/addonManager.js:43:3 createInstance@jar:file:///home/geeknik/firefox/omni.ja!/components/addonManager.js:254:22

Hey geeknik, Can you tell me which add-on was showing the popup that caused this reflow? If you go to about:debugging, it should have an internal UUID of 58e2758a-efad-4ad8-8551-36cb12e93495.

Hm, I'm 99% sure this is uBlock: https://github.com/gorhill/uBlock/blob/e5d5d9eaf6e6a7ebe0ff4e9e7de468b7a7e54f17/src/js/popup.js#L604 Tentatively moving this to Tech Evangelism, though I'm wondering why we're hitting this... aren't the panel contents supposed to be running OOP? Am I wrong on that, aswan?

(In reply to Mike Conley (:mconley) (:⚙️) (Catching up on needinfos / reviews) from comment #2) > Tentatively moving this to Tech Evangelism, though I'm wondering why we're > hitting this... aren't the panel contents supposed to be running OOP? Am I > wrong on that, aswan? Extension pages (including panel contents) are OOP on Windows and Mac, but not yet on Linux (bug 1357487). If this was observed on a platform where OOP should be enabled, I guess the first step would be to check the extensions.webextensions.remote preference and see if it was manually flipped to false for some reason.

Looking at the file path to the omni.ja (/home/geeknik/firefox/omni.ja), it seems very likely this was running on Linux. Plus, I'm realizing now that this bug is already listed as targeting the Linux platform, so yay for my observation skills. Thanks!

So is there any action that needs to be taken on the uBlock side, or is it just a matter of waiting for OOP to make it to Linux?

(In reply to Jorge Villalobos [:jorgev] from comment #5) > So is there any action that needs to be taken on the uBlock side, or is it > just a matter of waiting for OOP to make it to Linux? Moving the WebExtension OOP will help not jank the parent process by forcing a layout flush, but the add-on author can also accelerate that effort by avoiding the layout flush altogether (assuming this is possible).

The code involved is enable uBO to be rendered in a restricted viewport -- for examples on Firefox for Android or inside the overflow menu -- where uBO must fill the viewport rather than expect the viewport to adjust to the natural size of uBO's popup panel.[1] Given the real issues this code fixes and given that the "issue" is "1.08ms uninterruptible reflow", and given that this code executes most likely only once when the popup is first displayed,[2] is this ~1ms really an actual issue?[3] [1] https://github.com/gorhill/uBlock/issues/2809 [2] It will also execute on resize events (coalesced using a setTimeout), which shouldn't really occur for the popup panel. [3] This 1ms represents probably a fraction of % of all else that needs to be done by uBO when the popup panel opens.

By the way, I am unable to reproduce this warning at the console on my side (also using Linux here).