91231 - nsCharsetMenu should not be initialized on startup

Status: VERIFIED DUPLICATE of bug 64146

(Core :: Internationalization, defect)

Description

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

nsCharsetMenu should not be initialized on startup -- it is slow to initialize
(bug 64146).  At least one thing that would do so is charsetOverlay.js, for
which jag is writing a patch right now.

Comment 1

[jag (Peter Annema)]

Attachment: [patch] Don't load charset menu service for navigator windows

Comment 2

[jag (Peter Annema)]

This moves loading of the service to the onload of only mail windows.

Another possible rewrite would be to just get and store the service in the
"mail" portion of the check at the end of charsetOverlay.js.

Comment 3

[jag (Peter Annema)]

Attachment: [patch] Alternate solution

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I prefer the first solution (for reusability of code, at least).

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Oops, we both missed the use a little higher up in the file.  This should really
be in the menu's oncreate anyway (or so jag says).

Comment 6

[jag (Peter Annema)]

Bah, so that code modifies (or seems to modify) the rdf back-end from which the
menu is built, so we can't move it to oncreate, which is run after the menu is
built.

I'm now pondering rewriting those menus to use js to build themselves and drop
the rdf back-end, but that's going to be quite a bit of work. Is it worth it?

Or, does anyone have other suggestions?

Comment 7

[saari (gone)]

->1.0

Comment 8

[jag (Peter Annema)]

Hmmm, to answer my own question, I guess that in the case where we modify we
could actually force a rebuild of the menu, but I don't remember all the details.

Let me look at this more closely later today.

Comment 9

[jag (Peter Annema)]

Dupe of bug 64146.

*** This bug has been marked as a duplicate of 64146 ***

Comment 10

[Teruko Kobayashi]

Verified as dup.