238886 - Relative URI not correctly resolved for sound files (at least midi and mp3) in object element if the base href is used.

Status: RESOLVED WONTFIX

(Core Graveyard :: Plug-ins, defect, P4)

Description

[Xavier Robin]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040326 Firefox/0.8.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040326 Firefox/0.8.0+

In the page at http://membres.oversurf.com/talentdetolkien/bug/exemple.htm, the
base href is set to "http://membres.oversurf.com/talentdetolkien/".
Html file is correctly inserted.
Sound file with relative URI is not.
Sound file with absolute URI is correctly inserted.
I inserted another sound file to show that Mozilla searches the sound file in a
subfolder and ignores the base href.

Reproducible: Always
Steps to Reproduce:
1. Make a page with the base href tag in "http://www.mysite.com/"
2. Place this page in a subfolder of your site. Place your sound file in the
same folder.
3. Insert an object element in the page with the relative URI to your sound file
(ex : data="subfolder/sound.mid")

Actual Results:  
The sound isn't played.

Expected Results:  
The sound should have been played because of the base href.

Comment 1

[Bill Mason]

Attachment: Testcase

Comment 2

[Xavier Robin]

Attachment: Testcase

Comment 3

[Xavier Robin]

This bug only occurs with the Windows Media Player plugin.
No problem with the Quick Time plugin. If it is correctly configured to play
audio/x-mp3 media type, you will be able to play the sound.

I'v included 2 sounds in the testcase 150123 : 
- this with Quick Time is correctly played (you will need to configure your
Quick Time settings > Browser Plugin > MIME settings to handle "audio/x-mp3" files)
- but nothing happens with the Win Media Player.

Comment 4

[Adrian]

Attachment: Testcase

I think that this is an example of a more basic problem. See attached testcase
using 3 pure html files.  Issue in Mozilla 1.7.3 and FireFox 1.0PR

Similar bugs have been referenced to bug #99689

Comment 5

[Anne (:annevk)]

Could someone attach a usable test case, the first two test cases are based on
files that don't exist and the last test case is a zip file.

Comment 6

[Xavier Robin]

Attachment: testcase

Comment 7

[Xavier Robin]

HTTP Headers seems to indicate that the browser looks for the correct file.
However it doesn't embed it.

For example for attachment 169454 [details] it hit twice the file
http://cui.unige.ch/~robin0/bugzilla/shostakowich_24PREL_FUG_op87_F13.mid but it
is only used if absolute URI is used in the data attribute.

Comment 8

[Xavier Robin]

Attachment: testcase

Same problem with <embed> tags.

Comment 9

[denis]

Attachment: Stand-alone testcase with <embed> and PDF document

Confirm the bug on multiple Firefox 23 installations.

Fully stand-alone test case attached.

Comment 10

[Georg Fritzsche [:gfritzsche]]

Both Flash and Quicktime work fine and only send a single request.
Given that you point out in your test-case:
> Notice how Firefox makes two requests. The first one goes to the correct URL, but aborts, and then the second goes to a wrong URL. 
... this just looks like the initial stream/channel opened for the URL from the src attribute is fine, but some plugins rather (Acrobat, WMP) open their own channel/stream and build the URL incorrectly.

We should verify that, but it looks like those are just plugin issues that should be filed with the vendor.

Comment 11

[denis]

(In reply to Georg Fritzsche [:gfritzsche] from comment #10)
> Both Flash and Quicktime work fine and only send a single request.
> Given that you point out in your test-case:
> > Notice how Firefox makes two requests. The first one goes to the correct URL, but aborts, and then the second goes to a wrong URL. 
> ... this just looks like the initial stream/channel opened for the URL from
> the src attribute is fine, but some plugins rather (Acrobat, WMP) open their
> own channel/stream and build the URL incorrectly.
> 
> We should verify that, but it looks like those are just plugin issues that
> should be filed with the vendor.

Sorry I did not specify from the beginning: this only happens with Firefox internal PDF viewer in Firefox 22.
This bug does NOT happen with Adobe Flash-based PDF reader.

Comment 12

[denis]

Of course I meant Firefox 23 in my previous comment.

Comment 13

[Georg Fritzsche [:gfritzsche]]

(In reply to denis from comment #11)
> Sorry I did not specify from the beginning: this only happens with Firefox
> internal PDF viewer in Firefox 22.
> This bug does NOT happen with Adobe Flash-based PDF reader.

Ok, i filed bug 914667 on the PDF Viewer issue. Then so far this specific bug seems to be only an issue with WMP.

Comment 14

[denis]

Thank you!

Comment 15

[BMO Automation]

Resolving as wont fix, plugin support deprecated in Firefox 85.