Closed Bug 1629291 Opened 1 year ago Closed 11 months ago

Context menus are blank on macOS

Categories

(Core :: Internationalization, defect)

75 Branch
defect

Tracking

()

RESOLVED FIXED
mozilla78
Tracking Status
firefox78 --- fixed

People

(Reporter: dw_ff, Assigned: zbraniecki, NeedInfo)

References

Details

Attachments

(2 files)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:75.0) Gecko/20100101 Firefox/75.0

Steps to reproduce:

Ctrl-click on a tab in FF 75.0 on Macbook Pro w/Mojave 10.14.6.
Extensions: Facebook Container, Kaspersky Security, Kaspersky Password Manager, OneTab.

Actual results:

Drop down context menu appears but is blank -- no text, just a gray box. Mousing over the drop down highlights each entry as if the text were there. Menus cascade, but the sub-menus are blank as well.

Expected results:

Menu item text should show.

Summary: Drop down menus are blank → Context menus are blank on macOS

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → Security: PSM
Product: Firefox → Core

Can you try starting Firefox with the -purgecache option?

  1. Quit Firefox completely
  2. Open Firefox from a terminal, adding -purgecache. You can follow these instructions, just replace -P with -purgecache

If that doesn't work, can try creating the instructions here (create new profile, then switch back to the normal one)?
https://bugzilla.mozilla.org/show_bug.cgi?id=1603956#c124

Component: Security: PSM → Untriaged
Product: Core → Firefox

Was also able to reproduce the problem with a new profile in safe mode. Switching profiles doesn't seem to matter. However, rebooting has fixed the problem for now.

Thanks for responding so quickly!

Duplicate of this bug: 1630077

As written on Matrix the other day, the amount of reports seems to indicate an increase in frequency for this type of issues.

Can it be that, by fixing the cache not being used in bug 1603956, we actually exposed more issues?

Status: UNCONFIRMED → NEW
Ever confirmed: true
See Also: → 1603956

Can the cache be incomplete in some way, and if so, how would we know/tell ? Is there any way users who see this can gather more debug info?

Flags: needinfo?(dtownsend)

Resetting severity to default of --.

