Other files such as *.wav or *.mid do not upload when added to page using embed tag.

RESOLVED FIXED in mozilla1.1alpha

Status

RESOLVED FIXED
17 years ago
14 years ago

People

(Reporter: TucsonTester1, Assigned: adamlock)

Tracking

Trunk
mozilla1.1alpha
x86
Windows XP

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

2.27 KB, patch
Brade
: review+
kinmoz
: superreview+
Details | Diff | Splinter Review
(Reporter)

Description

17 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0+)
Gecko/20020430 Netscape6/6.2.1+
BuildID:    2002043008

If the embed tag is used in Composer to add a wav or midi file to a page and the
page is then published to an ftp site, the file does not upload.

Reproducible: Always
Steps to Reproduce:
1.Launch a new/blank Composer window.
2.Click Insert|HTML...
3.Use <embed> tag to add a wav file to page.
      ex. <embed src="file:///C:/.......filename.wav" height="25"              
                                 
      width="100" autostart="false">
4.Click File|Publish as...
5.Ensure "Include Images and Other Files" is checked (use same location as page)
6.Publish to ftp site.

Actual Results:  The local wav file is not uploaded to the ftp site(verifed
using CuteFTP to view site directory).  The src attribute continues to "point"
to the local file.

Expected Results:  I would expect this to behave similar to an image file where
the file uploads to the ftp site and the src is changed to be relative to the
page location.

The embed tag for a wav file does not "display" an audio player in Composer or
Navigator(after publishing).  If the area on the page where the embed tag was
placed is clicked a plug-in finder page will open.  If a midi file is embedded,
a quicktime player is displayed in both composer and Navigator.  Both are
displayed if page is opened in IE after publishing.

Comment 1

17 years ago
This sounds like a bug for Adam or me to fix...
(Assignee)

Comment 2

17 years ago
The persist object does not fixup embed or object elements at present. It should
be straightforward enough to add the basic functionality for them in
nsWebBrowserPersist::OnWalkDOMNode &
nsWebBrowserPersist::CloneNodeWithFixedUpURIAttributes.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 3

17 years ago
I agree, this seems like Adam's
Assignee: cmanske → adamlock
(Assignee)

Comment 4

17 years ago
Created attachment 81884 [details] [diff] [review]
Patch

Here is the patch for embed/applet/object tags. It fixes up the src/data
attribute as appropriate. It doesn't touch any other attribute, e.g. codebase,
or any nested param tags which could also contain URIs but which I have no way
of knowing if they represent data or not.

Reviews?
(Assignee)

Comment 5

17 years ago
Created attachment 81905 [details] [diff] [review]
Patch

New patch just processes embed/object tags. There is no "data" attribute on the
applet tag.
Attachment #81884 - Attachment is obsolete: true

Comment 6

17 years ago
Comment on attachment 81905 [details] [diff] [review]
Patch

r=brade
Attachment #81905 - Flags: review+

Comment 7

16 years ago
Comment on attachment 81905 [details] [diff] [review]
Patch

sr=kin@netscape.com
Attachment #81905 - Flags: superreview+
(Assignee)

Updated

16 years ago
Target Milestone: --- → mozilla1.1alpha

Comment 8

16 years ago
Comment on attachment 81905 [details] [diff] [review]
Patch

a=asa (on behalf of drivers) for checkin to the 1.1 trunk.
Attachment #81905 - Flags: approval+
(Assignee)

Comment 9

16 years ago
Fix checked in
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.