554558 - gFolderTreeView.load fails if the mode is not provided by TB

Status: RESOLVED FIXED

(Thunderbird :: Folder and Message Lists, defect)

Description

[Joshua Cranmer [:jcranmer]]

So, when making my foldercat extension, I noticed that gFolderTreeView.load has a bug in it:

    if (this._mode in this._modeDisplayNames)
      string = this._modeDisplayNames[this._mode];
    else {
      let key = "folderPaneModeHeader_" + aMode;
      string = document.getElementById("bundle_messenger").getString(key);
    }

When this runs, this._mode happens to be null, so the first if statement is not executed. It then tries to load the string from the message bundle which happens to fail at runtime.

Instead, the first line should be this.mode, which will properly load this._mode if it is not set.

Comment 1

[Rain [:rain1] (inactive)]

Does this work on trunk? I'd be surprised if it does... or something could possibly be initializing this._mode on trunk before load. Either way it's definitely a bug.

Comment 2

[Joshua Cranmer [:jcranmer]]

It most definitely exists on recent nightlies, and I think it exists on 3.0 branch, but I'm not entirely sure.

Comment 3

[Rain [:rain1] (inactive)]

Attachment: patch + test

This is layered on top of the patch in bug 542165.

Comment 4

[Andrew Sutherland [:asuth] (he/him)]

Comment on attachment 434626 [details] [diff] [review]
patch + test

Muy excelente.

Comment 5

[Rain [:rain1] (inactive)]

http://hg.mozilla.org/comm-central/rev/fef857483ad7

Comment 6

[Joshua Cranmer [:jcranmer]]

So, testing this out with my extension indicates it's not quite fully fixed. The current line is:
        if (this.mode in this._modeDisplayNames)
          string = this._modeDisplayNames;

If you load up an extension as the default, you'll find that this causes the string to become "[object Object]".

The correct line should be:
        if (this.mode in this._modeDisplayNames)
          string = this._modeDisplayNames[this.mode];

Comment 7

[Joshua Cranmer [:jcranmer]]

Attachment: Fix the name issue

Comment 8

[Andrew Sutherland [:asuth] (he/him)]

Comment on attachment 443856 [details] [diff] [review]
Fix the name issue

Given the simplicity of the fix, this should go in 3.1 for sure.

Comment 9

[Joshua Cranmer [:jcranmer]]

(In reply to comment #7)
> Created an attachment (id=443856) [details]
> Fix the name issue

Checked into comm-central as changeset 5587:46de9c4360e5.

Comment 10

[Joshua Cranmer [:jcranmer]]

Checked into comm-1.9.2 as changeset 5583:cd279d6b4fde.