[FIX]Permission denied error scripting SVG from data: URL after non-shift reload of local file

RESOLVED FIXED in mozilla1.9beta2

Status

()

Core
SVG
RESOLVED FIXED
12 years ago
11 years ago

People

(Reporter: Chris Nokleberg, Assigned: bz)

Tracking

Trunk
mozilla1.9beta2
Points:
---
Bug Flags:
wanted1.9 +
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.5) Gecko/20060731 Ubuntu/dapper-security Firefox/1.5.0.5
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.5) Gecko/20060731 Ubuntu/dapper-security Firefox/1.5.0.5

Using Javascript I create an object tag dynamically. The "data" attribute uses a data: URL scheme. The content is a bare-bones URL-encoded SVG document. I then add the object to the document, get a reference to the SVG root using the "documentElement" property, and create some SVG shapes via scripting.

If this is done from a locally-loaded file (file: URL), it will work the first time, and each time you shift-reload. If you reload normally, there is an error when you try to get the root element: "uncaught exception: Permission denied to get property SVGDocument.documentElement". I have yet to see the same error when the file is loaded via an HTTP URL.



Reproducible: Always

Steps to Reproduce:
1. Download attachment as *local file* and load it into firefox >= 1.5
2. Notice that it loads correctly when you shift-reload, but not when you regular reload

Actual Results:  
uncaught exception: Permission denied to get property SVGDocument.documentElement

Expected Results:  
Should work the same regardless of how the page is reloaded.
(Reporter)

Comment 1

12 years ago
Created attachment 239182 [details]
Standalone HTML+JS that exhibits the bug
I can reproduce this using the attachment without downloading and viewing it locally. I'm not familiar with the permissions issues here, but perhaps bz or roc are.
On branch this is bug 387979 (fixed in 1.8.0.13 and 1.8.1.5; reporter is using 1.8.0.5).

But on trunk, this is a bug in <object> loading which we should fix...  I'll post a patch later tonight.
Created attachment 290331 [details] [diff] [review]
Somewhat like this

A few things going on here:

1)  nsObjectLoadingContent needs to set the owner on channels that need it, like
    docshell does.  While I was here I also made javascript: URIs actually work
    in <object data="">
2)  Trying to test said javascript: URIs found a bug in the javascript:
    channel: the code to move the channel to the new loadgroup in
    nsURILoader::OpenChannel doesn't really work because of the nested
    streamchannel.  In particular, because that nested channel is the real
    document channel, onload never fired.
3)  Docshell should really handle script channels that don't inherit the
    principal (not that we have any now).  Not sure why I wrote the code the
    other way to start with.
Assignee: general → bzbarsky
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Attachment #290331 - Flags: superreview?
Attachment #290331 - Flags: review?(cbiesinger)
Attachment #290331 - Flags: superreview? → superreview?(jst)
OS: Linux → All
Hardware: PC → All
Summary: Permission denied error scripting SVG from data: URL after non-shift reload of local file → [FIX]Permission denied error scripting SVG from data: URL after non-shift reload of local file
Target Milestone: --- → mozilla1.9 M10
Is this related to bug 300263?
This patch fixes that bug, yes, due to the "while I was here I also made javascript: URIs actually work" bit.
Blocks: 300263

Updated

11 years ago
Flags: wanted1.9+

Updated

11 years ago
Attachment #290331 - Flags: superreview?(jst) → superreview+
Attachment #290331 - Flags: review?(cbiesinger) → review+
Comment on attachment 290331 [details] [diff] [review]
Somewhat like this

This makes <object> loading be more like <iframe> loading in terms of permissions stuff.  Unregresses a regression from 1.8.
Attachment #290331 - Flags: approval1.9?

Updated

11 years ago
Attachment #290331 - Flags: approval1.9? → approval1.9+
Checked in, with the test.
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.