Open Bug 1752552 Opened 3 years ago Updated 2 years ago

Unrelated localization stops working when creating a long-lived RefPtr<Localization> object in uriloader/base/nsDocLoader.cpp

Categories

(Core :: Internationalization: Localization, defect)

x86_64
Linux
defect

Tracking

()

People

(Reporter: manuel, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

I've set the platform to my platform, because I couldn't yet check if it applies to others as well.

Patch to show this behavior: https://phabricator.services.mozilla.com/D136612?id=532851 (you can click on "download raw diff" to download the patch). I've attached an image showing how firefox looks to me with the patch applied.

The log when running with this patch looks like this:

[fluent] Couldn't find a message: browser-main-window
[fluent] Couldn't find a message: browser-main-window-title
[fluent] Couldn't find a message: window-new-shortcut
[fluent] Couldn't find a message: tab-new-shortcut
[fluent] Couldn't find a message: location-open-shortcut
[fluent] Couldn't find a message: location-open-shortcut-alt
[fluent] Couldn't find a message: search-focus-shortcut
[fluent] Couldn't find a message: search-focus-shortcut-alt
[fluent] Couldn't find a message: downloads-shortcut
[fluent] Couldn't find a message: addons-shortcut
...

Using a short-lived in the function each time a translation is requested is working without errors with this patch https://phabricator.services.mozilla.com/D136612?id=530769

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

For more information, please visit auto_nag documentation.

Flags: needinfo?(zibi)

-> :nordzilla

Flags: needinfo?(zibi) → needinfo?(enordin)

This looks like something that we will want to prioritize resolving. I am marking this as S2 for now, given that it is at least working with a short-lived function, and I am leaving my NI open.

I intend to revisit this bug with a better idea of my schedule next week.

Severity: -- → S2

I've looked into this a bit.

The issue causing the way things are displayed in the screenshot appears to be caused by a null pointer.

There are cases in which the class is being instantiated with a null mL10n. The initialization of mL10n needs to be moved into the constructor that takes an argument, rather than only in the default constructor.

That being said, even with the initialization moved to the other constructor I am still encountering problems of a different nature, in which the mL10n object appears to be attempting to look up resources from other, unrelated areas in the code.

I'm continuing to investigate this in between other work and as such I'm leaving my NI open.

I believe that I mistriaged this as an S2 bug earlier this year, based on our triage guidelines: https://wiki.mozilla.org/BMO/UserGuide/BugFields#bug_severity

S2 is defined as: "Fix in the next release cycle or the following (nightly + 1 or nightly + 2)"

S3 is defined as: "Backlog"

I do believe that we should look at this soon, but given that there is an existing workaround with a short-lived object and that I was unable to diagnose the issue after a first look, I have allowed this to sit in the backlog since that time, and I should have moved it to S3 at that point.

Severity: S2 → S3
Flags: needinfo?(enordin)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: