Closed Bug 1932780 Opened 3 months ago Closed 3 months ago

Translations Performance Impacted By Mutation Observer Changes

Categories

(Firefox :: Translations, defect, P1)

defect

Tracking

()

VERIFIED FIXED
135 Branch
Tracking Status
firefox-esr128 --- unaffected
firefox132 --- unaffected
firefox133 --- unaffected
firefox134 --- verified
firefox135 --- verified

People

(Reporter: nordzilla, Assigned: gregtatum)

References

(Regression)

Details

(Keywords: regression)

Attachments

(5 files, 1 obsolete file)

Attached video before-and-after.webm

Description

Bug 1909632 (push log) introduced changes to the mutation observers for Translations, which fixed some long-standing bugs, but have introduced a new impact on performance for Translations.

The following steps to reproduce feel like an edge case of triggering multiple translations in a row with auto-translate enabled, however I have noticed the same impact (though less reliably reproducible) when translating only a single page.

I have particularly noticed this impact when testing out a zhen model and translating content on https://zh.wikipedia.org/wiki/Mozilla_Firefox.


Steps to reproduce

Note:

See attached video for example STR on Linux.

The attached video shows behavior on Linux where hovering the mouse over a hyperlink triggers a translation for that node after the translation has stalled. I have only been able to reproduce this exact behavior on Linux. The slowdown is noticeable on macOS, however mousing over a hyperlink seems to have no effect. I have not tried yet on Windows.

  1. Open the browser to a translatable page, e.g. https://es.wikipedia.org/wiki/Mozilla_Firefox.
  2. Enable auto-translate for the page language.
  3. Click on new hyper links in rapid succession until the page translation is no longer quick.

Expected Behavior
The page translation is fast no matter how many links you click on.

Actual Behavior
The page translation stalls for much of the visible content after clicking on a few links in succession.

Set release status flags based on info from the regressing bug 1909632

:gregtatum, since you are the author of the regressor, bug 1909632, could you take a look?

For more information, please visit BugBot documentation.

I think this has to do with the popovers on Wikipedia causing the mutation observer to run, and changing the timing of the translations queue. We don't do a good job of managing the queue for prioritization. I suspect that Bug 1820252 would help alleviate this. Wikipedia articles are big and take a long time to run. Before, they would go from top to bottom, but I wonder how the queue is getting shifted with the new behavior.

Flags: needinfo?(gtatum)

This was causing an issue where performing an action using a
translationId would affect translations from another page load. This
race condition would be prevalent when using the auto translation
feature and navigating quickly between pages.

Assignee: nobody → gtatum
Status: NEW → ASSIGNED

This is actually a correctness issue, not a perf issue. The mutations were re-translating incorrectly discarded translations request.

Set release status flags based on info from the regressing bug 1909632

Comment on attachment 9439418 [details]
Bug 1932780 - Make the translationsId unique across page loads; r?#translations-reviewers

Revision D229958 was moved to bug 1934997. Setting attachment 9439418 [details] to obsolete.

Attachment #9439418 - Attachment is obsolete: true

This was calling the wrong method and causing bad translation issues
when mutations were being canceled.

Pushed by gtatum@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/fda9afeffafd Correct mistaken use of discardTranslationQueue; r=translations-reviewers,nordzilla https://hg.mozilla.org/integration/autoland/rev/f77db234d79b Correct the spelling of translationId in message passing; r=translations-reviewers,nordzilla
Status: ASSIGNED → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → 135 Branch

The patch landed in nightly and beta is affected.
:gregtatum, is this bug important enough to require an uplift?

  • If yes, please nominate the patch for beta approval.
  • If no, please set status-firefox134 to wontfix.

For more information, please visit BugBot documentation.

Flags: needinfo?(gtatum)

This was calling the wrong method and causing bad translation issues
when mutations were being canceled.

Original Revision: https://phabricator.services.mozilla.com/D231011

Attachment #9442203 - Flags: approval-mozilla-beta?
Attachment #9442204 - Flags: approval-mozilla-beta?

beta Uplift Approval Request

  • User impact if declined: Full page translation will not fully translate a page when there is a mutation.
  • Code covered by automated testing: yes
  • Fix verified in Nightly: yes
  • Needs manual QE test: yes
  • Steps to reproduce for manual QE testing: See comment
  • Risk associated with taking this patch: Low
  • Explanation of risk level: It should be minimal, as it's fixing the call to an incorrect method. The specific fix isn't covered by a test for the behavior as it's hard to test, but the overall codebase for translations is well tested for this area.
  • String changes made/needed: None
  • Is Android affected?: yes
Flags: qe-verify+
Attachment #9442203 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Attachment #9442204 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
QA Whiteboard: [qa-triaged]
Flags: needinfo?(gtatum)

I've managed to reproduce this issue in Nightly 134.0a1 (2024-11-21) using the STR from Comment 0 on Ubuntu 22.04.
Marking this as Verified Fixed, as the issue is no longer reproducible in the latest Nightly 135.0a1 and Firefox 134.0b8 versions on Windows 11, macOS 13, and Ubuntu 22.04, where the page is translated without delay when clicking on various links.

Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: