Unrelated localization stops working when creating a long-lived RefPtr<Localization> object in uriloader/base/nsDocLoader.cpp
Categories
(Core :: Internationalization: Localization, defect)
Tracking
()
People
(Reporter: manuel, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
44.98 KB,
image/png
|
Details |
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
Comment 1•3 years ago
|
||
The severity field is not set for this bug.
:zbraniecki, could you have a look please?
For more information, please visit auto_nag documentation.
Comment 3•3 years ago
|
||
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.
Comment 4•2 years ago
|
||
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.
Comment 5•2 years ago
|
||
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.
Description
•