392050 - Saving Flash file from Media tab of "View Page Info" window does not work

Status: RESOLVED FIXED

(SeaMonkey :: Page Info, defect)

Description

[Georg Maaß]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061113 SeaMonkey/1.5a
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4

Saving Flash file from Media tab of "View Page Info" window does not work. No default filename is provide no file type is provided in the SAVE AS dialog. When entering a filename manually and trying to save fails.

In the trunk [Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061113 SeaMonkey/1.5a] all that works fine, but in the release it does not.

Firefox 2.0 has the same problem, so it is probably in a shared component.

Reproducible: Always

Steps to Reproduce:
1. Right-Click on page to get the context menu
2. Select menu item "View Page Info"
3. Select the Media tab
4. Select the Flash file (for unknown reasons it is displayed with the filename only omitting the protocol and host)
5. Click on the SAVE AS.. button
Actual Results:  
The SAVE AS dialog does not fill the filename to the textbox. The menu of filetypes has only the "all files" entry. Saving with a manually entered filename fails.

Expected Results:  
The SAVE AS dialog should fill the original filename to the textbox.
The menu of filetypes should have the "Shokwave Flash Object" entry and this entry should be sellected by default. Saving should work.

If I enter the complete URL of the flash file I can use SAVE PAGE AS to save the flash file correctly, but this workaround is ugly.

Comment 1

[zug_treno]

Duplicate of (Firefox bug 313072 -> Firefox bug 287720 ->) bug 213701?

Comment 2

[Serge Gautherie (:sgautherie)]

Can you reproduce with SeaMonkey v1.1.9 ?
(or Firefox v2.0.0.14 ?)

Comment 3

[Serge Gautherie (:sgautherie)]

Confirming:
Lists filename only;
No filename to save;
Trying to save with a fake filename:

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.15pre) Gecko/2008060503 BonEcho/2.0.0.15pre] (nightly) (W2Ksp4)
{{
Error: uncaught exception: [Exception... "Component returned failure code: 0x80004003 (NS_ERROR_INVALID_POINTER) [nsITransfer.init]"  nsresult: "0x80004003 (NS_ERROR_INVALID_POINTER)"  location: "JS frame :: chrome://global/content/contentAreaUtils.js :: internalSave :: line 352"  data: no]
}}

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9] (release) (W2Ksp4)
{{
Error: uncaught exception: [Exception... "Component returned failure code: 0x80004003 (NS_ERROR_INVALID_POINTER) [nsITransfer.init]"  nsresult: "0x80004003 (NS_ERROR_INVALID_POINTER)"  location: "JS frame :: chrome://communicator/content/contentAreaUtils.js :: internalSave :: line 391"  data: no]
}}

***

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a5pre) Gecko/20070515 SeaMonkey/1.5a] (nightly) (W2Ksp4)
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9pre) Gecko/2008060507 Minefield/3.0pre] (nightly) (W2Ksp4)

Confirming:
No issue, can save the file.

***

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9pre) Gecko/2008060802 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4)

Lists full URL;
Filename to save;
but Save As > ... > Save:
{{
Error: uncaught exception: [Exception... "Could not convert JavaScript argument arg 2 [nsIWebBrowserPersist.saveURI]"  nsresult: "0x80570009 (NS_ERROR_XPC_BAD_CONVERT_JS)"  location: "JS frame :: chrome://communicator/content/contentAreaUtils.js :: internalSave :: line 449"  data: no]
}}

***

Then:
*1.8.1 branch: full bug with FireFox and SeaMonkey.
*1.9 trunk: FF 3.0 works; but SM 2.0a1 partially regressed from 1.5a :-<

Let's fix SM 2.0a1 first;
then we'll see if we can port a fix to the branch or not.

***

|internalSave()| code is the "same" everywhere:
<http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/xpfe/communicator/resources/content/contentAreaUtils.js&rev=1.142&mark=456-458#445>
<http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/suite/common/contentAreaUtils.js&rev=1.153&mark=447-449#436>
<http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/toolkit/content/contentAreaUtils.js&rev=1.102&mark=368-370#357>

Comment 4

[Serge Gautherie (:sgautherie)]

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9pre) Gecko/2008060802 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4)

