I'm currently coding counter system and have spotted one problem with flash banners without wmode attribute at all, loaded via iframe from another website.
Works only mouseout event.
The problem is, that i can't catch click event on those banners.
Is there any solution?
Thanks.
No, Flash and other plugins deal with mouse interaction on their own and cannot be interfered with from HTML. Even if you changed the wmode and layered other HTML elements on top of the Flash, having caught a click on an element you could not then route that click into Flash either.
So you can't catch a click on Flash unless the Flash is deliberately written co-operatively to pass information about clicks out to JavaScript (eg. by providing a listener interface). There is no way to reliably audit third-party Flash banner clicks.
About all you can do would be to listen for mouseover/mouseout on a block containing the Flash, and if the current window loses focus in between the mouse entering and leaving, make a guess that the user clicked the banner and popped up a new window. This is still massively unreliable (plenty of scope of false +ves and false -ves).
no wmode or wmode=window means that the Flash file is rendered on top of the page not inside it. So you practically have no means to do anything with this file without the correct wmode (opaque or transparent)
Related
What's the Problem:
Unfortunately I must use an Iframe in a web solution (tenant scoped SharePoint hosted App with App Parts).
The iframe needs around 50% of the website's space and the space for it in the host will be programmatically blown up in size so that there will be no scrolling bars shown. It works good on every browser except Safari. In Safari the touch event seems to be caught by the iframe window and will not be forwarded to the host window. Imagine this on the iPad: in over 50% of the page the user can't scroll down the page.
Hardware I used for testing:
Windows 8.1 (touch enabled screen) with latest version of Safari (5.1.7)
iPad with iOS version 8.4.1.
What I researched/tried so far:
This has nothing to do with everything that can be solved by "-webkit-overflow-scrolling: touch;" and similar approaches. From what I understood in my research, this will make the iframe scrollable but I need to make the host window scrollable when moving the finger in the iframe area. In other Browsers the iframe for example scrolls down until the end and then starts scrolling the host window
In some post one suggested to overlay the iframe with a div (z-index: 2) and then forward the click events from this overlaying div to the Iframe window ( I do have control on this Iframe window, so I can catch events in there). The overlaying div fixed the scrolling behaviour on my testing page but not in my target application, so it's not a reliable solution. Besides that: I managed the click event to be triggered (with same approach as in 3.) but could not manage to make it click links in my iframe-page (what I need... because this is the reason why I want the clicks to be forwarded.)
Another approach was to forward the touch events from the Iframe page to the host page. I did this via postMessages, JSON-stringified event parameters and a javascript library called "jquery.simulate.js" that is used to simulate touch events. I did not manage to trigger the touchmove event correctly on the parent window (and besides that I doubt that this is really good concerning user experience and performance)
I also thought about getting the simple html from the Iframe and add it to the host page programmatically. Unfortunately SharePoint hosted Apps are hosted on other subdomains, so due to the cross-browser restrictions I think is not worthid to follow.
Another approach was pointer-action: None; - This also breaks the link functionality and unfortunately worked only on the desktop
Setting scrolling="no" (or "yes") did not have any effect nowhere (maybe because it's gone in HTML5)
So here I am stuck... and it seems that no one else in this world has the same problem as I cannot find any really working idea anywhere. But I tested around 20 different websites with iframe - and I tested with the Desktop touch and the iPad.... and I have the same problem. I could not find a single Safari-Touch-working iframe throughout all suggestions and possible solutions.
How to reproduce:
A simple
<iframe src="http://www.w3schools.com"></iframe>
embedded on any html page with long content, Safari and a touch device (similar to the ones I used for testing) should be enough to reproduce.
What I want to know:
Does anyone have the same problem?
Could you put me into the right direction? I am actually unsure which of the above mentioned approaches I should continue to go on with
Do you have a completely new idea that I could follow?
Did you test this on any other device and know it's working? (I am thinking maybe downgrading could be a solution)
Edit: (Solution Nr. 2) The overlaying div makes the page indeed also scrollable in Safari, but I could not find the correct way how to forward the click event to the child successfully (meaning: which of the event parameters are necessary to be forwarded to trigger the click event in the child window?)
Edit: Searching again and found out that you cannot create events like clicking programmatically due to security reasons. Makes sense as this will be a big security issue if you could force the user to click on your ads for example.
How can I click on specific (x,y) coordinates on a web page?
My friend made it so that on their page you can't right click on the pictures to save them. After inspecting the html it looks like this is done with JavaScript to bind the mousedown event. If I disable JavaScript, then I can right click and save the pictures, but I want to try to see if I can do it without disabling JavaScript. I tried using the JavaScript console to set different values and functions to null, but it didn't work.
I set a breakpoint on the mousedown event and whenever I right click on a picture this is what happens.
return document.addEventListener("mousedown", (function(e) {
return _this.onMouseDown(e);
}), true);
Why is it necessary to bind the mousedown event every time a user clicks the button? Shouldn't it only have to be bound once at the beginning?
I tried using removeEventListener but it didn't do anything. How can I re-enable right click on the pictures?
This is the page.
Just run a browser that has a preference that prevents the web page from blocking right-click and set that preference (such as Firefox or Chrome). I can right-click save any of your friend's images in my default configuration of Firefox.
FYI, there are much more effective ways of doing right-click blocking than your friend is using (including ways that work even when Javascript is disabled), but no scheme can block anyone from taking the images. The images can always be copied via screen capture, grabbing from the browser cache, grabbing the image URL from the page source, etc...
A popular photo service uses a right-click deterrent by putting a scaled transparent gif image over a background image that is the actual image you see. When the user right-clicks they get the transparent gif, not the background image they're looking at. I call it a small deterrent because it's still easily bypassed by any determined thief. This scheme works even when javascript is disabled and even works in browsers like Firefox that prevent apps from blocking right-click because it doesn't use any javascript and because it feeds right-click the blank gif, not the image of interest.
You can see whether there are any other events attached to the document. UseVisual event
Also addEventListener is old way of attaching events, if you could use jquery then you can easily bind/unbind events using bind() and unbind() methods.
I'm trying to create an overlay containing a flash player that is shown when a user clicks on a link. The div containing the player starts with display:none in CSS. Upon clicking, the div will be shown, and JS will use ExternalInterface to configure and start the player. The JS configures the player when it catches a "flash ready" event, which is fired by Flash on ADDED_TO_STAGE.
All this works, except that the ExternalInterface callbacks are never created. The JS and AS3 work fine if the player is shown upon page load, or is hidden with visibility:hidden instead of display:none. I am aware that Flash will not be initialized with display:none, and this works as expected: when the Flash is unhidden, it fires its events and correctly initializes everything else (eg. GUI, other internal stuff). The only thing that doesn't happen as expected is that my ExternalInterface callbacks are not added.
ExternalInterface.available is true. It's not a timing problem, because even after several minutes the callbacks are still not present. The strangest bit is that the flash is able to call JS, fires JS events fine, and the code to fire the events comes after the code to add the callbacks. There are no errors thrown by any of the AS3 code. I'm seeing this problem in both Chrome and Firefox.
FWIW, I'm coding the embed HTML directly instead of using SWFObject, due to some unusual requirements.
Has anyone run into this sort of problem with display:none and ExternalInterface?
Thanks!
I have had issues with addCallBack before. What I ended up doing was having my Flash call an init() function in JS after it's loaded, then within that init, setting up and transferring variables.
Hopefully that helps!
This turned out to be a problem with some details I glossed over, thinking they were unimportant (sorry!). The showing/hiding of the Flash video was being handled by FancyBox, which actually copies your hidden HTML into a new div and shows that div. This worked as such, and the newly minted player was able to initialize and fire events. However, it used ExternalInterface.objectID to reference itself, and due to FancyBox there were now two elements with the same ID in the DOM. Therefore, the events that were triggered like $(#objectId).trigger(...) had .target set to the original Flash player, which was still hidden, and therefore had not initialized, and did not have the callbacks I was looking for.
I solved this by putting the HTML for fancybox in an HTML script tag:
<script type="text/html" id="fancyBoxTargetId">[Flash player html]</script>
this prevented there from being two elements with the same ID in the DOM (good to do anyway), and allowed Flash to self-reference using ExternalInterface.objectID.
Currently I am developing a web application for which I am using a pre-loader icon. What I want is that the pre-loader becomes visible every time the user navigates to another page or refreshes the page. So far I have the following solution:
window.onbeforeunload = function() { $("applicationdisabler").show(); };
For Safari and Firefox it works fine when the user clicks a link or refreshes the page. However in IE7 the div only becomes visible when the user clicks a link and NOT when the user refreshes the page.
The user can refresh the page by hitting F5 (on Windows) or any other possible way the browser provided.
Of course I have been looking for some workarounds already. The following code shows the alert in IE7, but the div still doesn't become visible.
window.onbeforeunload = function() { $("applicationdisabler").show(); alert("come on!"); };
The code of my div:
<div id="applicationdisabler"><img src="images/preloader.gif" /></div>
Hopefully someone can help me out.
You need to put the # before the id on the jQuery selector:
$("#applicationdisabler").show();
Why not use just use the onLoad listener instead? Although it would be slightly slower it should be more reliable.
Actually after a bit of looking around I'm not sure modifying the DOM makes any sense unless the onBeforeUnload handler returns false first - i.e. forces the user to stay on the same page.
As I understand it the onBeforeUnload event is fired just before the page is unloaded, so if you don't return false the browser will unload the page and DOM, and any JavaScript executed after that will be pointless.
That doesn't quite explain why JavaScript isn't executed properly in the onBeforeUnload function, but from what I've seen sites only use the window.alert or window.prompt dialogs to ask the user if they want to leave the site, and then often executing JavaScript if the user decides to stay.
Hence I'm guessing that some browsers may not allow DOM manipulation when this event is fired - since if the page is unloaded any DOM manipulation done is completely pointless.
So either:
Return false in your onBeforeUnload method, and then show your preloader (although this will stop navigation to the next page)
Use the onLoad event of the next page to show the preloader image instead
Also note: Opera versions 9.5 and below do not support this event (I'm unsure about later versions) but GMail does manage to catch the back button in Opera.
Possibly related is this security warning for IE7's implementation of the onBeforeUnload event - it's possible Microsoft patched it in a way that prevents the things you're trying to do. And I know IE6 and below don't allow commands like document.location='' in the onBeforeUnload handler for security reasons.
I'm using a custom right click context menu for a flash app (overriding the default adobe menu). For this Uza's right click solution ( http://www.uza.lt/blog/2007/08/solved-right-click-in-as3 ) works well.
However, flash player plugin (for Firefox/Chrome etc) has a bug which breaks usage of international characters when its using WMode for the html embed. WMode="widnow" works.
http://bugs.adobe.com/jira/browse/FP-501
The issue can be seen better here -
http://www.5etdemi.com/blog/archives/2005/06/firefox-wmodetransparent-is-completely-screwy-and-breaks-textfields/
The problem
I need to capture the right click event fired from Flash player plugin to the web browser container without using WMode on the html embed tag (ie. WMode="window")
Does anyone have an idea about this?
The right-click JS hack works in opaque and transparent mode because the browser is rendering the Flash inside its own display tree. In this mode, the browser receives mouse events, allows them to be handled by JS, then passes them to the Flash plugin. (This is the reason why there are bugs with entering accented or non-latin characters in transparent mode, because some browsers don't pass them through properly).
In the other window modes the Flash object is not part of the html DOM in the same way. Instead it is just given a rectangle of the display and can draw to it directly. It also gets its keyboard and mouse events from the OS directly, so I wouldn't expect any JS context menu hacks to work in any mainstream browser.