Couple questions regarding flash security and https migration.

[msp...@gmail.com]

 Hey all. I'm a hobby coder, not a large scale developer or anything of the sort. So forgive me if outreach to my ilk didn't really happen and i'm just now catching up on all this.

 I have created a mixed content .html file that loads some .js support, some .css support, and is basically a great big container for flash objects with some menu controls and automation. I will briefly describe how the content is intended to function so you have some context.

 The .html page is loaded within an embed on a site that hosts chat rooms and allows user customization. We are basically allowed to dress the room up, with some caveats. Within this container are 7 flash objects. 6 are flash video containers that can play or record to an rtmp server. The 7th is a media player streaming aacp. The container as a whole is coded to scale to maintain uniformity in it's page position on the right. Text chat happens on the left. The purpose is basically to add a more human element to the chat. Users are free to cam while they chat and live DJ's can takeover the music streaming to DJ for them. Everyone has a good time and this all worked great until two things happened at some point while I wasn't paying attention and with my other devices.

 1) At some point Chromium decided anything flash smaller than 300 x 400px was 'invisible'. This broke the auto load whereas even if the user chooses to allow flash on the page, they still have no say over auto load. It's actually a convenience to the users that this occurs automatically for them and they are accustomed to it. This occurs for both the music player (Jwplayer) and the cameras (VideoIO). Also, stacking 3 cameras high, two rows, and the media player at the minimum requested size is simply not realistic to meet the new auto load standards. Can I appeal to a developers inner sense of reason on this? Flash media streaming for audio commonly uses a basic player bar that i've never seen higher than 80px, maybe 100px max. Perhaps play list driven players will go larger but a streaming player streams a fixed stream. It's utilitous and doesn't need to consume real estate for this purpose. How was the determination made that an object must be at minimum 300x400 to be considered visible? That's rather large IMHO. If this is some sort of attempt to mitigate annoying hidden players, it doesn't stop anyone from placing one in the first layer of a page and layering the rest of the content over it. How about absolute positioning it off the page? CSS allows all sorts of content deviance. It doesn't make sense to me to put the cart before the horse. Does this new rule apply to html5 players where similar abuse could occur? I'm searching for some rationale on this one.

2) The site hosting the chat rooms is migrating to https. The migration does not appear complete. My content loads fine without console flags if loaded from my domain. Hosted on their domain, I get cross domain origin warnings and camera and microphone access is disabled. This renders the cams useless. I have taken the necessary steps to certify my domain via Chromiums suggested certbot and migrate all my support code properly (I believe). The console error Opera throws up suggests line one of their page document. Only thing I can see there is all the URL references for the document type are http. Is the browser scrubbing these docs and examining the URLs? All of my document URLs have been migrated to https. While their document is loaded over https, the document declaration still contains http references. I'm just trying to sort out who or what is preventing the camera and microphone access in his use case. Again, loaded stand alone from my domain everything works fine. This suggests further the parent hosting document is causing the issue but i'm unsure if there is anything I can do to work around this. While parent documents should be in control of child content, it creates issues when the children are compliant and the parents are dragging their feet.

 FWIW,  I looked into html5 before I even started the project. The support cross browser for rtmp video was abysmal and flash was widely used. html5 players offer no support for shoutcast aacp streams whatsoever. At least not last I looked. If html5 can't yet replace these things in all cases, why cripple whats working; Prematurely? 

 Welcome any thoughts on my current issues. I'm not having these issues in non-chromium based browsers. Thanks!