If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

gloda's folder property indexingPriority set as function text, not number

RESOLVED FIXED in Thunderbird 3.3a1

Status

MailNews Core
Database
RESOLVED FIXED
7 years ago
7 years ago

People

(Reporter: rkent, Assigned: rkent)

Tracking

Trunk
Thunderbird 3.3a1
x86
Windows 7
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(blocking-thunderbird3.1 rc1+, thunderbird3.1 rc1-fixed)

Details

(Whiteboard: [fixed 3.1 RC 1 build 3])

Attachments

(1 attachment)

(Assignee)

Description

7 years ago
At http://mxr.mozilla.org/comm-central/source/mailnews/db/gloda/modules/index_msg.js#1724 we have the following code:

aFolder.setStringProperty("indexingPriority", Number.toString(aPriority));

This sets the string property to a string representation of a function, not to a number.  We need:

aFolder.setStringProperty("indexingPriority", Number(aPriority).toString());

This does not seem to be noticed in normal operation, because the folder version of indexingPriority is a secondary value, only used if Gloda goes away.
But its value will be completely polluted in the user's profile if this is not fixed, so I hope that if there is a respin of 3.1, then the low risk one-line fix for this can be included. Not likely to block though.

patch to follow once I get my 1.9.2 build working with up to date code.
(Assignee)

Comment 1

7 years ago
OK I give up, can't get a new build to work. The patch is trivial for someone with a build working, so I'm not going to patch this after all.
(Assignee)

Comment 2

7 years ago
Created attachment 447198 [details] [diff] [review]
fix Number usage

Oh never mind, here is the simple patch. But I have not been able run it due to my build problems.
Attachment #447198 - Flags: review?(dmose)
(Assignee)

Comment 3

7 years ago
and I'm setting 3.1 blocking to keep this on the radar.
blocking-thunderbird3.1: --- → ?
Component: Search → Database
Product: Thunderbird → MailNews Core
QA Contact: search → database
Status: NEW → ASSIGNED
Assignee: nobody → kent
The end user effect of this bug, as far as I can tell, is that, for users who turn off indexing for a given folder in the propreties dialog, the next time Gloda gets rebuilt (either because it was removed or because the Gloda schema gets bumped at some point in the future), the folder in question will suddenly start getting indexed at a lower-than-default priority, in conflict with the intent expressed by the user.

Blocking+, as we want this for RC1 build 3 so that we don't end up with any more profiles in the wild with this problem than necessary.
blocking-thunderbird3.1: ? → rc1+
Comment on attachment 447198 [details] [diff] [review]
fix Number usage

r=dmose.

It seems clearly correct, the gloda xpcshell-tests all pass with it applied, and there's nothing obviously wrong when playing with the preferences dialog that drives all this.

This shouldn't be very hard to write a test for, either a unit test that just checks property on the message db or a more complete functional test that simulates the failure mode described in my previous comment.  

Since we need to get this landed ASAP in order to kick off RC1 build3, I don't think we want to block on test here, so just setting the in-testsuite? test flag.

Kent, thanks so much for the patch.
Attachment #447198 - Flags: review?(dmose)
Attachment #447198 - Flags: review+
Attachment #447198 - Flags: approval-thunderbird3.1+
I've pushed it to the 3.1 branch as well, but not the trunk, as the trees are in an odd state.
status-thunderbird3.1: --- → rc1-fixed
Flags: in-testsuite?
(In reply to comment #4)
> Blocking+, as we want this for RC1 build 3 so that we don't end up with any
> more profiles in the wild with this problem than necessary.

Will you add cleanup code at some point in the future? Or when will it occur, and how to fix the profile?

(Sorry, I have had very bad experiences with bugs in the profile from years ago that suddenly surfaced ...)
Historically, for bugs like this that have occurred only in non-production (i.e. alpha & beta) versions of the software, Mozilla generally hasn't done that because of lack of resources.  That said, it would be a nice thing to do.   If you're interested in a taking a run at it, I suspect it wouldn't be too difficult
to detect.
Whiteboard: [fixed 3.1 RC 1 build 3]
(In reply to comment #4)
> The end user effect of this bug, as far as I can tell, is that, for users who
> turn off indexing for a given folder in the propreties dialog, 

So, the bug only does harm if I have set that?
I believe that's correct, yes.  Note that I haven't gone through and verified by hand that that's the actual failure more.
"failure mode"
Checked in on trunk: http://hg.mozilla.org/comm-central/rev/551db2c55b20
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 3.2a1
You need to log in before you can comment on or make changes to this bug.