This was just discussed in the OS/2 newsgroup. Seems like the fix from bug 395576 doesn't properly take into account files without extension.
Created attachment 286010 [details] [diff] [review] likely fix We have visited this code three times in the last year, why have we never thought of using stricmp() for the comparison? Even though it's not standardized, it is already used many times in the Mozilla code... Well, this basically reverts the change from bug 395576 (and hence returns early if there is no extension) and instead uses stricmp which does not touch the input strings. Will ask for review once it's tested.
Comment on attachment 286010 [details] [diff] [review] likely fix Mike, I hope you agree that this solution makes a lot more sense than the first try (that didn't check the return codes of either _mbsrchr or strncpy).
Comment on attachment 286010 [details] [diff] [review] likely fix yeah, that does seem much more logical
Fix checked into trunk and 1.8 branch, and because this was such a stupid and easy to fix regression and it only touches on OS/2 only file I also checked it into the GECKO181_20071004_RELBRANCH.
Please seek approval before checking into a _RELBRANCH even for "not part of build" changes. Seeing unexpected check-ins on "their" branch freaks out the build/release folks.
If it would be clear how the approval process is handled and if it had been announced in .planning that there would be a fast 22.214.171.124 release from the same release branch as 126.96.36.199, I might have done so. So I only saw the unclear message at the top of the 1.8 branch tinderbox, and to me it seemed that if I wanted to have this fix in the FIREFOX_2_0_0_9_RELEASE tag that I had to act now and not wait hours/days/weeks for approval. Would you have seen and reacted to an approval request 5 (?) minutes before tagging?
Haven't heard any complaints since this went in.