1809926 - Firefox Translations extension adds noticeable (>1s) delay to browser readiness at launch time

Status: RESOLVED MOVED

(Firefox :: Translations, defect)

Description

[[e-mail]]

Attachment: Profiling data with Firefox Translations enabled

This is especially noticeable when a content blocker is also enabled, as these will delay webpage load time until they are ready.

Steps to reproduce:

• Install uBlock Origin (from https://addons.mozilla.org/en-US/firefox/addon/ublock-origin/)
• Install Firefox Translations (from https://addons.mozilla.org/en-US/firefox/addon/firefox-translations/)
  • I wouldn't know but it's possible the number of currently downloaded translations package influence -- I can't remember how many I have locally on my side, maybe ~5
• Open a simple webpage (i.e. http://example.org/)
• Check the setting "Open previous windows and tabs" so that the browser opens the above webpage at next launch
• Quit Firefox
• Launch Firefox

Notice the >1s delay for the restored webpage to open compared to when Firefox Translations is disabled.

Two profiling sessions attached, one with Firefox Translations enabled, the other without Firefox Translations -- all else being the same.

Comment 1

[[e-mail]]

Attachment: Profiling data with Firefox Translations disabled

Comment 2

[[e-mail]]

Attachment: Screenshot of profiling data showing CPU usage in WebExtensions process

Comment 3

[[e-mail]]

In case the number of downloaded translations packages matter, I used the dev tools to peruse how many translations packages appear to be present in the Firefox Translations cache storage on my side, and I count 7, the following: deen, enpt, esen, fren, plen, pten, ruen.

Comment 4

[Greg Tatum [:gregtatum]]

The language checker is being loaded and probably checking all the restored pages. The fix here would be to move it into a worker, defer doing this until later, or not running the language detection on tab restore.

Comment 5

[Greg Tatum [:gregtatum]]

https://github.com/mozilla/firefox-translations/blob/af29a6ca83c4e98566d510c0f150667a43e506d2/extension/controller/languageDetection/fasttext.js#L12

Here where fasttext is loaded, and fasttext is also being used to check what the language is.

Comment 6

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:anatal, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 7

[Shane Caraveo (:mixedpuppy)]

Is it the same without uBlock? IOW is it a delay caused by having both, or is it just a Translations issue?

Comment 8

[André Natal]

There's at least 3 different "translation" implementations atm that took me an instant to figure that this was actually related to the extension, whose codebase and issue tracker is actually on github: https://github.com/mozilla/firefox-translations/issues

I've moved this there along a reference and will close it: https://github.com/mozilla/firefox-translations/issues/666

Thanks rhill!

Comment 9

[[e-mail]]

Is it the same without uBlock? IOW is it a delay caused by having both, or is it just a Translations issue?

Not sure the delay is noticeable when not using a content blocker which typically holds back first page load. In a profiling session without any other extension than Firefox Translations, I can see the currently active page starts loading while Firefox Translations extension is hogging the CPU in the WebExtensions process (for about 1.7s). So mainly the effect is to delay other extensions' time-to-readiness, which in the case of content blockers causes the whole browser's time-to-readiness to be delayed.