Debugged and tested with Venkman:
cause is that |aReferrer| value is |false| instead of |null|.

Comment 5

[Serge Gautherie (:sgautherie)]

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9pre) Gecko/2008060802 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4)

Call stack from Venkman:
{{
#0: function internalSave(aReferrer=boolean:false, aChosenData=null:null, aFilePickerTitleKey=string:"SaveImageTitle", aShouldBypassCache=boolean:false, aContentType=null:null, aContentDisposition=null:null, aDefaultFileName=null:null, aDocument=null:null, aURL=string:"http://www.thecuriosityofchance.com/curiousity-newcurtain.swf") in <chrome://communicator/content/contentAreaUtils.js> line 447
#1: function saveURL(aReferrer=boolean:false, aShouldBypassCache=boolean:false, aFilePickerTitleKey=string:"SaveImageTitle", aFileName=null:null, aURL=string:"http://www.thecuriosityofchance.com/curiousity-newcurtain.swf") in <chrome://communicator/content/contentAreaUtils.js> line 194
#2: function saveMedia() in <chrome://navigator/content/pageinfo/pageInfo.js> line 778
#3: function oncommand(event=XULCommandEvent:{0}) in <chrome://navigator/content/pageinfo/pageInfo.xul> line 1
}}

SM 2.0a1 trunk case is a regression from bug 379183.

Comment 6

[Serge Gautherie (:sgautherie)]

Attachment: (Av1-suite) <pageInfo.js> [Checkin: Comment 8]

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9pre) Gecko/2008060802 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4)

Removes |aSkipPrompt| (parameter) value, which SeaMonkey does not have.

Comment 7

[[e-mail]]

Comment on attachment 324197 [details] [diff] [review]
(Av1-suite) <pageInfo.js>
[Checkin: Comment 8]

This confused me until I realised I had to delete the broken download before I could download it correctly.

Comment 8

[Frank Wein [:mcsmurf]]

Checking in suite/browser/pageinfo/pageInfo.js;
/cvsroot/mozilla/suite/browser/pageinfo/pageInfo.js,v  <--  pageInfo.js
new revision: 1.12; previous revision: 1.11
done

Comment 9

[Serge Gautherie (:sgautherie)]

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.0.1pre) Gecko/2008062115 SeaMonkey/2.0a1pre] (SEA-WIN32-TBOX-trunk) (W2Ksp4)

V.Fixed, SM 1.9(.0) trunk part.

Comment 10

[Serge Gautherie (:sgautherie)]

(In reply to comment #1)
> Duplicate of [...] bug 213701?

Confirming 1.8(.1) branch case:

1.9 trunk was fixed between
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060720 SeaMonkey/1.5a] (2006-07-20-10-trunk) (W2Ksp4)
and
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060721 SeaMonkey/1.5a] (2006-07-21-10-trunk) (W2Ksp4)

<http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=MozillaTinderboxAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-07-20-10&maxdate=2006-07-21-11&cvsroot=%2Fcvsroot>
points to bug 213701.

Then, the question is:
Can we port that fix(es) to the branch or is this (now) a WontFix ?

Comment 11

[Florian Quèze [:florian]]

At this point I think that if you really want to fix the visible bug for the 1.8 branch, it would be safer to just resolve the URL in JS in pageInfo.js

Comment 12

[Serge Gautherie (:sgautherie)]

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.22pre) Gecko/2009031004 BonEcho/2.0.0.22pre] (nightly) (W2Ksp4)

FFv2 still has this "Core" bug.

***

I think I/we don't care much about the 1.8.1 branch anymore.

R.Fixed, on the regressed SeaMonkey specific part.

Comment 13

[Andrew Hagen]

Thanks for closing it.  

If anybody has a bug number for the Core bug, much appreciated in advance. 

(I would like it fixed, but if we WONTFIX that, I would still be happy. I just want to know that we have thought about this and made a decision.)

Comment 14

[Serge Gautherie (:sgautherie)]

(In reply to comment #13)
> If anybody has a bug number for the Core bug, much appreciated in advance. 

See bug 213701 comment 44...

> (I would like it fixed, but if we WONTFIX that, I would still be happy. I just
> want to know that we have thought about this and made a decision.)