Adam writes:
> an attribute to prevent some protocols
> from being called by js from the internet.

I touched upon this briefly, suggesting a theoretical way js could get at local 
files.
TBH, I don't think js should access any of our plugins, period.
It fetches files via transport, that's it.
I must have been thinking this at a subconscious level, because it's already 
implemented, at least 3/4.
In the following program, zipx://hole.zip@:@talk is a valid
url to extract a file from my zip archive. The db3 log follows.

<head>
<script src=zipx://hole.zip@:@talk></script>
<LINK href=zipx://hole.zip@:@talk rel=stylesheet type=text/css>
</head>
<body>
<p> hello  world
<iframe src=zipx://hole.zip@:@talk></iframe>
<script>
// access a variable that will expand the frame
frames[0].contentDocument;
var xhr = new XMLHttpRequest;
xhr.url = "zipx://hole.zip@:@talk";
xhr.method = "GET";
xhr.send("", 0);
</script>
</body>

* b
create js context 0
css source zipx://hole.zip@:@talk
894 persistent cookies, 0 expired
the zipx protocol is not supported by edbrowse
could not fetch CSS
execute eb$qs$start
execution complete
js source zipx://hole.zip@:@talk
the zipx protocol is not supported by edbrowse
could not fetch javascript
execute jg at 9
fetch frame zipx://hole.zip@:@talk
plugin ebunzip zipx://hole.zip@:@talk
text type is ascii
create js context 1
execute eb$qs$start
execution complete
xhr zipx://hole.zip@:@talk
the zipx protocol is not supported by edbrowse
execution complete
52
* qt
894 persistent cookies, 0 expired

As you see, a frame can tap into our protocols, and I wanted that because 
frames are often youtube videos, and I want to type exp and listen to the video.
An approach here might be that frames can run players, but not converters.
A frame will never be a word doc, for instance.
What do you think?

Karl Dahlke
_______________________________________________
Edbrowse-dev mailing list
Edbrowse-dev@lists.the-brannons.com
http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev

Reply via email to