1434571 - Too slow and little incorrect animation on init

Status: RESOLVED WORKSFORME

(WebExtensions :: Frontend, defect)

Description

[Vitaly Zdanevich]

Attachment: webextension-init-retina--showmotion.gif

My extensions UI shows almost instantly in Chromium 64.

Comment 1

[Vitaly Zdanevich]

Attachment: webextension-init-retina--normal-speed.gif

Comment 2

[Vitaly Zdanevich]

Attachment: webextension-init-non-retina--normal-speed.gif

Comment 3

[Vitaly Zdanevich]

Attachment: webextension-init-retina--chrome64--normal-speed.gif

Comment 4

[Vitaly Zdanevich]

All gifs with the same codebase - only userdata differs.

Comment 5

[Vitaly Zdanevich]

The extension available at https://addons.mozilla.org/en-US/firefox/addon/intelligent-speaker-tts

Comment 6

[Luca Greco [:rpl] [:luca] [:lgreco]]

I took a brief look to the extension linked in Comment 5 and I tried to reproduce the issue with the extension running in non-oop and oop mode.

I currently tried to reproduce it on Linux and I was able to see the popup window resizing after being opened (not as much as it seems to resize in the attached screencasts, but still enough to be able to notice it), the window resizing seems to be much more visible when the extension runs in oop mode. 

By briefly investigating what the extension is doing once the browserAction popup window is opened, I noticed that the extension is currently:

- running a chrome.storage.sync.get request
- once the storage.sync.get request is completed, it fetches the selected locale (based on the result of the storage.sync.get request or navigator.language) using chrome.runtime.getURL and fetch (and parse its content as json) 
- using the fetched locale file data, it changes any string that match /^__MSG_\w+__$/ () to localize them

This seems to be very likely the reason why the popup resizes visibly when opened (e.g. in the version of the extension that I tried locally there was also a select which can be used to manually switch the popup between different locales, and every time the locale is switched to a different language the same kind of window resizing is also visible while the strings have been changed to the new locale).

Comment 7

[Vitaly Zdanevich]

Gifs were recorded before i18n, the same code on Chromium works without such "animation".
https://chrome.google.com/webstore/detail/beta-intelligent-speaker/eidcpcpmmfiolomceegcagooodnaplmp?authuser=2
By the link may be temporally 404.

Comment 8

[Luca Greco [:rpl] [:luca] [:lgreco]]

The popup window loading mechanism is definitely different on chrome, in comment 6 I mentioned the locales selector because "changing the locales" was making more visible that the content of the popup was changing, and that by triggering a resize of the document it was triggering the resize of the popup (and making the "animated" resize visible even after it has been completely loaded).

I will keep investigating it, but my current feeling is that the popup document is being resized (as a side effect of the changes to the document content) multiple times while the popup is loading.

I took a look at the messages exchanged while the popup window is being opened which can be related to the popup window resizing:

- from ext-browser-content.js multiple "Extension:BrowserResized" messages are sent from _handleDOMChange (https://searchfox.org/mozilla-central/rev/b9f1a4ecba48b2d8c686669e32d109c40e927b48/toolkit/components/extensions/ext-browser-content.js#229-302)

- these events are then received by the BasePopup's receiveMessage method (https://searchfox.org/mozilla-central/rev/b9f1a4ecba48b2d8c686669e32d109c40e927b48/browser/components/extensions/ExtensionPopups.jsm#192-199), which will resizes the browser XUL element that contains the popup window 

The following are the conditions that can trigger the handleDOMChange method:

- receiving a "MozScrolledAreaChanged" message (which should be received when the scrollbars are changing the available area for the content, e.g. by appearing or disappearing), https://searchfox.org/mozilla-central/rev/b9f1a4ecba48b2d8c686669e32d109c40e927b48/toolkit/components/extensions/ext-browser-content.js#199-202

- a "DOMContentLoaded" and "load" events, https://searchfox.org/mozilla-central/rev/b9f1a4ecba48b2d8c686669e32d109c40e927b48/toolkit/components/extensions/ext-browser-content.js#150-187

- the "MutationObserver" created once the "load" event has been received, https://searchfox.org/mozilla-central/rev/b9f1a4ecba48b2d8c686669e32d109c40e927b48/toolkit/components/extensions/ext-browser-content.js#189-197

By looking at the width values sent by the popup window of this particular extensions, it seems that the following values are being received in a rapid sequence:

- between the moment when "DOMContentLoaded" event is received and the popup is shown (the XUL browser of the hidden panel is swapped with the visible one):
  - the document readyState is "interactive"
  - the document width is 635

- After the popup is shown to the user (resized with the received width of 635 px), the following sequence of width values are received (and the popup window resized accordingly):
  - width 635 px, initially with readyState "interactive" and then "complete"
  - width 698 px
  - width 709 px

Comment 9

[Luca Greco [:rpl] [:luca] [:lgreco]]

I'm unable to reproduce the issue as originally reported (and as I've been able to reproduce when I added comment 6 and comment 8), I tried to reproduce it on Linux and on MacOS, but in both the cases the extension popup didn't show any animated resizing when it is opening.

Hi Vitaly,
I'm closing this issue as "RESOLVED,WORKSFORME", because the STRs we used previously doesn't seem to be able to trigger the issue anymore, but there is also a chance that the issue has been workarounded/solved by applying some changes to the extension itself and so fell free to re-open it and needinfo me if you can still reproduce it and you can provide a new STR.

(As a side note I noticed that in the current version of the extension popup, the content of the popup is scrollable, despite the rest of the page seems to be just empty, I briefly looked what is forcing the scrollingHeight on the document.documentElement and it seems that it may be due to the list of languages and voices in the hidden settings, but it doesn't seem to be an issue specific to the extension popups, as I got the same behavior when I tried to open the popup page into a tab with the "Responsive Design Mode" active).