(In reply to :Gijs (he/him) from comment #6)

Can the cache be incomplete in some way, and if so, how would we know/tell ? Is there any way users who see this can gather more debug info?

It looks like if we fail to translate some elements we abandon the rest of translations, but still update the cache and mark it as translated, so yes we could end up in this state. When a translation fails we abandon translating any elements left to do, I guess it is possible that the context menu elements come last but if not I'd expect to see other untranslated elements in this case. But I wouldn't expect a reboot to fix this issue (once the problem is cached purgecaches would have to be used).

Flags: needinfo?(dtownsend)

Ah, that sounds plausible. It should be relatively easy to just not put the cache in if we failed to translate all elements.

Is this a dupe of bug 1603956 then?

(In reply to Zibi Braniecki [:zbraniecki][:gandalf] from comment #10)

Is this a dupe of bug 1603956 then?

My understanding is bug 1603956 is about the case where there is a race in creating the cache because two windows open, cf https://bugzilla.mozilla.org/show_bug.cgi?id=1603956#c94 . What Dave is describing here (broken translations meaning we stop doing other translations, plus then caching the wrong thing) seems like an orthogonal problem. It even seems like this problem may persist without the cache. I don't understand why one broken translation breaks the remaining ones; fluent was supposed to fix that kind of problem...

(In reply to Zibi Braniecki [:zbraniecki][:gandalf] from comment #10)

Is this a dupe of bug 1603956 then?

No, bug 1603956 is caused by two windows racing to load the same prototype. I don't really know if this bug is caused by a failure to translate some elements or something else.(In reply to :Gijs (he/him) from comment #11)

(In reply to Zibi Braniecki [:zbraniecki][:gandalf] from comment #10)

Is this a dupe of bug 1603956 then?

My understanding is bug 1603956 is about the case where there is a race in creating the cache because two windows open, cf https://bugzilla.mozilla.org/show_bug.cgi?id=1603956#c94 .

Yes, that's right.

What Dave is describing here (broken translations meaning we stop doing other translations, plus then caching the wrong thing) seems like an orthogonal problem. It even seems like this problem may persist without the cache. I don't understand why one broken translation breaks the remaining ones; fluent was supposed to fix that kind of problem...

It breaks it in that we just give up localizing the list of elements in the presence of a single error (https://searchfox.org/mozilla-central/rev/d2cec90777d573585f8477d5170892e5dcdfb0ab/dom/l10n/DOMLocalization.cpp#470). I feel like at an early point that caused us to not cache or something but I'm not seeing that happen right now. I may be missing something though, this stuff is pretty complicated at this point :(

Ok, that makes sense. Let's keep it separated, but I worry that the difference may not be observable so looking for people who can reproduce it may be confusing.

It even seems like this problem may persist without the cache.

I don't think so. The problem is that even if you clear the cache, the next time we translate not fully, and store in the cache, and then the next time we load from cache without translating.

What we should do, maybe, is not cache if the translation wasn't complete, alternatively we may want to track if translation was successful per element which may be hard for our current cache.
Or, we may want to store in cache the list of elements that failed to be translated...

See Also: → 1632486

(In reply to Zibi Braniecki [:zbraniecki][:gandalf] from comment #13)

What we should do, maybe, is not cache if the translation wasn't complete, alternatively we may want to track if translation was successful per element which may be hard for our current cache.
Or, we may want to store in cache the list of elements that failed to be translated...

Not caching at all if the translation wasn't completed for any element sounds like the simplest way to solve this. Is there an easy way / existing place to make that change, or does it require changes with how the cache works?

Flags: needinfo?(gandalf)

Hi,

I will move this over to a component so developers can take a look over it. If is not the correct component please feel free to change it to an appropriate one.

Thanks for the report.

Clara

Component: Untriaged → Menus

Is there an easy way / existing place to make that change, or does it require changes with how the cache works?

It just needs a patch around https://searchfox.org/mozilla-central/source/dom/base/Document.cpp#3937 to pass a success/failure flag and not set the cache if it failed.

Flags: needinfo?(gandalf)

Per comment #7 the fix is internal to documentl10n and its DOM integration, so moving out of menus.

Zibi, can you take this?

Severity: normal → S1
Component: Menus → Internationalization
Flags: needinfo?(gandalf)
Product: Firefox → Core

Yep, taking. Let's see if the solution proposed in comment 16 will fix it.

Assignee: nobody → gandalf
Status: NEW → ASSIGNED
Flags: needinfo?(gandalf)

Mossop - does this patch look like what you were hoping for?

It seems that we were quite resilient even without it and if there was a missing string, we'd still handle all other strings and cache, so it shouldn't result in fully broken UI.
But there's a number of failure paths in the chain that would prevent the document from being translated, and all of them were ending up with the cache being marked as localized.

With this patch each early exist and promise rejection from translation will result with cache not being set.

I don't know if this will result this bug, but I think the change does make sense either way.

Flags: needinfo?(dtownsend)
Duplicate of this bug: 1637326
Pushed by zbraniecki@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/4309266ff43d
Don't set l10n as cached if there was any error during initial translation. r=mossop
Status: ASSIGNED → RESOLVED
Closed: 11 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla78

Backed out for frequent assertion failures on ErrorResult.h

backout: https://hg.mozilla.org/integration/autoland/rev/4648ea360a394f64de8a67a086e879033865523b

push: https://treeherder.mozilla.org/#/jobs?repo=autoland&searchStr=os%2Cx%2C10.14%2Cdebug%2Cfirefox%2Cfunctional%2Ctests%2C%28local%29%2Ctest-macosx1014-64%2Fdebug-firefox-ui-functional-local-e10s%2Cfxfn-l%28en-us%29&revision=4309266ff43d3a4f398200c7a5df768a021ed0be&selectedTaskRun=CrrMURZIQ42I93H_LnIWOw-0

failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=302060707&repo=autoland&lineNumber=1546

[task 2020-05-13T06:33:01.105Z] 06:33:01 INFO - console.warn: "[fluent] Missing translations in en-US: newtab-page-title."
[task 2020-05-13T06:33:01.105Z] 06:33:01 INFO - [Child 1890, Main Thread] WARNING: 'rv.Failed()', file /builds/worker/checkouts/gecko/dom/l10n/DOMLocalization.cpp, line 222
[task 2020-05-13T06:33:01.105Z] 06:33:01 INFO - Assertion failure: !Failed(), at /builds/worker/workspace/obj-build/dist/include/mozilla/ErrorResult.h:582
[task 2020-05-13T06:33:01.106Z] 06:33:01 INFO - #01: mac_plugin_interposing_child_OnShowCursor[/Users/cltbld/tasks/task_1589349504/build/application/Firefox NightlyDebug.app/Contents/MacOS/XUL +0x43e85e3]
[task 2020-05-13T06:33:01.106Z] 06:33:01 INFO - #02: mac_plugin_interposing_child_OnShowCursor[/Users/cltbld/tasks/task_1589349504/build/application/Firefox NightlyDebug.app/Contents/MacOS/XUL +0x40b6e94]
[task 2020-05-13T06:33:01.106Z] 06:33:01 INFO - #03: mac_plugin_interposing_child_OnShowCursor[/Users/cltbld/tasks/task_1589349504/build/application/Firefox NightlyDebug.app/Contents/MacOS/XUL +0x40b74af]
[task 2020-05-13T06:33:01.106Z] 06:33:01 INFO - #04: XRE_GetBootstrap[/Users/cltbld/tasks/task_1589349504/build/application/Firefox NightlyDebug.app/Contents/MacOS/XUL +0x5ef3929]
[task 2020-05-13T06:33:01.106Z] 06:33:01 INFO - #05: XRE_GetBootstrap[/Users/cltbld/tasks/task_1589349504/build/application/Firefox NightlyDebug.app/Contents/MacOS/XUL +0x5ef31af]
[task 2020-05-13T06:33:01.106Z] 06:33:01 INFO - #06: XRE_GetBootstrap[/Users/cltbld/tasks/task_1589349504/build/application/Firefox NightlyDebug.app/Contents/MacOS/XUL +0x5ef4540]
[task 2020-05-13T06:33:01.106Z] 06:33:01 INFO - #07: XRE_GetBootstrap[/Users/cltbld/tasks/task_1589349504/build/application/Firefox NightlyDebug.app/Contents/MacOS/XUL +0x5f593f7]
[task 2020-05-13T06:33:01.106Z] 06:33:01 INFO - #08: XRE_GetBootstrap[/Users/cltbld/tasks/task_1589349504/build/application/Firefox NightlyDebug.app/Contents/MacOS/XUL +0x615b58d]
[task 2020-05-13T06:33:01.106Z] 06:33:01 INFO - #09: XRE_GetBootstrap[/Users/cltbld/tasks/task_1589349504/build/application/Firefox NightlyDebug.app/Contents/MacOS/XUL +0x5ef3929]
[task 2020-05-13T06:33:01.107Z] 06:33:01 INFO - #10: XRE_GetBootstrap[/Users/cltbld/tasks/task_1589349504/build/application/Firefox NightlyDebug.app/Contents/MacOS/XUL +0x5ef31af]
[task 2020-05-13T06:33:01.107Z] 06:33:01 INFO - #11: XRE_GetBootstrap[/Users/cltbld/tasks/task_1589349504/build/application/Firefox NightlyDebug.app/Contents/MacOS/XUL +0x5ef4540]
[task 2020-05-13T06:33:01.107Z] 06:33:01 INFO - #12: XRE_GetBootstrap[/Users/cltbld/tasks/task_1589349504/build/application/Firefox NightlyDebug.app/Contents/MacOS/XUL +0x5ffebdf]
[task 2020-05-13T06:33:01.107Z] 06:33:01 INFO - #13: mozilla_dump_image[/Users/cltbld/tasks/task_1589349504/build/application/Firefox NightlyDebug.app/Contents/MacOS/XUL +0x22da61d]
[task 2020-05-13T06:33:01.107Z] 06:33:01 INFO - #14: BeaverTriple_areEqual[/Users/cltbld/tasks/task_1589349504/build/application/Firefox NightlyDebug.app/Contents/MacOS/XUL +0x879e1]
[task 2020-05-13T06:33:01.107Z] 06:33:01 INFO - #15: BeaverTriple_areEqual[/Users/cltbld/tasks/task_1589349504/build/application/Firefox NightlyDebug.app/Contents/MacOS/XUL +0x86a36]
[task 2020-05-13T06:33:01.107Z] 06:33:01 INFO - #16: BeaverTriple_areEqual[/Users/cltbld/tasks/task_1589349504/build/application/Firefox NightlyDebug.app/Contents/MacOS/XUL +0x70096]
[task 2020-05-13T06:33:01.107Z] 06:33:01 INFO - #17: BeaverTriple_areEqual[/Users/cltbld/tasks/task_1589349504/build/application/Firefox NightlyDebug.app/Contents/MacOS/XUL +0x70c7a]
[task 2020-05-13T06:33:01.107Z] 06:33:01 INFO - #18: nsXPTCStubBase::Stub249()[/Users/cltbld/tasks/task_1589349504/build/application/Firefox NightlyDebug.app/Contents/MacOS/XUL +0xffc418]
[task 2020-05-13T06:33:01.108Z] 06:33:01 INFO - #19: NS_NewLocalFileWithCFURL[/Users/cltbld/tasks/task_1589349504/build/application/Firefox NightlyDebug.app/Contents/MacOS/XUL +0x188f28]
[task 2020-05-13T06:33:01.108Z] 06:33:01 INFO - #20: NS_NewLocalFileWithCFURL[/Users/cltbld/tasks/task_1589349504/build/application/Firefox NightlyDebug.app/Contents/MacOS/XUL +0x18e92c]
[task 2020-05-13T06:33:01.108Z] 06:33:01 INFO - #21: nsXPTCStubBase::Stub249()[/Users/cltbld/tasks/task_1589349504/build/application/Firefox NightlyDebug.app/Contents/MacOS/XUL +0x9ab3e4]
[task 2020-05-13T06:33:01.108Z] 06:33:01 INFO - #22: nsXPTCStubBase::Stub249()[/Users/cltbld/tasks/task_1589349504/build/application/Firefox NightlyDebug.app/Contents/MacOS/XUL +0x93afbe]
[task 2020-05-13T06:33:01.108Z] 06:33:01 INFO - #23: mac_plugin_interposing_child_OnShowCursor[/Users/cltbld/tasks/task_1589349504/build/application/Firefox NightlyDebug.app/Contents/MacOS/XUL +0x447f7f9]
[task 2020-05-13T06:33:01.108Z] 06:33:01 INFO - #24: mac_plugin_interposing_child_OnShowCursor[/Users/cltbld/tasks/task_1589349504/build/application/Firefox NightlyDebug.app/Contents/MacOS/XUL +0x44f5d33]
[task 2020-05-13T06:33:01.108Z] 06:33:01 INFO - #25: catch_exception_raise[/Users/cltbld/tasks/task_1589349504/build/application/Firefox NightlyDebug.app/Contents/MacOS/XUL +0x5db75ae]
[task 2020-05-13T06:33:01.109Z] 06:33:01 INFO - #26: nsXPTCStubBase::Stub249()[/Users/cltbld/tasks/task_1589349504/build/application/Firefox NightlyDebug.app/Contents/MacOS/XUL +0x9abdf1]
[task 2020-05-13T06:33:01.109Z] 06:33:01 INFO - #27: nsXPTCStubBase::Stub249()[/Users/cltbld/tasks/task_1589349504/build/application/Firefox NightlyDebug.app/Contents/MacOS/XUL +0x93afbe]
[task 2020-05-13T06:33:01.109Z] 06:33:01 INFO - #28: catch_exception_raise[/Users/cltbld/tasks/task_1589349504/build/application/Firefox NightlyDebug.app/Contents/MacOS/XUL +0x5db7037]
[task 2020-05-13T06:33:01.109Z] 06:33:01 INFO - #29: ???[/Users/cltbld/tasks/task_1589349504/build/application/Firefox NightlyDebug.app/Contents/MacOS/plugin-container.app/Contents/MacOS/plugin-container +0xf0b]
[task 2020-05-13T06:33:01.344Z] 06:33:01 INFO - Couldn't convert chrome URL: chrome://branding/locale/brand.properties

Flags: needinfo?(gandalf)
Attached patch followup.diffSplinter Review

Mossop - seems like the ErrorResult overuse for missing translation is a bit unfortunate here.

The simplest solution I think is separate "translation failed, but the system works OK" from "something went really wrong" - I'd like to communicate the former with the boolean result, and the latter with ErrorResult.

Here's a patch on top of the original one that does it. I didn't dig into L10nOverlays where I should introduce the same separation (failing to parse FTL message as HTML DOM shouldn't be fatal), but for now I think this will fix it and let us land.

Lmk what you think. (I'll apply it on top of the PR after the backout reaches the central)

Flags: needinfo?(gandalf)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Target Milestone: mozilla78 → ---
Flags: needinfo?(dtownsend)
Pushed by zbraniecki@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/d2592450a5df
Don't set l10n as cached if there was any error during initial translation. r=mossop

My issue was absorbed into this one as my issue was the same but in Windows 10. I have resolved MY issue by removing the add on "Dark Mode (WebExtension)" (https://addons.mozilla.org/en-US/firefox/addon/dark-mode-webextension/) by Bernard (https://addons.mozilla.org/en-US/firefox/user/11809182/). Once the add-on was deleted and Firefox restarted, the menu text reappeared. Simply disabling the add-on did not solve the problem.

I "resolved" my problem when v76.0.1 installed itself.

Status: REOPENED → RESOLVED
Closed: 11 months ago11 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla78
Flags: qe-verify+

Hello, so I tried reproducing the issue with Firefox 77.0a1 (2020-04-11) under macOS 10.15.5 and installing various add-ons (mentioned in Comment 0) but had no success.

dw_ff, could you verify if the issue is fixed on your side? Thanks!

Flags: qe-verify+ → needinfo?(dw_ff)
You need to log in before you can comment on or make changes to this bug.