290848 - ActiveX pluginhostctrl dll does not properly resolve relative URLs (w/ patch)

Status: RESOLVED INVALID

(Core Graveyard :: Embedding: ActiveX Wrapper, defect)

Description

[Jeff Hobbs]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2

When writing a local (relative) file name into the src= field, the 
URLOpenStream call in nsURLDataCallback::StreamThread function returns a 
800C000D error.  The problem is in mozilla/embedding/browser/activex/src/pluginhostc
trl/nsURLDataCallback.cpp:nsURLDataCallBack::OpenURL().  This affects any NSAPI
plugin using the ActiveX pluginhostctrl to operate in IE.

I see several other reports of relative src= problems across a variety of areas,
but none specifically for the ActiveX pluginhostctrl, so I'm attaching this
patch as a new report.  This isn't against HEAD, but is restricted to one function.

Reproducible: Always

Steps to Reproduce:
Any page using a relative URL in src= for the EMBED or OBJECT param.  Like this
snippet (I changed classid in my pluginhostctrl variant to avoid the broken
original):

  <OBJECT
        ID="PluginHostCtrl"
        CLASSID="CLSID:14E78123-A693-4F27-B6EE-DDDE18F93D3A"
        WIDTH="800"
        HEIGHT="550"
>
          <PARAM name="type" value="application/x-tcl"/>
          <PARAM name="pluginspage" value="http://www.tcl.tk/software/plugin/"/>
          <PARAM name="src"  value="floor.tcl"
/>

        <EMBED
          TYPE="application/x-tcl"
          PLUGINSPAGE="http://www.tcl.tk/software/plugin/"
          FRAMEBORDER="NO"
          WIDTH="800"
          HEIGHT="550"
          SRC="floor.tcl"
        >
        </EMBED>
  </OBJECT>

If you use an absolute URL for src= value, the is no problem

Comment 1

[Jeff Hobbs]

Attachment: patch to resolve relative URL src= in ActiveX pluginhostctrl

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

[Jeff Hobbs]

This patch is still valid and still has not been applied to the mozilla code
base (at least in the 1.8 branch).

Comment 4

[Marius Strumyla]

Jeff, you need to request a review. See a list of available reviewers:
http://www.mozilla.org/hacking/reviewers.html

Comment 5

[Jeff Hobbs]

I have actually forwarded this report before to the module owner (Adam Lock),
and have resent the review request now.

Comment 6

[Ed Morley [:emorley]]

The ActiveX embedding API was removed in bug 662023 and friends, making this INVALID.

[Filter bugspam on activexinvalid]