Closed
Bug 567824
Opened 14 years ago
Closed 14 years ago
gloda's folder property indexingPriority set as function text, not number
Categories
(MailNews Core :: Database, defect)
Tracking
(blocking-thunderbird3.1 rc1+, thunderbird3.1 rc1-fixed)
RESOLVED
FIXED
Thunderbird 3.3a1
People
(Reporter: rkent, Assigned: rkent)
Details
(Whiteboard: [fixed 3.1 RC 1 build 3])
Attachments
(1 file)
889 bytes,
patch
|
dmosedale
:
review+
dmosedale
:
approval-thunderbird3.1+
|
Details | Diff | Splinter Review |
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•14 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•14 years ago
|
||
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•14 years ago
|
||
and I'm setting 3.1 blocking to keep this on the radar.
blocking-thunderbird3.1: --- → ?
Updated•14 years ago
|
Component: Search → Database
Product: Thunderbird → MailNews Core
QA Contact: search → database
Updated•14 years ago
|
Status: NEW → ASSIGNED
Updated•14 years ago
|
Assignee: nobody → kent
Comment 4•14 years ago
|
||
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 5•14 years ago
|
||
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+
Comment 6•14 years ago
|
||
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?
Comment 7•14 years ago
|
||
(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 ...)
Comment 8•14 years ago
|
||
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.
Updated•14 years ago
|
Whiteboard: [fixed 3.1 RC 1 build 3]
Comment 9•14 years ago
|
||
(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?
Comment 10•14 years ago
|
||
I believe that's correct, yes. Note that I haven't gone through and verified by hand that that's the actual failure more.
Comment 11•14 years ago
|
||
"failure mode"
Comment 12•14 years ago
|
||
Checked in on trunk: http://hg.mozilla.org/comm-central/rev/551db2c55b20
Status: ASSIGNED → RESOLVED
Closed: 14 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.
Description
•