280600 - Link to local WMV file with path containing spaces won't open in Windows Media Player (space passed to helper app as %20)

Status: RESOLVED WORKSFORME

(Firefox :: File Handling, defect)

Description

[jeb]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20041001 Firefox/0.10.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20041001 Firefox/0.10.1

Links to local wmv files are passed url-encoded to Windows Media Player, so a
file  on the desktop for example will cause Windows Media Player to complain
about not finding "C:\Document%20and%20Settings\user\Desktop\file.wmv"  FWIW, I
checked it in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b)
Gecko/20050131 and it works fine there.

Reproducible: Always

Steps to Reproduce:
1.Create a directory c:\foo bar\
2.put a file with the extension .wmv in there.
3.create an html file with a line like:
<a href="file:///c:/bar%20foo/test.wmv">Link</a>
4. Open the file, click on the link
5. When Windows Media Player opens, you'll see a fairly useless error message,
don't click more information.  You get more information, but it has little to no
relevance.
6. After all that nonsense is dismissed, Windows Media Player will busy itself
with opening its online store, trying in vain to get you to purchase a copy of
your test WMV file from it's mothership.  While it's doing this, you can click
on the entry in the 'Now Playing List' corresponding to your file.  It will have
an exclamation point in front of it.  Note: This does not mean WMP is playing
the negation of your file.  It means there is a problem.  When you click on it,
you'll see the path Windows Media Player was looking for:
'c:\foo%20bar'
If you replace the %20 with a space and hit enter, everything'll work.
Actual Results:  
My windows media file failed to play.

Expected Results:  
I think it probably should have reversed the URL encoding process.  It's clearly
already doing something, because the forward slashes have been returned to
backwards ones, the leading slash has been removed, and the 'file://' is gone. 
This makes me think it's the browser's responsibility to translate URLs into
system filenames, not the media player's.  Perhaps I'm wrong, but this does work
in MSIE and Mozilla.

I'm using a fresh user account created for this purpose with fresh nightlies of
Moz and FF.  I would check to see if the bug is broader (e.g. if it affects any
more helper apps) but I don't have any other helper apps on my system.

Comment 1

[jeb]

Attachment: Folder containing test case that demonstrates bug

This test case complicates matters slightly because it uses relative paths, but
that's unavoidable.  Still, I think it should make it slightly less
time-consuming for someone to verify the bug.  Unzip the folder to a path with
no spaces (like 'c:\') and load test.html.  The link labeled 'test1' should
work as it contains no spaces, but the link labeled 'test2' should not, as it
does.  If you unzip this folder to a path with spaces, like your Desktop
('c:\Documents and Settings\you\Desktop'), neither test link will work.

Comment 2

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 3

[Jesse Ruderman]

Confirmed Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1)
Gecko/20051005 Firefox/1.6a1.

Windows Media Player tries to open "C:\moz\pathbugtestfolder\bar%20foo\test.wmv"
and fails.  So this isn't a security hole where we're failing to enclose the
filename in quotes and Windows Media Player is treating part of the filename as
an extra parameter, but it is a bug.

Note that % is a legal character in Windows filenames, so there could be a
folder named bar%20foo.

Comment 4

[Matthew Sherborne]

Same thing happens for me with wma files and wmv files. Wether I'm accessing the file from an <embed> tag or from browsing a directory with a space in the name and clicking on a .wmv or .wma file.

Except, when browsing the dir, clicking the .wmv, brings up a save as/open dialog, and open works. The .wma, however opens helper straight away and helper says can't play file; I assume that the wrong name is bieng passed.

matiu

Comment 5

[Matthew Sherborne]

Further to previous comment:

If I remove all spaces from the path, all <embed> and directory browsing both work perfectly.

Comment 6

[Daniel Vanesse]

Experiencede the same today.

Comment 7

[zetka]

(In reply to comment #6)
> Experienced the same today.
> The same persists in Sea Monkey 1.1.4 . It is very unpleasant and annoying. After two years of existence of this bug should somebody take care about that.

Comment 8

[Phoenix]

WORKSFORME
Created file test.html with one line pointing to file
<a href="file:///M:/foo%20bar/Civ5_Opening_Movie_es_ES.wmv">Link</a>
in status bar link shows with space instead of %20 and opens in WMP just fine
Build identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a1) Gecko/20111017 Firefox/10.0a1 SeaMonkey/2.7a1
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20100101 Firefox/7.0.1