I was browsing sidki's site (nice, thanks sidki
), when I noticed the "unfiltered submit popup" test case here:
http://www.geocities.com/sidki3003/prox-test.html
To my surprise, the demo worked, so I copied the source code to my hard drive for further testing.
I modified the code to simulate the "injected scripts" that I would normally put in via proxo and added a link for testing.
Code:
<head>
<script type="text/javascript">
// Prx Start js
HTMLFormElement.prototype.PrxRealSubmit = HTMLFormElement.prototype.submit;
HTMLFormElement.prototype.submit = function(){return null};
</script>
<title>Submit</title>
</head>
<body>
<h1>"submit" popup</h1>
<form name=kim action=about:blank method=get target=newWin></form>
<script type=text/javascript>document.kim.submit();</script>
<a href="javascript:void(document.kim.submit())">submit[/url]
<script type="text/javascript">
// Prx End js
HTMLFormElement.prototype.submit = HTMLFormElement.prototype.PrxRealSubmit;
</script>
</body>
While the above code prevents the popup with firefox, it doesn't work with ie.
However, I found this link about emulating dom objects in ie here:
http://delete.me.uk/2004/09/ieproto.html
The techniques described there looked interesting and may provide a solution to this and offer other posibilites as well.
Any thoughts on this?
Mike
wow! i frequenlty visit sidki's site but somehow missed that "demo"...
quite cool!
yep, confirmed a "hit:body-onmousemove" (four of them) pop-up opens (via a new tab in Sleipnir 1.66 [2.00 beta1 is strictly Japanese thus far])...
Yep, targeting the object's prototype - or emulating that, would be *the* solution, not only in this case. I've played with that while trying to find a solution for the "Frame Methods" testcase.
The problem there was that an early "window.frames" shouldn't be blocked, but delayed until the page has loaded. The anti-popup functions would then kick in again for the bad guys, and the good guys could pass. Otherwise quite a few pages got broken.
I didn't check that with "submit", but i could imagine that it's similar there. Anyway, definitely worth a try, but would require some time of testing.
As for the IE emulation, i saw that too, sounds promising. Check it out.
I'll mess with it later as well (short in time the next couple of days).
sidki
Hi
I haven't tried the Frames test, I'll check that out later.
For submit, my initial thought was to disable it till the page loads, but emulating prototype for html elements with ie is key to that. Once that works, the code could be tweaked as required.
As I have a bit of free time for the next couple of days, I think I'll play around with it since nobody has said "been there, done that, doesn't work".
Mike
Sidki,
How does one filter UTF-16 to convert it to UTF-8?
Basically you need to test for and remove a two-byte (=char=[%ff][%fe]) marker at the very beginning of unicode pages. Then you have to remove every second byte (=char=[%00]) for the entire page, before any other filter gets a chance to kick in.
Have a look at "Top Remove: Unicode BOM: HTML" (you'd just need the "[%ff][%fe]" case) and "UTF-16 to UTF-8 Page Converter" (just the "bom=le_low" case) from my config.
sidki
z12 Wrote:I haven't tried the Frames test, I'll check that out later.
Oh, that problem isn't urgent. I just wanted to say that you may break pages, if you block early auto-submits. The solution could be to delay them until the page has loaded, like in the Frame case. But again, i may be wrong.
Quote:As I have a bit of free time for the next couple of days, I think I'll play around with it since nobody has said "been there, done that, doesn't work".
Cool - keep us posted!
sidki
While researching DHTML behaviors in ie, I ran across this:
http://blog.codingforums.com/index.php/m...and_above/
This looks like it may be just what the doctor ordered.
However, my initial testing has revealed what appears to be a "timing" problem, as desribed here:
http://msdn.microsoft.com/workshop/autho...asp#Timing
Here's a code snippet of what I'm trying:
Code:
<head>
<style type="text/css" onreadystatechange = "bload()">
* { behavior: url(HTMLElement.htc); }
</style>
<script type="text/javascript" >
function bload(e){
if (!e) var e = window.event;
if (e.srcElement.readyState=="complete"){
alert(e.srcElement.nodeName);
// Finish initialization.
HTMLElement.prototype.test = function() {
alert(this.innerHTML);
}
document.getElementsByTagName("body").item(0).test(); // alerts its innerHTML
}
}
</script>
If I comment out the alert displaying the node name, I get a script error.
I think the problem might be solved using the import processing directive to load the htc instead of the style tag, but I haven't been able to get that to work
Another potential problem with import is that it wants a namespace specifed in the html tag, but if I could get import to work, that might be fixable.
Any thoughts on this?
Mike
The nice thing about the ieproto approach is its simplicity.
But it looks like you can just append new attributes with it, not redefine existing ones.
Also, i don't see where to specify the object.
As for HTMLElement.htc, this thing is extremely slow, it's apparently applied to every element in the tree. Maybe it helps to cut down that constructors array to just the objects we need, maybe strip other things as well.
z12 Wrote:If I comment out the alert displaying the node name, I get a script error.
Odd! If readyState isn't complete, that function doesn't do anything. I don't get a script error here when commenting out the first alert, while *bypassing* Prox (although IE crashed on me when loading HTMLElement.htc the first time).
I always got an error with Prox, as long as i injected any code just above </body>, seems to be located in the HTC's "j" loop. Maybe fixable. Or disappears anyway, after cut-down.
Generally, creating a resource-friendly function that loops until readyState is complete shouldn't be difficult (? la LoopMe() in my set).
Quote:Another potential problem with import is that it wants a namespace specifed in the html tag, but if I could get import to work, that might be fixable.
Not that i know of -- Just tested, works here without that in IE/Fx/Opera.
sidki
z12 Wrote:Another potential problem with import is that it wants a namespace specifed in the html tag, but if I could get import to work, that might be fixable.
If you mean a specific problem with importing HTC files, i have no clue, that was the first time i used one.
sidki
At this point, I haven't had much luck applying the "behavior" in the head section where we inject our scripts.
If that can't be made to happen, it won't do us much good.
Until I have more free time to read up on htc files, this project will have to wait.
Mike