Closed Bug 1559239 Opened 6 years ago Closed 5 years ago

File access error with OOP-iframe

Categories

(Core :: DOM: Content Processes, defect, P3)

Product:
Core
Component:
DOM: Content Processes
Type:
defect

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: rhunt, Unassigned)

Details

Ran into this when writing a test using 'fission.oopif.attribute=true'. I wrote a 'main.html' and 'inner.html', then visited the 'main.html' via file:///.

I then got an access denied error message inside of the iframe. Removing the fission attribute resolved the issue.

I strangely don't get this on every test I've written in this manner. Might be something to do with process allocation and sandboxing?

main.html

<!DOCTYPE html>
<meta charset="utf-8">
<html>
<body>
	<iframe fission=""
			width="400"
			height="400"
			src="./inner.html"></iframe>
</body>
</html>

inner.html

<!DOCTYPE html>
<meta charset="utf-8">
<html>
<body>
</body>
</html>
Fission Milestone: --- → ?
Flags: needinfo?(nika)
Blocks: fission-dogfooding
No longer blocks: fission

This is a known flawed property of fission.oopif.attribute. We always force the oop iframe element into the web content process, so if the sandbox is enabled it won't be able to load file:// URIs.

Given the flaws with the fission attribute, we should probably remove it. What reason do you have for still using it?

No longer blocks: fission-dogfooding
Fission Milestone: ? → ---
Flags: needinfo?(nika) → needinfo?(rhunt)

That seems reasonable to me. The only reason I have used it is for ease of creating test-cases without managing files on different origins. For example, see most of the files on 'https://eqrion.github.io/web-tests/fission'. It would be nice to be able to keep that, but I don't feel strongly about it.

Flags: needinfo?(rhunt)

(In reply to Ryan Hunt [:rhunt] from comment #2)

That seems reasonable to me. The only reason I have used it is for ease of creating test-cases without managing files on different origins. For example, see most of the files on 'https://eqrion.github.io/web-tests/fission'. It would be nice to be able to keep that, but I don't feel strongly about it.

I don't know if it works fully, but we should isolate into a separate process if we do something like <iframe sandbox="allow-scripts"></iframe>. So long as we don't set allow-same-origin, I think we should isolate.

There's a chance we don't right now, but, that's another problem :-P.

Tentatively moving all bugs whose summaries mention "Fission" (or other Fission-related keywords) but are not assigned to a Fission Milestone to the "?" triage milestone.

This will generate a lot of bugmail, so you can filter your bugmail for the following UUID and delete them en masse:

0ee3c76a-bc79-4eb2-8d12-05dc0b68e732

Fission Milestone: --- → ?

fission.oopif.attribute was removed in bug 1562029.

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WONTFIX
Fission Milestone: ? → ---
You need to log in before you can comment on or make changes to this bug.