691144 - Open Containing Folder should preselect the file

Status: RESOLVED FIXED

(SeaMonkey :: Download & File Handling, defect)

Description

[Stanimir Stamenkov]

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.

Comment 1

[therube]

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.

Comment 2

[Stanimir Stamenkov]

(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.

Comment 3

[Stanimir Stamenkov]

> 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

Comment 4

[Stanimir Stamenkov]

Could the changes to Bug 665569 be related?

Comment 5

[Ian Neal]

(In reply to Stanimir Stamenkov from comment #4)
> Could the changes to Bug 665569 be related?

Any relevant messages in the error console?

Comment 6

[Philip Chee]

> Could the changes to Bug 665569 be related?

What happens if you revert the changes in:
http://hg.mozilla.org/comm-central/rev/bc728348268b

Comment 7

[Philip Chee]

> Could the changes to Bug 665569 be related?

What happens if you revert the changes in:
http://hg.mozilla.org/comm-central/rev/bc728348268b

Comment 8

[Stanimir Stamenkov]

(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.

Comment 9

[Stanimir Stamenkov]

(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.

Comment 10

[Ian Neal]

Attachment: Return nsILocalFile [Checked in trunk: Comment 13 comm-aurora/beta Comment 14]

The file.reveal() in showDownload function needs the targetFile to be an nsILocalFile so lets make sure it is.

Comment 11

[Stanimir Stamenkov]

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.

Comment 12

[Ian Neal]

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

Comment 13

[Ian Neal]

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

Comment 14

[Ian Neal]

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