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

RESOLVED FIXED in Thunderbird 3.1b2

Status

Thunderbird
Folder and Message Lists
RESOLVED FIXED
7 years ago
7 years ago

People

(Reporter: jcranmer, Assigned: sid0)

Tracking

Trunk
Thunderbird 3.1b2
Bug Flags:
in-testsuite +

Thunderbird Tracking Flags

(thunderbird3.1 rc1-fixed)

Details

Attachments

(2 attachments)

(Reporter)

Description

7 years ago
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.
(Assignee)

Comment 1

7 years ago
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.
(Reporter)

Comment 2

7 years ago
It most definitely exists on recent nightlies, and I think it exists on 3.0 branch, but I'm not entirely sure.
Version: 3.0 → Trunk
(Assignee)

Comment 3

7 years ago
Created attachment 434626 [details] [diff] [review]
patch + test

This is layered on top of the patch in bug 542165.
Assignee: nobody → sid.bugzilla
Status: NEW → ASSIGNED
Attachment #434626 - Flags: review?(bugmail)
(Assignee)

Updated

7 years ago
Depends on: 542165
Attachment #434626 - Flags: review?(bugmail) → review+
Comment on attachment 434626 [details] [diff] [review]
patch + test

Muy excelente.
(Assignee)

Comment 5

7 years ago
http://hg.mozilla.org/comm-central/rev/fef857483ad7
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 3.1b2
(Reporter)

Comment 6

7 years ago
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];
(Reporter)

Comment 7

7 years ago
Created attachment 443856 [details] [diff] [review]
Fix the name issue
Attachment #443856 - Flags: review?
(Reporter)

Updated

7 years ago
Attachment #443856 - Flags: review? → review?(bugmail)
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.
Attachment #443856 - Flags: review?(bugmail)
Attachment #443856 - Flags: review+
Attachment #443856 - Flags: approval-thunderbird3.1+
(Reporter)

Comment 9

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

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

Comment 10

7 years ago
Checked into comm-1.9.2 as changeset 5583:cd279d6b4fde.
status-thunderbird3.1: --- → rc1-fixed
You need to log in before you can comment on or make changes to this bug.