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

Options > Choose Download Folder > Close using top left hand menu crashes firefox.

VERIFIED FIXED

Status

()

Firefox
Shell Integration
--
major
VERIFIED FIXED
11 years ago
11 years ago

People

(Reporter: Miles Kuperus, Assigned: Peter Weilbacher)

Tracking

({crash, verified1.8.1.2})

Trunk
x86
OS/2
crash, verified1.8.1.2
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

11 years ago
User-Agent:       Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.8.1) Gecko/20061009 Firefox/2.0
Build Identifier: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.8.1) Gecko/20061009 Firefox/2.0

Crash when closing choose download folder dialog using top right menu.

Reproducible: Always
(Assignee)

Comment 1

11 years ago
Yep, I see this, too. I tried to find out where it happens and the POPUPLOG.OS2 address of one of my Firefox 2 builds points to nsFilePicker::Show(). Have to wait for a debug build to analyze the problem with a debugger.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: crash
(Assignee)

Comment 2

11 years ago
Created attachment 248190 [details] [diff] [review]
add NULL check

Somehow the ^ marker in the string is gone when the dialog is dismissed using the system menu. This extra NULL check avoids the crash and doesn't do any harm because the string is only used in the case of DID_OK.

This is such an obvious fix that I think I should check into trunk and branch at the same time...
Assignee: nobody → mozilla
Status: NEW → ASSIGNED
Attachment #248190 - Flags: review?(mozilla)

Comment 3

11 years ago
Comment on attachment 248190 [details] [diff] [review]
add NULL check

r=mkaply
Attachment #248190 - Flags: review?(mozilla) → review+
(Assignee)

Comment 4

11 years ago
Fix checked into trunk and 1.8 branch.
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Keywords: fixed1.8.1.1
Hardware: Other → PC
Resolution: --- → FIXED
Version: unspecified → Trunk
(Assignee)

Comment 5

11 years ago
This was obviously checked in too late for 1.8.1.1 (and I confirmed that Firefox 2.0.0.1 still crashes).
Keywords: fixed1.8.1.1 → fixed1.8.1.2
(Assignee)

Comment 6

11 years ago
Verified fixed on trunk using "Gecko/20061222 Minefield/3.0a2pre" nightly.
Status: RESOLVED → VERIFIED

Comment 7

11 years ago
Hi peter, can you verify this fix for us on OS/2 in the 1.8.1.2 branch as well?   We dont have OS/2 here installed, and hopefully it'll be a quick verification for you.   When you are done, please change the keyword "fixed1.8.1.2" to "verified1.8.1.2" for tracking purposes.  Thanks!
(Assignee)

Comment 8

11 years ago
Verifying some older bugs.

(As we don't have branch nightlies nor RCs of Firefox on OS/2, I can only verify now.)
Keywords: fixed1.8.1.2 → verified1.8.1.2
You need to log in before you can comment on or make changes to this bug.