Closed Bug 691144 Opened 8 years ago Closed 8 years ago

Open Containing Folder should preselect the file

Categories

(SeaMonkey :: Download & File Handling, defect)

defect
Not set

Tracking

(seamonkey2.3 unaffected, seamonkey2.4 wontfix, seamonkey2.5 fixed, seamonkey2.6 fixed, seamonkey2.7 fixed)

RESOLVED FIXED
seamonkey2.7
Tracking Status
seamonkey2.3 --- unaffected
seamonkey2.4 --- wontfix
seamonkey2.5 --- fixed
seamonkey2.6 --- fixed
seamonkey2.7 --- fixed

People

(Reporter: stanio, Assigned: iann_bugzilla)

Details

(Keywords: regression)

Attachments

(1 file)

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a1) Gecko/20111002 Firefox/10.0a1 SeaMonkey/2.7a1
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110928 Firefox/7.0.1 SeaMonkey/2.4.1

STR:

1. Download a file;
2. Open the Download Manager and select the file entry, if necessary;
3. "Open Containing Folder" either from the context menu or from the File menu.

Actual:

* The containing folder is opened, if not already, but the file is not preselected.

Expected:

* The containing folder is opened, if not already, and the file is preselected.

This used to work in SeaMonkey 2.3 with the difference activating "Open Containing Folder" always opened a new folder window, even if already opened one exists.

I'll try to find a regression range.
Summary: Open Containing Folder show preselect the file → Open Containing Folder should preselect the file
Confirmed, regression.

Works: 2.3.3, http://hg.mozilla.org/releases/mozilla-release/rev/7a4871571868
Broken: 2.4b1, http://hg.mozilla.org/releases/mozilla-beta/rev/ff20a21364bb

(I don't know if that is the regression "range", necessarily.)

Works in FF 7, so not a core issue.
(In reply to Stanimir Stamenkov from comment #0)
> This used to work in SeaMonkey 2.3 with the difference activating "Open
> Containing Folder" always opened a new folder window, even if already opened
> one exists.

I suspect this change comes from core, as Firefox 6 also opens a new folder window every time "Open Containing Folder" is invoked, while Firefox 7 doesn't.  So it is very likely the corresponding core change has broken the preselection in SeaMonkey.
> I suspect this change comes from core, as Firefox 6 also opens a new folder
> window every time "Open Containing Folder" is invoked, while Firefox 7
> doesn't.

Seems I've lied.  I observe the given behavior with Firefox starting just with Firefox 9 Aurora.

The last good build for SeaMonkey seems:

http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/2011/07/2011-07-03-00-31-04-comm-central-trunk/seamonkey-2.4a1.en-US.win32.zip

The first bad:

http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/2011/07/2011-07-05-00-32-57-comm-central-trunk/seamonkey-2.4a1.en-US.win32.zip

Unfortunately, there's no win32 build for 2011-07-04:

http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/2011/07/2011-07-04-00-30-31-comm-central-trunk/

Here are the push logs from comm-central and mozilla-central for the given range:

http://hg.mozilla.org/comm-central/pushloghtml?startdate=2011-07-03&enddate=2011-07-06

http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2011-07-03&enddate=2011-07-06
Could the changes to Bug 665569 be related?
(In reply to Stanimir Stamenkov from comment #4)
> Could the changes to Bug 665569 be related?

Any relevant messages in the error console?
> Could the changes to Bug 665569 be related?

What happens if you revert the changes in:
http://hg.mozilla.org/comm-central/rev/bc728348268b
> Could the changes to Bug 665569 be related?

What happens if you revert the changes in:
http://hg.mozilla.org/comm-central/rev/bc728348268b
(In reply to Ian Neal from comment #5)
> Any relevant messages in the error console?

None.

(In reply to Philip Chee from comment #6)
> What happens if you revert the changes in:
> http://hg.mozilla.org/comm-central/rev/bc728348268b

I'll try.
(In reply to Philip Chee from comment #7)
> What happens if you revert the changes in:
> http://hg.mozilla.org/comm-central/rev/bc728348268b

I haven't done a full build, but I've backed out changeset bc728348268b from my comm-central tree, then copied the modified files to the omni.jar of a latest nightly build manually - the behavior this way is as expected.
Assignee: nobody → iann_bugzilla
Status: NEW → ASSIGNED
OS: Windows 7 → All
Hardware: x86_64 → All
The file.reveal() in showDownload function needs the targetFile to be an nsILocalFile so lets make sure it is.
Attachment #564302 - Flags: feedback?(stanio)
Comment on attachment 564302 [details] [diff] [review]
Return nsILocalFile [Checked in trunk: Comment 13 comm-aurora/beta Comment 14]

Works just right for me.  Thanks.
Attachment #564302 - Flags: feedback?(stanio) → feedback+
Attachment #564302 - Flags: review?(neil)
Attachment #564302 - Flags: review?(neil) → review+
Comment on attachment 564302 [details] [diff] [review]
Return nsILocalFile [Checked in trunk: Comment 13 comm-aurora/beta Comment 14]

Requesting approval on comm-aurora and comm-beta for this simple regression fix
Attachment #564302 - Flags: approval-comm-beta?
Attachment #564302 - Flags: approval-comm-aurora?
Keywords: regression
Comment on attachment 564302 [details] [diff] [review]
Return nsILocalFile [Checked in trunk: Comment 13 comm-aurora/beta Comment 14]

http://hg.mozilla.org/comm-central/rev/942e6b119d20
Attachment #564302 - Attachment description: Return nsILocalFile → Return nsILocalFile [Checked in trunk: Comment 13]
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Flags: in-testsuite-
Resolution: --- → FIXED
Target Milestone: --- → seamonkey2.7
Attachment #564302 - Flags: approval-comm-beta?
Attachment #564302 - Flags: approval-comm-beta+
Attachment #564302 - Flags: approval-comm-aurora?
Attachment #564302 - Flags: approval-comm-aurora+
Comment on attachment 564302 [details] [diff] [review]
Return nsILocalFile [Checked in trunk: Comment 13 comm-aurora/beta Comment 14]

http://hg.mozilla.org/releases/comm-aurora/rev/8d75a54332db
http://hg.mozilla.org/releases/comm-beta/rev/b99666db9517
Attachment #564302 - Attachment description: Return nsILocalFile [Checked in trunk: Comment 13] → Return nsILocalFile [Checked in trunk: Comment 13 comm-aurora/beta Comment 14]
You need to log in before you can comment on or make changes to this bug.