newElement.attachEvent not supported in IE11

[JamieMcDonnell]

I have noticed that for IE you are assigning the onplaying event for "newElement" in a way that only supports IE9 and lower.

Can I suggest the following that covers IE10 / 11 too?

newElement.onplaying = (element.onplaying) ? element.onplaying : function (arg) {}; if (isIE) { // on IE the event needs to be plugged manually if(newElement.addEventListener){ newElement.addEventListener('onplaying', newElement.onplaying); }else if(newElement.attachEvent){ newElement.attachEvent('onplaying', newElement.onplaying); }

Cheers!

Jamie

[johache]

Actually addEventListener is supported by IE 9 and more cf: http://www.w3schools.com/jsref/met_element_addeventlistener.asp Did you face issues using it?

Given the other issue that you opened, if you're in an iframe, make sure that IE is not switching to quirks mode, in which case addEventListener might not be supported.

[JamieMcDonnell]

Hi,

thanks for the quick reply - the issue is that attachEvent is throwing an error in IE11, while addEventListener is not. If addEventListener is supported by IE9+, why would adapter.js be using attachEvent?

Thanks

Jamie

[JamieMcDonnell]

IE11 is in edge mode, which I understand to be standards mode as apposed to quirks mode - is that correct? Thanks for your help!

[johache]

Ho, sorry, I mis-understood your question:

• in general, we use addEventListener (check the rest of the code)
• On plugin objects only, on IE, you need to use attachEvent. This is due to the technology that we use.

You should not have an error when running it. Can you tell me more about your scenario?

[JamieMcDonnell]

Ahaaa ok - I work with Inaki at eFace2Face if that helps - perhaps you are already familiar with our product? It would save me the explanation ;)

[JamieMcDonnell]

I have to head for some lunch but if it will help, when I return, I will give you a full outline of our setup if it will help. Thanks

[JamieMcDonnell]

Hi, sorry for the delayed reply.

I now have our app working and stable in dev if you would like to connect to see our setup and how we are using your plugin for yourself? Please mail me at jamie dot mcdonnell at eface2face dot com to set that up.

Our app loads in an iframe over our own, or a customer's page.

adapter.js is loaded dynamically into the host page so if the browser doesn't support webRTC we can check for Temasys presence to decide whether to continue loading the product iFrame, or show an install popup.

Because of the change in adapter.js to automatically embed the temasys object, it now appears in the top level page, despite there being no

I have also had to make another tweak to avoid showing your install toolbar, as we have our own popup - again it would be great if this was an option we could set prior to including adapter.js.

It would suit us to define a settings object before including adapter.js, e.g: var temasysSettings = {showInstallBar:false, autoEmbedTemasysObject:false};

adapter.js is then loaded into the iFrame so the Temasys object can be used to replace the

I hope that gives you a better idea as to why "attachEvent" and as in my other ticket, element.parentNode.insertBefore might be failing?

Thanks Jamie

[johache]

Hi, Step by step:

• What you you call the auto-embed object? This: <object id="myid" 'type="application/x-temwebrtcplugin"> ? This should only be injected if the browser is NOT webrtc ready.
• Avoiding showing the install toolbar: let us consider it internally.
• What do you mean the element appears on the top of the page? The element should appear at the end of the page. We need to make it 1x1 px, otherwise IE will not load the plugin code. This is an IE limitation. I believe this is not necessary on Safari, but one should verify this first.
• You start by saying your application work, and you finish by saying there are errors. Does it mean it works with Chrome but not with the plugin?

Cheers, J-O

[JamieMcDonnell]

Hi J,

by the auto-embed object I mean the object element that is embedded into the page automatically in a non-webrtc ready browser that supports temasys:

By "Top of the page" I mean the top level page, the parent of our iFrame. I guess what I am looking for is a way to check if the browser is webrtc / temasys compatible, and if so whether or not it is installed without embedding the object - it is only needed in the iFrame, not in the parent page.

I was not aware the object needed to be 1px / 1px, thanks for the info.

The plugin is working and our app is running, though only because I edited the attachEvent lines as above, and commented out element.parentNode.insertBefore(frag, element); & element.parentNode.removeChild(element);

Hope that helps to clarify the situation?

Thanks

Jamie

[johache]

It does.

Is the plugin injected in the main page even if you include the adapter from the iFrame? If yes we would need to find a way to identify more precisely where to inject the plugin.

For the 1x1 px, the size itself doesn’t matter, but IE requires it to be “visible”. It means

• it should have a non-null area,
• it should not be “hidden=true”

I need to spend more time on you issue for the attachEvent part. Someone will look into it as soon as we can allow more resources to this issue.

Thanks again

On 10 Nov 2014, at 3:25 pm, JamieMcDonnell [email protected] wrote:

Hi J,

by the auto-embed object I mean the object element that is embedded into the page automatically in a non-webrtc ready browser that supports temasys: By "Top of the page" I mean the top level page, the parent of our iFrame. I guess what I am looking for is a way to check if the browser is webrtc / temasys compatible, and if so whether or not it is installed without embedding the object - it is only needed in the iFrame, not in the parent page.

I was not aware the object needed to be 1px / 1px, thanks for the info.

The plugin is working and our app is running, though only because I edited the attachEvent lines as above, and commented out element.parentNode.insertBefore(frag, element); & element.parentNode.removeChild(element);

