Closed Bug 141316 Opened 22 years ago Closed 22 years ago

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

Categories

(SeaMonkey :: Composer, defect)

x86
Windows XP
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
mozilla1.1alpha

People

(Reporter: TucsonTester1, Assigned: adamlock)

Details

Attachments

(1 file, 1 obsolete file)

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.
This sounds like a bug for Adam or me to fix...
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
I agree, this seems like Adam's
Assignee: cmanske → adamlock
Attached patch Patch (obsolete) — Splinter Review
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?
Attached patch PatchSplinter Review
New patch just processes embed/object tags. There is no "data" attribute on the
applet tag.
Attachment #81884 - Attachment is obsolete: true
Comment on attachment 81905 [details] [diff] [review]
Patch

r=brade
Attachment #81905 - Flags: review+
Comment on attachment 81905 [details] [diff] [review]
Patch

sr=kin@netscape.com
Attachment #81905 - Flags: superreview+
Target Milestone: --- → mozilla1.1alpha
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+
Fix checked in
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: