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

Status: RESOLVED FIXED

(Core :: SVG, defect)

Description

[bill]

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

Comment 1

[Christian :Biesinger (don't email me, ping me on IRC)]

Attachment: simpler testcase

Comment 2

[Christian :Biesinger (don't email me, ping me on IRC)]

with bug 1156's patch, this almost works... (content tree is built correctly,
but not the frames?)

Comment 3

[Christian :Biesinger (don't email me, ping me on IRC)]

(with the latest patch there, the testcase here works)

Comment 4

[Boris Zbarsky [:bzbarsky]]

Is this still an issue?

Comment 5

[bill]

(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

Comment 6

[Jonathan Watt [:jwatt]]

Deerpark was a codename for early Firefox builds. We're now on to release candidates. Download RC2 from http://www.mozilla.org/projects/svg/

Comment 7

[Boris Zbarsky [:bzbarsky]]

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/

Comment 8

[bill]

(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.

Comment 9

[Boris Zbarsky [:bzbarsky]]

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?

Comment 10

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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.

Comment 11

[Boris Zbarsky [:bzbarsky]]

> 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.

Comment 12

[Boris Zbarsky [:bzbarsky]]

Bug 353334 fixed this.  The test there tests this too.

Comment 13

[Sopheap Ly]

> 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).

Comment 14

[Henri Sivonen (:hsivonen)]

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.

Comment 15

[Henri Sivonen (:hsivonen)]

(In reply to Henri Sivonen (:hsivonen) from comment #14)
s/that supported/don't support it/