1965261 - Inconsistencies in translation detection (menu offering availability)

Status: RESOLVED FIXED

(Firefox for Android :: Translations, defect, P1)

Description

[Aaron Train [:aaronmt]]

There is some inconsistencies in the menu offering to "Translate page" which I assume depends on translation feature detection.

E.g,

• Launch Nightly (05/08)
• Tap the Wikipedia tile
• Open menu, see no "Translate page"
• Refresh page, open menu, see "Translate page"

Caught via verifyTabMainMenuItemsTest

Comment 1

[Olivia Hall [:olivia]]

Might be related to bug 1964647? We have some ANRs in that area. :polly has a patch up and is running tests right now on it.

Comment 2

[Aaron Train [:aaronmt]]

Mentioned on Slack, but the menu option does show up if I wait a little bit before opening the menu.

Comment 3

[Olivia Hall [:olivia]]

Thanks, yeah sounds like bug 1958042 to me too then.

Comment 4

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

:boek, since you are the author of the regressor, bug 1958042, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 5

[Donal Meehan [:dmeehan - PTO - Back Oct 13]]

We are in the final week of beta for Fx139, with only 2 beta builds left.
:olivia, could this be triaged for Severity? (pinging you as Triage Owner)
Is there a user-facing problem here that concerns Fx139?

Comment 6

[Olivia Hall [:olivia]]

Is there a user-facing problem here that concerns Fx139?

Yes, in the sense that if a user was fast enough, then they could see this issue. I was able to see the missing "Translate" menu item by launching directly using the intent adb shell am start -d "https://www.mozilla.org/fr" -p org.mozilla.fenix and immediately opening the browser menu. However, the workaround is simply opening the translate menu again. The toolbar option to the feature also populates as expected.

No, in the sense that I don't think that most users will be fast enough to perceive this issue. Launching from an intent that way and immediately opening the browser menu would be an edge case for most users.

I think this should be fixed, but it is more an S3 because there are workarounds and it is difficult to be be faster than the menu populating under most conditions. (We should monitor for reports in case this assumption is mistaken.)

Hi :segun,

Could your squad take a look at the regression? It probably arose from trying to improve performance in bug 1958042.

Comment 7

[Segun Famisa [:segun]]

Hi :olivia,

Indeed, it is possible that this is caused by bug 1958042. However, the translations initialisation has a significant impact on our startup performance, and we moved it to the visual completeness queue, so that it does not have an impact on app startup.

There's a 5 second delay in the visual completeness queue, which accounts for why the test is failing, or why it does not appear immediately, like :aaronmt mentioned

but the menu option does show up if I wait a little bit before opening the menu.

We think that there's room for improvement of the UX here, because we should probably still be able to enable the UI element without initializing the translations which slow down startup. Is this something the translation folks would be able to look into?

Comment 8

[Olivia Hall [:olivia]]

Thanks for taking a look!

we should probably still be able to enable the UI element

It is a little complicated because we don't want to enable the UI element on devices that translations is not supported on. On bug 1958042 comment 2, I gave an overview of all the nuance of each of those startup calls. requestEngineSupport probably needs to happen extremely early. We can help it out by storing this result somewhere and recalling it, because it shouldn't change. (The engine support is linked to device hardware, but the first time would still need to ask the translations engine in toolkit.)

Although, even making the supported engine call early, solving this would still be tricky because a lot of information is retrieved to show in the UI. (Like supported language names, user settings, etc. I tend to think that we'd have the language names by the time the user opened the feature, though. Assuming we already have the hardware support flag early.)

Comment 9

[Kaya [:kaya]]

Attachment: Bug 1965261 - Initialize translations flow when page load is completed.

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/661f9f179d9d
Initialize translations flow when page load is completed. r=android-reviewers,matt-tighe

Comment 11

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/661f9f179d9d

Comment 12

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

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

• If yes, please nominate the patch for beta approval.
  • See https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift for documentation on how to request an uplift.
• If no, please set status-firefox139 to wontfix.

For more information, please visit BugBot documentation.

Comment 13

[Kaya [:kaya]]

keeping it as fix-optional for now.

Comment 14

[Kaya [:kaya]]

Attachment: Bug 1965261 - Initialize translations flow when page load is completed.

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

Comment 15

[Phabricator Automation]

firefox-release Uplift Approval Request

• User impact if declined: Buggy translation initialization, inconsistent behavior in the flow
• Code covered by automated testing: yes
• Fix verified in Nightly: yes
• Needs manual QE test: no
• Steps to reproduce for manual QE testing: -
• Risk associated with taking this patch: low
• Explanation of risk level: It is baked in Nightly and Beta. There's no crash reports related to this issue.
• String changes made/needed: -
• Is Android affected?: yes

Comment 16

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/a2e29e2cf5b8
https://hg.mozilla.org/releases/mozilla-release/rev/765d18fd4a7a