Closed Bug 1604960 Opened 5 years ago Closed 5 years ago

Migrate all basic text actions l10n to Fluent

Categories

(Toolkit :: General, task, P3)

task

Tracking

()

RESOLVED FIXED
mozilla73
Tracking Status
firefox73 --- fixed

People

(Reporter: zbraniecki, Assigned: zbraniecki)

References

Details

Attachments

(1 file)

In result of bug 1600528, we now have textActions.ftl. Let's migrate to it all of m-c.

Assignee: nobody → gandalf
Blocks: 1581212
Status: NEW → ASSIGNED
Priority: -- → P3

Welp, it actually removes 20 DTD calls from M1!

Blocks: 1579477
No longer blocks: 1581212

With this patch, when I enable in FX in a txt field the spell checking I get this error two times:

[Exception... "Component returned failure code: 0x80520012 (NS_ERROR_FILE_NOT_FOUND) [nsIXPCComponents_Utils.readUTF8URI]" nsresult: "0x80520012 (NS_ERROR_FILE_NOT_FOUND)" location: "JS frame :: resource://gre/modules/L10nRegistry.jsm :: this.L10nRegistry.loadSync :: line 759" data: no] L10nRegistry.jsm:759

With this patch, when I enable in FX in a txt field the spell checking I get this error two times:

Can you provide STR please?

Flags: needinfo?(richard.marti)

Open https://searchfox.org/ then in one of the two text fields right click and tick Check Spelling on. Now right click again (the Languages menuitem should be shown now) and the errors appear.

Flags: needinfo?(richard.marti)

Open https://searchfox.org/ then in one of the two text fields right click and tick Check Spelling on. Now right click again (the Languages menuitem should be shown now) and the errors appear.

This is present in central as well and is not specific to this patch.

The source of the exception is that somehow the try/catch here https://searchfox.org/mozilla-central/source/intl/l10n/L10nRegistry.jsm#757-761 doesn't silence the error when we synchronously try to load the FTL file.

It's a red herring - we try to load it from the browser omni.ja first, and then from the toolkit's one where we find it. The first should throw, and it does, it just should be silenced.

You can file it as a new bug.

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

It's a red herring - we try to load it from the browser omni.ja first, and then from the toolkit's one where we find it. The first should throw, and it does, it just should be silenced.

It's because it's NS_ERROR_FILE_NOT_FOUND instead of the 2 errors that we're specifically looking for.

Filed bug 1605489 for the errors.

Pushed by zbraniecki@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/0267e42c0db5 Migrate all text actions to use Fluent. r=fluent-reviewers,Gijs,flod

Green try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=57fadc384c7d4d54017160b886d2c1c2412a34c6

Minor updates:

  • In browser/components/places/content/places.xhtml one MACOS ifdef delete action switched
  • devtools/client/webconsole/test/browser/browser_console_context_menu_entries.js updated to new IDs.
Flags: needinfo?(gandalf)
Pushed by zbraniecki@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/ca49196116bb Migrate all text actions to use Fluent. r=fluent-reviewers,Gijs,flod
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla73
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: