iFrame blocker that shows the url at hovering.

In case one of our macro writers has some free time on her/his fingers it could be a helpful addition for blocking iFrames.

There is no need for a dedicated image like in the picture below. "[iFrame]" would suffice.
This way in case there is something the user would like to watch - like an embedded vid, she/he could do so by opening the link.

Example how it could look like:

I know a picture is worth a thousand words, but this time I need some words. What do you wish the macro code to accomplish? How does one know if there is an IFrame?

Quote
JamesD
What do you wish the macro code to accomplish?

To block iFrames and also to display the blocked link at hovering.

Quote
JamesD
How does one know if there is an IFrame?

By scanning the page for the iFrame tag (+ source)?

Examples for how they show up in web pages:

<iframe src="/static/sys/pixel.gif" name="spon_vdz_countframe" width="0" height="0" frameborder="0" style="display:none;">
<iframe width="560" height="315" src="//www.youtube.com/embed/FONN-0uoTHI" frameborder="0" allowfullscreen>

For now you can only hide iFrames in K-Meleon through userContent.css.

iframe {
  display: none !important;
}

IMHO this isn't really of much help because among those hidden there might be also content you'd like to watch.
The same way blocking all frames is also counterproductive.

The prob for macros is that they can only start any action AFTER a page has already fully loaded ($OnLoad event), not at the beginning of loading. Again and again, am running against a wall with many macro wishes due to that prob.
So from my (limited) point of view that wouldn't help you much. One of the main job of macros is pref toggling, yes - but again, this must be started at some "event" first, be it OnLoad or by the user firing a shortcut or menu.

What I do personally is block 3rd party frames by default ("permissions.default.subdocument"=3, toggling it by macros priv3buttons, permdefs, blockeria). And to be able to even notice that something important might be blocked on a page, have KM paint dotted red borders around iframe-tags (defined in adblock.css, where all my custom css is defined). Then when deciding I want to see it, unhide the long priv3buttons toolbar, toggle subdocuments and reload. Funnily those red borders appear rather rarely, but might be because lots of stuff is already blocked in HOSTS file, no idea. For my usage that system works well enough.

Yes it would be nice to have a link with visible URL, but if frames are blocked by default before loading, am afraid their adress is already deleted - or wouldn't they load otherwise? Haven't examined this yet though, too busy with my never-ending monster macros sigh, so you might check this yourself more deeply :-)

Quote
siria
The prob for macros is that they can only start any action AFTER a page has already fully loaded ($OnLoad event), not at the beginning of loading.

I see. A macro won't do it.

Quote
siria
So from my (limited) point of view that wouldn't help you much.

No, IMHO this wouldn't make any sense.
It's not so much about me this time. I already have a working solution for blocking iFrames and displaying a clickable URL and it works with every browser (Proxomitron).
I only thought that it would be a handy and useful feature of K-Meleon, one that no other browser offers.

Quote
siria
Yes it would be nice to have a link with visible URL, but if frames are blocked by default before loading, am afraid their adress is already deleted - or wouldn't they load otherwise?

