Last Comment Bug 691144 - Open Containing Folder should preselect the file
: Open Containing Folder should preselect the file
Status: RESOLVED FIXED
: regression
Product: SeaMonkey
Classification: Client Software
Component: Download & File Handling (show other bugs)
: Trunk
: All All
: -- normal (vote)
: seamonkey2.7
Assigned To: Ian Neal
:
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-10-02 05:59 PDT by Stanimir Stamenkov
Modified: 2011-10-10 14:58 PDT (History)
3 users (show)
iann_bugzilla: in‑testsuite-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
unaffected
wontfix
fixed
fixed
fixed


Attachments
Return nsILocalFile [Checked in trunk: Comment 13 comm-aurora/beta Comment 14] (720 bytes, patch)
2011-10-03 12:49 PDT, Ian Neal
neil: review+
stanio: feedback+
bugspam.Callek: approval‑comm‑aurora+
bugspam.Callek: approval‑comm‑beta+
Details | Diff | Splinter Review

Description Stanimir Stamenkov 2011-10-02 05:59:14 PDT
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 2011-10-02 11:14:56 PDT
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 2011-10-02 12:01:01 PDT
(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 2011-10-02 13:04:00 PDT
> 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 2011-10-02 13:08:15 PDT
Could the changes to Bug 665569 be related?
Comment 5 Ian Neal 2011-10-03 11:11:36 PDT
(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 2011-10-03 11:18:01 PDT
> 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 2011-10-03 11:20:44 PDT
> 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 2011-10-03 11:48:56 PDT
(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 2011-10-03 12:12:09 PDT
(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 2011-10-03 12:49:53 PDT
Created attachment 564302 [details] [diff] [review]
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 2011-10-03 13:48:37 PDT
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 2011-10-06 17:11:25 PDT
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 2011-10-08 05:13:37 PDT
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

Note You need to log in before you can comment on or make changes to this bug.