Closed
Bug 46405
Opened 24 years ago
Closed 24 years ago
Relative URLs in 'pluginspage' attribute don't use BASE tag href
Categories
(Core Graveyard :: Plug-ins, defect, P5)
Core Graveyard
Plug-ins
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla0.8
People
(Reporter: shrir, Assigned: peterlubczynski-bugs)
References
Details
Attachments
(3 files)
19.05 KB,
text/html
|
Details | |
19.45 KB,
text/html
|
Details | |
642 bytes,
patch
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Comment 1•24 years ago
|
||
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.
Status: NEW → ASSIGNED
Summary: default plugin takes user to wrong page when quicktime plugin is absent → Relative URLs in 'pluginpage' attribute confuse default plugin
Target Milestone: --- → M18
Comment 3•24 years ago
|
||
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.
Summary: Relative URLs in 'pluginpage' attribute confuse default plugin → Relative URLs in 'pluginspage' attribute confuses default plugin
Comment 4•24 years ago
|
||
Not a Netscape 6 RTM blocker. FUTURE. This bug has been marked Future because the Netscape engineer it is assigned to is overburdened.
Target Milestone: M18 → Future
Assignee | ||
Comment 5•24 years ago
|
||
I'm stealing this one....
Assignee: av → peterlubczynski
Status: ASSIGNED → NEW
OS: Windows NT → All
Hardware: PC → All
Target Milestone: Future → mozilla0.8
Assignee | ||
Comment 6•24 years ago
|
||
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.
Assignee | ||
Comment 7•24 years ago
|
||
Assignee | ||
Comment 8•24 years ago
|
||
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.
Status: NEW → ASSIGNED
Priority: P3 → P5
Summary: Relative URLs in 'pluginspage' attribute confuses default plugin → Relative URLs in 'pluginspage' attribute don't use BASE tag href
Assignee | ||
Comment 9•24 years ago
|
||
Assignee | ||
Comment 10•24 years ago
|
||
Andrei, approval? I also tested other variants of the testcases, like removing the leading / on the PLUGINURL attribute
Comment 11•24 years ago
|
||
OK. a=av
Comment 12•24 years ago
|
||
sr=buster
Assignee | ||
Comment 13•24 years ago
|
||
Patch checked in.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Comment 14•24 years ago
|
||
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?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Updated•24 years ago
|
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 15•24 years ago
|
||
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.
Reporter | ||
Comment 16•24 years ago
|
||
verified working on windows, mac commercial trunk builds 0226. Marking VERIFIED.
Status: RESOLVED → VERIFIED
Updated•2 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•