Closed Bug 300263 Opened 15 years ago Closed 12 years ago

javascript: url "is not defined" error on SVG object

Categories

(Core :: SVG, defect)

x86
All
defect
Not set

Tracking

()

RESOLVED FIXED

People

(Reporter: w.langdon, Unassigned)

References

()

Details

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050702 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050702 Firefox/1.0+

Deerpark (Gecko/2005/07/02) javascript URL works differently for type=image/xbm
and for type=image/svg+xml
Example shows javascript working ok for older image types and image is correctly
displayed. Space is left for the SVG picture but nothing is displayed. Instead
the javascript console gives
  Error: eg_svg is not defined
  Source File: javascript:eg_svg Line: 1
I am wondering if svg type causes javascript to loose scope?

Reproducible: Always

Steps to Reproduce:
1.Enable Javascript console.
2.Load http://www.cs.ucl.ac.uk/staff/W.Langdon/svg_javascript_url_demo.html

Actual Results:  
See small black xbm picture but not larger three intersecting colours SVG image

Expected Results:  
XBM picture should be preceeded by larger SVG picture
(like http://www.cs.ucl.ac.uk/staff/W.Langdon/example.svg )
No errors expected on javascript console.

Sysadmin recently added (at my request) 
the .svg/.svgz extension as MIME type image/svg+xml
to www server http://www.cs.ucl.ac.uk/

PC running WindowsNT5.1 service pack 2
Component: General → SVG
Product: Firefox → Core
Version: unspecified → 1.0 Branch
with bug 1156's patch, this almost works... (content tree is built correctly,
but not the frames?)
Depends on: 1156
OS: Windows XP → All
Version: 1.0 Branch → Trunk
Assignee: nobody → general
(with the latest patch there, the testcase here works)
Is this still an issue?
(In reply to comment #4)
> Is this still an issue?
Yes.
I have tried both my example and Christian's simplier example, with the latest
build of deerpark (reloaded today) 20050712. Neither works.
I am guessing this means the fix has not been incorporated into Deerpark.
(I could not find a version of deerpark later than 20050712).

Bill

Deerpark was a codename for early Firefox builds. We're now on to release candidates. Download RC2 from http://www.mozilla.org/projects/svg/
jwatt, that doesn't matter.  Bug 1156 is fixed on trunk, but NOT on the 1.8 branch.  So please test a trunk nightly build from ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/
(In reply to comment #7)
> jwatt, that doesn't matter.  Bug 1156 is fixed on trunk, but NOT on the 1.8
> branch.  So please test a trunk nightly build from
> ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/
> 
I have just down loaded 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051119 Firefox/1.6a1
using firefox-1.6a.en-US.win32.installer.exe
This does _not_ fix the problem. Mysteriously, it seems to have got worse,
in that neither the SVG image nor the XBM image are displayed. (Previously the XBM image was displayed). 
On the plus side, deer park alpha 2 does not produce a javascript error.
QA Contact: general → ian
On trunk, that testcase throws a security error, since the channel has no owner.  This is consistent with what <img> does, but not with <iframe>, since <iframe> has a subdocument by default, while <object> does not.

Do we care?  What behavior should we aim for?
As much as javascript urls scare me, i think this should work. Especially if it does for <iframe>s. What owner do we use for iframes? It seems like the owner should be the page containing the <object> tag.
> Especially if it does for <iframe>s.

OK, but it doesn't work for images... 

> What owner do we use for iframes?

The principal of the document inside the iframe.

> It seems like the owner should be the page containing the <object> tag.

If you're happy declaring that sites that care about XSS attacks just shouldn't use <object> or <embed> or <applet>, then sure.

Note that there is still the difference that the JS is run on different script contexts in the case of <object> and <iframe>.  Not sure whether we care.
Bug 353334 fixed this.  The test there tests this too.
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
> If you're happy declaring that sites that care about XSS attacks just shouldn't
use <object> or <embed> or <applet>, then sure.

You're creating an ideal scenario for your personal belief. I suggest Firefox team fix stuff according to the accepted standards. Fixing stuff to suit your personal *UNPUBLISHED* guidelines does not help securing Firefox. 

Your fix opens up a XSS security hole. This could be exploited in the wild on various social networking sites (I tested).
I think we should revert this feature. Other browsers that supported, so we don't need it for compatibility with other browsers. There are better ways to generate SVG, HTML or plain text programmatically. This feature is pretty much pure XSS risk.
(In reply to Henri Sivonen (:hsivonen) from comment #14)
s/that supported/don't support it/
You need to log in before you can comment on or make changes to this bug.