Develop Reference

Safest way to break Flash focus?

The gist: What's the best way to escape a Flash object's focus on a webpage?
Context:
I have a hotkey listener (an AutoHotKey script) running in my tray. If the script detects the command Alt+Shift+F6 while I am clicked into a Flash object on a webpage, it activates and sends key combinations to Flash to pull certain data logs. After this process completes, I want to call up a JavaScript file on that same browser tab that requests additional information from the user - basically, a tiny UI with additional text fields available in a third-party bug tracker. To do this, I want to send a javascript: command to the address bar using Ctrl+L and having AutoHotKey paste in the full call to the JS file.
A visualization of a possible environment:
The problem:
I need the user to be clicked INTO Flash in order to pull the data logs. However, I need the user to be clicked OUT of Flash for Ctrl+L to actually work - Flash appears to eat all keystrokes at the browser-level when one of its objects has focus.
A possible solution: The easiest way to go about this would be to simulate clicking on the stage, which borders my Flash object on every side. This should work, but I must assume the stupidest possible user. Such a user would somehow limit their current browser window to only be as big as the Flash object (if not smaller), click into it, and attempt to use the hotkey. In this case...I have no idea where I should click, because it could be outside the browser. Further, I don't believe I can assume that all browser address bars are similar amounts of pixels south from the top of the window.
Additional complicating factors:
I want this to work for the user's default browser. (IE, Chrome, Firefox, Safari are my big targets.)
AHK does not provide any native DOM or COM hooks to anything except IE.
Ctrl+Tab and Alt+Tab shenanigans do not appear to work. That can get me to other tabs/windows, but returning to the tab/window with the Flash object still causes Flash to 'eat' further keyboard input.
While I'd be open to using another scripting language than AHK if it could overcome this Flash focus hurdle, I do not know how to create a keylistener that sits in the users tray until activated by a hotkey.
I have no access to the Flash object's code, and it contains no logic to interpret a key combination as a way to break focus or launch a script.

Would it be possible to use WinMaximize to maximize the size of the window? If you do that it should be easier to set up the script to avoid clicking outside the browser.

Perhaps look at ControlFocus and/or ControlSend (using the "edit1" control in IE and FF -- unfortunately, Chrome doesn't expose the "address bar" as a "control" this way but if you test for Chrome first, you can implement your "click outside the Flash box" method for that case).

iPad/Safari scrolling iframe does not allow host page to scroll (the iframe itself is scrolling)

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?

Add an option to Flash contex window using Javascript

I am tring to create a Chrome extension that adds a contex menu entry when ever the right
mouse button is clicked.
I also need for the new entry to be displayed when the right click is on a flash object (Such as Youtube clip) I cannot find a way to do it...
Can it be done? What directions should I check?

Can't do this (not from JavaScript, and probably not from Flash, either). The menu that you get when you right-click in a Flash object is generated by your Flash interpreter, not the browser - and IIRC can't be overridden.

Register click via javascript on flash without wmode in iframe(cross-domain)

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)

popups from embedded .swf cross-browser

Situation: you've got a .swf embedded in an html page, and when you click on something in the .swf, it needs to popup a chromeless window. Normally this would be fairly easy - but consider Safari, which completely disables all 'window.open' functionality while its popup-blocker is enabled (it makes an exception if the function is triggered onclick, but it doesn't count clicks in flash). How can you create something which gracefully degrades (provides an alternate and roughly equivalent experience) for browsers that won't execute window.open?
(note: this is AS3, and Safari 3 for PC or Mac we're talking about - but more broadly, any browser that doesn't support or refuses to allow the javascript window.open function.)

If your SWF is loaded using wmode='opaque' or wmode='transparent', then you could have the SWF output JavaScript code that would create an empty <div> that's positioned over the SWF area. That <div> could then handle the onclick event and create the popup window rather than the Flash code.

the div overlay was more complicated than the project deserved - check out code.google.com/p/popupfromflash for the code I came up with.
It attempts to use ExternalInterface to setup a window.open function, and if that fails (particularly in Safari) it calls back into flash and prompts it to do a navigateToURL to pop up the window normally (instead of chromlessly)