46405 - Relative URLs in 'pluginspage' attribute don't use BASE tag href

Status: VERIFIED FIXED

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

Description

[shrirang khanzode]

Build: 2000072408

I see this on the windows build. When a page lacks the quicktime plugin, 
clicking on the 'Get the Plug-in' button takes the user to a page with an error 
message. This does not happen with 4.x browser.

I will attach a testcase which specifies the mime type in the EMBED tag so that 
this can be seen.

Comment 1

[shrirang khanzode]

Attachment: testcase fro quicktime

Comment 2

[av (gone)]

The problem is that the URL specified in the embed tag is relative. The fix 
would be to convert it to absolute before passing to the default plugin. 

Changing summary.

Comment 3

[Jesse Ruderman]

Where does it go?  For me, NS4.75 and Mozilla 2000091508/Win98 both go to 
http://bugzilla.mozilla.org/quicktime/download/?video/quicktime, which seems to 
make sense, except for the ?stuff at the end.  Where is it supposed to go?  

By the way, the similar bug 42694 was recently WFM'ed.  Perhaps this should be 
marked as a dup.

(Why does it seem like Mozilla/Netscape is blatantly ignoring security by 
telling me about SmartUpdate stuff and then trying to send me back to the 
site?  Evil webmasters should at least have to spoof the SmartUpdate page to 
get users to install malicious plug-in code.)

Adding a few 's's to the summary.

Comment 4

[ekrock's old account (dead)]

Not a Netscape 6 RTM blocker. FUTURE. This bug has been marked Future because
the Netscape engineer it is assigned to is overburdened.

Comment 5

[Peter Lubczynski]

I'm stealing this one....

Comment 6

[Peter Lubczynski]

With the testcase attached, this is working.

1) Remove your Quicktime plugins from your plugins directory
2) Restart the browser or do a javascript:navigator.plugins.refresh(true)
3) Visit the testcase (#11897)
4) Notice in the source that the PLUGINSPAGE attribute is relative
5) Click on the default plugin to go to this page.
6) Notice it tried to go to
http://bugzilla.mozilla.org/quicktime/download/?video/quicktime

Which is the URL for the testcase on bugzilla plus the relative URL.

This seems to be working fine with this testcase, I need another one whipped up 
with a BASE tag. Perhpas that doesn't work because I saw another similar bug on 
that.

Comment 7

[Peter Lubczynski]

Attachment: same testcase but with BASE tag

Comment 8

[Peter Lubczynski]

Nope, the BASE tag is what's the problem with this bug. Relative url's work fine 
without the BASE tag as seen in attachment #11897 [details]. The new attachment (#24231) 
doesn't work as it should. However, I've seen another bug (possibly with Java) 
haven't to do with the same thing. I'll see if I can find it, but this is a 
relativly minor bug. 

Updaing summary and severity.

Comment 9

[Peter Lubczynski]

Attachment: patch to use document BASE in GetURL

Comment 10

[Peter Lubczynski]

Andrei, approval?

I also tested other variants of the testcases, like removing the leading / on 
the PLUGINURL attribute

Comment 11

[av (gone)]

OK. a=av

Comment 12

[buster]

sr=buster

Comment 13

[Peter Lubczynski]

Patch checked in.

Comment 14

[Jesse Ruderman]

The comment on the line you changed no longer matches the code on the line.  
Reopening.

It would be nice if the comment there and the one in the "else" block said 
something like "the plugin is in a document, so ...", etc.  I can't figure out 
what's going on in the else block.  Has the plugin been loaded by itself (the 
plugin's url in the location bar), and you want to use that as the base url?

Comment 15

[Peter Lubczynski]

I'm sorry the comment isn't perfect but I think it's pretty clear what's going 
on. You'll notice the comment for GetBaseURL in nsIDocument does say "(or the 
document URL)". 

GetURL works like clicking on a link. If someone supplies a BASE tag in the 
document, all links should honor that and be resolved. The else block simply 
tries to get to the document interface pointer so it can resolve the URL if 
there is a BASE tag. If there is no document (i.e. in a full-page plugins), an 
attempt to get the interface pointer will fail and therefore we'll try to use 
the actually location if the plugin's source which is the only thing we have to 
work with.

Marking FIXED again unless someone would like to submit a patch explaing the 
purpose of the else block.

Comment 16

[shrirang khanzode]

verified working on windows, mac commercial trunk builds 0226. Marking VERIFIED.