Figure out what rules should be applied for a site specific browser loading data/blob urls.as toplevel documents
Categories
(Firefox :: General, task, P3)
Tracking
()
People
(Reporter: mossop, Unassigned)
References
Details
Currently these types of loads are blocked but they might be needed by some sites. The spec doesn't really say whether they are in scope or not.
data:
URLs are needed by DomTerm. For example domterm hcat
of an image works by converting the image to base64 and sending a data URL.
DomTerm could perhaps work around the lack of data URLs but it would be a major pain.
Updated•3 years ago
|
Comment 2•3 years ago
|
||
(In reply to per from comment #1)
data:
URLs are needed by DomTerm. For exampledomterm hcat
of an image works by converting the image to base64 and sending a data URL.DomTerm could perhaps work around the lack of data URLs but it would be a major pain.
Does it load these data URLs as a toplevel URL?
"Does it load these data URLs as a toplevel URL?"
No, I can't see any need for that. It would be mainly for images.
Comment 4•3 years ago
|
||
(In reply to per from comment #3)
Does it load these data URLs as a toplevel URL?
No, I can't see any need for that. It would be mainly for images.
Then you're fine irrespective of our decision here. We're not disabling all of data: URLs; this is only about whether they and blob URLs can be loaded as toplevel documents inside the site-specific browser. You could imagine, say, a link in example.com
that points to data:text/html,<a href="https://example.com/">Back</a> [more content here]
, and in theory that might "work", if we allowed it. It's not clear whether we should.
Thanks. I see you changed the title to make that clear.
(DomTerm catches clicking on links anyway, redirecting them to a regular browser window/tab.)
Comment 6•3 years ago
|
||
Bugbug thinks this bug should belong to this component, but please revert this change in case of error.
Updated•3 years ago
|
Reporter | ||
Comment 8•2 years ago
|
||
Closing per bug 1682593.
Description
•