Closed
Bug 300263
Opened 19 years ago
Closed 17 years ago
javascript: url "is not defined" error on SVG object
Categories
(Core :: SVG, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: w.langdon, Unassigned)
References
()
Details
Attachments
(1 file)
812 bytes,
text/html
|
Details |
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
Updated•19 years ago
|
Component: General → SVG
Product: Firefox → Core
Version: unspecified → 1.0 Branch
Comment 1•19 years ago
|
||
Comment 2•19 years ago
|
||
with bug 1156's patch, this almost works... (content tree is built correctly, but not the frames?)
![]() |
||
Updated•19 years ago
|
Assignee: nobody → general
(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•19 years ago
|
||
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•19 years ago
|
||
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.
Updated•19 years ago
|
QA Contact: general → ian
![]() |
||
Comment 9•18 years ago
|
||
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.
![]() |
||
Comment 11•18 years ago
|
||
> 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•17 years ago
|
||
Bug 353334 fixed this. The test there tests this too.
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Comment 13•15 years ago
|
||
> 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•12 years ago
|
||
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•12 years ago
|
||
(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.
Description
•