It's only about iFrames. I never block Frames generally. I'm not aware that they are misused as iFrames are.
Proxomitron blocks them (they can't load) but displays the blocked URL at hovering (like shown in the picture above) so one can still click that link if desired.

I had hope that this CSS stuff would help, but all that I could tell was that history no longer worked.

/* --  check this for Yogi and siria +/
iframe {
  visibility: hidden !important;
}

I could find some iframe stuff on the page pictured by Yogi, but nothing that showed. I think the one at which I looked requires a script. Does an iframe on that page actually present something useful?

Visibility has some more options but if that stops history then I cannot use it.

Quote
JamesD
I had hope that this CSS stuff would help, but all that I could tell was that history no longer worked.

Yikes - history?! :O
Is that some bug, or possible why Slickone can't write history? Which version affected? What exactly doesn't work?

Quote
JamesD
I had hope that this CSS stuff would help, but all that I could tell was that history no longer worked.

/* --  check this for Yogi and siria +/
iframe {
  visibility: hidden !important;
}

Unfortunately this won't help. It's rather about blocking and in the meanwhile still offering the option to view the content.
My bad if I didn't explain it better.
Otherwise your CSS code looks pretty similar with the one I've posted above:

Quote
myself

iframe {
  display: none !important;
}

IMHO this isn't really of much help because among those hidden there might be also content you'd like to watch.

Quote
JamesD
I could find some iframe stuff on the page pictured by Yogi, but nothing that showed. I think the one at which I looked requires a script. Does an iframe on that page actually present something useful?

Nope. That iFrame on that site is neither important nor useful. It links to a .gif of 1x1 pixels and it's made invisible by the webmaster for the user.
Most of the time iFrames are misused for serving adds or even worse, for scams.
But there are also cases when the content can be important or useful, e.g. forums where a vid you'd like to watch is embedded in an iFrame.
That's why it's important to have also an easy option to access blocked iFrames.

Quote
siria
Yikes - history?! surprised smiley
Is that some bug, or possible why Slickone can't write history? Which version affected? What exactly doesn't work?

I am using KM 76 Beta 3. I have the updates except the last one which was about drag/drop. I don't use gestures so I did not put that one in yet.

As to what happened. I put the code into the User-defined stylesheet and restarted KM. I was going to the website in Yogi's picture. I could see it in my history, but when I clicked on it, nothing happened. I have since removed the code, restarted KM, and now history works right again.

I can test in KM 75.1 if you wish me to do so.

Ok, now I ended with some mind breaking real life problems (and some technical difficulties), so I can involve with this.

I'll tell just that it can be achieved, and as I would need to do for me too (collateral effect of blocking iframes :/ through permissions.default.subdocument 2 or 3), I'll make a script for it.

But I don't know when. I have to free myself from some others things out there yet.

It is a quite easy script, I think, based on the little I already played with, so I hope it won't be much difficult to write/test it. It is similar to some other scripts I've been doing for other pages.

Without knowing before what was greasemonkey, the fact is that I'm doing scripts for myself. It's a shame that we don't have a native system similar to it without installing it :/. It complicates things for average users distribution.



Edited 1 time(s). Last edit at 01/26/2016 03:30AM by JohnHell.

@Siria
After thinking twice, I have to revise my first statement regarding "wouldn't make any sense".
Even for already loaded elements through an iFrame (but made invisible through CSS) it would make sense to have a clickable link displayed.
I always prefer blocking over hiding, even so I have a flat rate with no data volume restrictions and a fast connection. But that's only me. Not everybody shares the same approach.

@JohnHell
Nice to hear that it's a feasible task.
As mentioned before, it's not as much a personal wish of mine, since I already have a workable solution that works with any browser but it could be an unique and useful feature of K-Meleon, one that even the average user could easily cope with.

To avoid an off-topic in its main thread, question:

Does K-meleon have any kind of dev mode where macros could be reloaded without close and reopen K-meleon?

This could be so useful to disaster macro coders like me. I ended opening and closing several times for dumb errors.

Dorian (if you read this), if it doesn't, maybe could be good idea for those that want to create macros, because, compared with readfile/injectCSS/injectJS where changes can be seen on the fly by just calling them again, macro coding is a toothache compared to them.

And I'm not talking about errors that are shown in the console, no, I mean for errors that prevent K-meleon to open!! at least in my case. Maybe is because my Win2k environment, but argh..., parse them on the fly would be helpful and not open-close several times until K-meleon wants to open again (usually removing the whole portion of code written before).


Aside of this, @Siria, you will need to confirm that it works in 1.5. My guess is that it doesn't. There was an error in Gecko a few versions back by Mozilla and prevents to run the code in 1.6 :/


The thread for the macro is this:
http://kmeleonbrowser.org/forum/read.php?9,137411

What is funny is find that ixquick.com and startpage.com do have an iframe.

It is some kind of counter for no-javascript users.