The default bug view has changed. See this FAQ.

Browsing through files without extension using FireFTP crashes the browser

VERIFIED FIXED

Status

()

Core
XPCOM
VERIFIED FIXED
10 years ago
9 years ago

People

(Reporter: Peter Weilbacher, Assigned: Peter Weilbacher)

Tracking

(4 keywords)

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

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

Comment 1

10 years ago
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.
Assignee: nobody → mozilla
Status: NEW → ASSIGNED
(Assignee)

Comment 2

10 years ago
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).
Attachment #286010 - Flags: review?(mozilla)

Comment 3

10 years ago
Comment on attachment 286010 [details] [diff] [review]
likely fix

yeah, that does seem much more logical
Attachment #286010 - Flags: review?(mozilla) → review+
(Assignee)

Comment 4

10 years ago
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Keywords: crash, fixed1.8.1.10, fixed1.8.1.9, regression
Resolution: --- → FIXED
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.
(Assignee)

Comment 6

10 years ago
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 1.8.1.9 release from the same release branch as 1.8.1.8, 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?
(Assignee)

Comment 7

9 years ago
Haven't heard any complaints since this went in.
Status: RESOLVED → VERIFIED
Keywords: fixed1.8.1.10, fixed1.8.1.9 → verified1.8.1.10, verified1.8.1.9
You need to log in before you can comment on or make changes to this bug.