Hope that helps to clarify the situation?

Thanks

Jamie

— Reply to this email directly or view it on GitHub https://github.com/Temasys/AdapterJS/issues/21#issuecomment-62349613.

[JamieMcDonnell]

Thanks, appreciate the help.

The plugin is injected in both the main page and the iframe - it is injected in the main frame first, because if the browser is not webrtc compatible, and does not support temasys, there is no point in creating the iFrame for this case of user.

What would be great is if we could either use the plugin from the main page in the iframe, though on a customer website they are not on the same domain, or somehow move the plugin into the iframe if it gets successfully created (meaning it needs to be used to make webrtc calls, right?).

Perhaps having an instance of the plugin in the parent page and a second in the iframe is not the cause of the issues we have seen with element.parentNode or attachEvent, but we really only need one instance of the plugin injected into the iframe.

Thanks for investigating.

Regards

Jamie

[agouaillard]

Jamie, JO,

Some comments to help in the process:

• if you can make screenshots, it helps
• if you can make screenshots, with overlays (big red arrows pointing to the problem, windows paint 1.0 style) that helps even further :D
• if you can set up a small working test that reproduce the result so we (@ temasys) can play with it ourselves and reproduce/debug/fix, that's the best.

Cheers.

Alex

On Mon, Nov 10, 2014 at 3:53 PM, JamieMcDonnell [email protected] wrote:

Thanks, appreciate the help.

The plugin is injected in both the main page and the iframe - it is injected in the main frame first, because if the browser is not webrtc compatible, and does not support temasys, there is no point in creating the iFrame for this case of user.

What would be great is if we could either use the plugin from the main page in the iframe, though on a customer website they are not on the same domain, or somehow move the plugin into the iframe if it gets successfully created (meaning it needs to be used to make webrtc calls, right?).

Perhaps having an instance of the plugin in the parent page and a second in the iframe is not the cause of the issues we have seen with element.parentNode or attachEvent, but we really only need one instance of the plugin injected into the iframe.

Thanks for investigating.

Regards

Jamie

— Reply to this email directly or view it on GitHub https://github.com/Temasys/AdapterJS/issues/21#issuecomment-62351485.

Alex. Gouaillard, PhD, PhD, MBA

CTO - Temasys Communications, S'pore / Mountain View

President - CoSMo Software, Cambridge, MA

sg.linkedin.com/agouaillard

[JamieMcDonnell]

Hi Alex, Attached are a few screenshots (1.png / 2.png) of the issues I have been experiencing with insertBefore and removeChild - they are errors in the console.

Having tested some more it seems that the error I was experiencing with attechEvent (solved by using addEventListener) no longer seems to be a problem - at least I can no longer reproduce it...

I am attaching another screenshot (3.png) to explain my need to hide your download toolbar in favour of our more informative popup.

4.png shows the object element outside the iframe which is neither needed nor used, but is only for the purpose of detecting whether or not Temasys is supported / installed.

As I suggested, perhaps it will be quicker for you to see the issue first hand by connecting with me using our application?

Thanks

Jamie

On Mon Nov 10 2014 at 10:21:33 PM alex gouaillard [email protected] wrote:

Jamie, JO,

Some comments to help in the process:

• if you can make screenshots, it helps
• if you can make screenshots, with overlays (big red arrows pointing to the problem, windows paint 1.0 style) that helps even further :D
• if you can set up a small working test that reproduce the result so we (@ temasys) can play with it ourselves and reproduce/debug/fix, that's the best.

Cheers.

Alex

On Mon, Nov 10, 2014 at 3:53 PM, JamieMcDonnell [email protected]

wrote:

Thanks, appreciate the help.

The plugin is injected in both the main page and the iframe - it is injected in the main frame first, because if the browser is not webrtc compatible, and does not support temasys, there is no point in creating the iFrame for this case of user.

What would be great is if we could either use the plugin from the main page in the iframe, though on a customer website they are not on the same domain, or somehow move the plugin into the iframe if it gets successfully created (meaning it needs to be used to make webrtc calls, right?).

Perhaps having an instance of the plugin in the parent page and a second in the iframe is not the cause of the issues we have seen with element.parentNode or attachEvent, but we really only need one instance of the plugin injected into the iframe.

Thanks for investigating.

Regards

Jamie

— Reply to this email directly or view it on GitHub https://github.com/Temasys/AdapterJS/issues/21#issuecomment-62351485.

Alex. Gouaillard, PhD, PhD, MBA

CTO - Temasys Communications, S'pore / Mountain View

President - CoSMo Software, Cambridge, MA

sg.linkedin.com/agouaillard

— Reply to this email directly or view it on GitHub https://github.com/Temasys/AdapterJS/issues/21#issuecomment-62457340.

[johache]

I might be missing it, but I can't see your screenshots.

[JamieMcDonnell]

hmmmm I sent them by email as I couldn't see how to add them to the ticket

• let me look again

On Tue Nov 11 2014 at 10:16:54 AM johache [email protected] wrote:

I might be missing it, but I can't see your screenshots.

— Reply to this email directly or view it on GitHub https://github.com/Temasys/AdapterJS/issues/21#issuecomment-62520882.

[johache]

Still don't have anything

[JamieMcDonnell]

Hi - they have been added to my previous comment - I see the links and they all work as expected - do you still not see them?