Unity 3: Application.ExternalCall() not working in IE!!

I've detected a major bug!
The web player that comes with Unity 3 is not communication with javascript through Application.ExternalCall() when using Internet Explorer

In Firefox and Chrome this is working fine.

 

Yup, same here. Any work around?

 

do your security settings allow javascript to run? cause externalcall does nothing else than execute js in the page.

IE paranoia default settings don't allow it

 

I set all security to low and added the site to trusted sites with no luck. This worked fine with the previous 2.x version.

 

Does anyone have a link to a Unity application that uses this? So I can make sure its not just something I'm doing wrong. It doesn't look like the docs are any different for Unity 3 though.

 

Same problem here. When I install web player 3.0.0f2 it works fine!

 

Default IE settings are fine. Major bug report submitted to Unity team.

 

This is really serious problem
I hope it will be resolved as soon as possible.

 

I've reported this bug. They confirmed it and sent it to the def team. So hopefully they will fix this soon.

 

Hm. Yep. I have same problems. I did install 2.6.1 3.0 versions. After update new unity web player, I have same problem.

http://www.netmego.com/xe/MEGOGUBI_PAGE
<- I attached here. In game screen, second button is call another webpage using external call.

 

I'm tested bug at Firefox, Chrome and Opera now. Looks like doesn't work only at Internet Explorer.
We updated our project to Unity 3 too, and lost par of IE users now

 

A post above said web player 3.0.0f2 works fine. Can the download be rolled back to that until this is fixed? Any new user is going to think our software is broken.

Does anyone have a link where we can get that version?

 

there is no link to it no. also you wouldn't be allowed to offer it, only UT can.

would drop the support a mail on the matter also pointing here and naturally as always report a bug if not done yet

 

It has nothing to do with updating your project to Unity 3. The problem is the web player. If you install the new Unity web player (or your user does) it doesn't work in IE anymore. Also projects made with Unity 2.6!

 

Can someone please tell me when - as close to exact as possible - the "new" Unity Web Player was placed on Unity's download page?

For companies like mine, we need to reach out to any of our new customers that have tried our product since the new web player went up and beg for forgiveness and another chance!

 

This really needs to be fixed, or an older web player distributed. We have now officially lost a significant client contract due to this issue.

 

Yes, Please!! We are basically dead in the water until this gets fixed.

 

So long (

 

No offense but if that client jumps ship THAT easily, then you're better off without them. Imagine what would happen if you dared catch a cold!

 

At around 0800 PST on Monday 27th.

 

Is any progress there?

 

I presume you mean Monday 4th of Oct? 27th was last Monday.

 

No offense, but when some guy shows up to me with his "amazing" game and touts that it can run anywhere as a major selling point, and it doesn't even run on my own gaming PC on arguably the most mainstream browser, then yes I can totally understand thinking that guy can't do the job well.

Anyway, just adding my voice for a fast fix, this is a totally critical piece of functionality.

 

don't add your voice, report a bug.
Thats faster and much more impacting in this case.

 

It's already been reported, so reporting it again would have no positive impact and just waste their time (and mine).

 

thats a rather destructive point of view.

numbers make the "how severe is this issue really" rating, not "is or not is reported"

Sure its a severe thing independent of the case.
But in general: if a single person reports an issue, don't expect it to be anywhere in the high priority end of the list, cause 1 of 150k users = "htfc??"

But 100 of 150k, especially active users, then its a totally different thing.

also you forget that you don't waste developer time there. its the Q&A team that will go through your reports, check for reproducability or dublication.


also as far as I can tell, more bugreports would potentially help UT to realize that stealthing the issue database etc from us and making us waste time to report stuff that 50 people reported already, is a top notch major issue on its own and the more time they have to waste, the more obvious it becomes. its a top notch issue not only cause it wastes a lot of time on reporting, but also cause you waste days in finding the root of a problem that 30 people already reported which nicely put is S*** annoying and costs thousands of USD and countless hours of development time per team per year as you will find out when you are longer here.
They are aware of this problem already too, many devs reported the problem, there are two dozen threads with most of them having postings from staff members but as you see, even years later we still work against the same time and money wasting system.

 

Regardless of your point of view, Dreamora, this webplayer bug is a major issue. Especially when it was tested and working in f2. We still have to showcase our technology to potential investors, so we are forced to use the working player, f2, in order to do this. You seem to be an expert on everything, and a lot of your comments have a condescending tone, when people are just trying to solve problems and be innovative. Not every business model fits your point of view.

 

Anyone that needs a copy of the working f2 webplayer to be able to test their projects please send me a PM with your email address.

 

Sure its a major issue.
Nobody said anything different, not even I.

What I'm saying is that if you find a bug, report it, as multiple independent people reporting a bug gives it more weight than if only a single person does

 

Well, here is the end of the week... 5 days, and not any hot fixes with that really critical bug very sad, guys.

 

new Unity releases don't happen in days. normally more on the scale of 3-5 weeks.

in this case its more a matter of a new webplayer version though so unsure how thats going to work as webplayer versions are normally tied to unity releases from what I recall. the webplayer won't update itself if the version isn't newer

 

Yes. It is a real show stopper, unless you force your clients to install the f2 web player which still works.
That's what we are doing.

 

Well since it is Monday, just bringing this back up to see if this is getting fixed?

 

Same problem here, needs fixing!

 

Any news on the hotfix date?
They said it would be released last week!

 

i have 2 emails in to support with no response. Great service...........

 

I get the information, that bug will be fixed very soon so - just waiting for

 

Guys,

Sorry for the long delay in me responding to this thread. We have had a couple of related issues appear as we have tested the fix for Application.ExternalCall which has delayed the hot fix. I am pushing for this fix to go out tonight European time. We'd prefer to ship something that has been tested correctly, rather than rush something out and then have to hotfix the hotfix.

I am truly sorry that i have not kept you all in the loop. I can full understand how frustrating silence is for you when you have your customers to keep on your side.

Thanks,
Graham

 

Not that it matters but there are ways around the problem to allow you to communicate between the player and web pages without using that feature. You just have to know REST/AJAX or your own ActiveX controls with back end database systems. Still, a fix to a feature is good.

 

Hey guys,

Bad news I am afraid. We have not had complete success testing tonight. We know the plugin we have works, since a fresh install with it produces a working result. However, getting this process automated so end users get a working plugin on their machines is what is failing tonight. We'll continue working on it, and fully expect to fix this once and for all tomorrow. I will keep this thread updated with progress.

Regards,
Graham

 

Thanks for the update, it's very reassuring to know the progress on this, even if it's "bad news". These "bad news" are approximately one million (1 000 000) times better to hear than no news at all.

 

Sleep always yields a working result That or jack daniels..

 

We are pushing installation of the f2 player for now. It's really awkward for our clients, but it works. Thanks for the news.
Hopefully a fix is in store before the end of the week. It's kind of confusing when you have to explain to a Fortune 500 company that they have to use an old version of the new player in order for them to get a presentation of your cutting edge technologies.

 

Guys,

Thanks for your patience while we sort this out. I can now say with certainty that we fully understand why we were seeing crashes in testing last night, we have this in hand, have a new version which we will start testing very soon, and still fully expect to have a fix pushed live today.

@Zumwalt - the Unity stash of JD ran dry months ago during the 3.0 beta phase. But it turned out well to get a shed load of testing done late last night so the devs had plenty of data to eat this morning.

Regards,
Graham

 

Guys,

We have now pushed out plugin version 3.0.0f6. This should fix the ExternalCall bug we introduced in 3.0.0f5. Now, when a user with the 3.0.0f5 plugin views 3.0 content, their plugin will be automatically updated. A browser restart is required for the 3.0.0f6 plugin to be activated, however.

Our web browser plugin contains two parts, the "player" and the "plugin". The player is a DLL that actually does the work. The plugin is a OCX or DLL that provides the glue between the player and the web browser. What we have pushed live is a new plugin, since this was where the ExternalCall stuff is implemented. You can see which version of plugin and player you have it you visit:

http://files.unity3d.com/webplayer_test/version/

This will show 3.0.0f6 against the plugin if you have been updated to the fixed version. If the plugin is shown as 3.0.0f5 then your plugin has not been updated, or, your plugin has been updated but you have not restarted your browser. (Note that any browser in use by any user on the machine can have the 3.0.0f5 plugin locked, so when I say browser restart I really mean close all browsers and then reopen them.)

If you want to discuss this issue further please do so here, or PM me if you think you might have something unique to your setup. If you have bugs please always report them using our bug reporting tool so the QA team have details on what happened. You can always post the bug number here - remembering that you only need to post the 6-digit number.

Thank you all for your patience while Unity responded to this issue. Once again, please accept my apologies that I let this one slip through the net. A lot of our test rigs had been set up to use FireFox, and this has not given us the coverage we should have had. We have fixed that now.

Kind regards,
Graham

 

Is it just me or is that version like 20X faster on loading and use? cool....

 

Great! All works fines here Thank you, guys

 

Will all users who update to the 3.0.0f6 version of the plugin need to restart their browsers, or just those updating from 3.0.0f5? One of the strengths of installing the Unity plugin is that it doesn't require a browser restart, merely a refresh.

Thanks.
Amy.

 

Thanks for the update. Things are better but I'm still seeing an issue.

If I access a Unity Web application with IE, the plugin gets updated. I can see this from going to the "version" web page. It shows 3.0.0f6.

Yet the ExternalCall still doesn't work after just a simple browser restart. Even a reboot does not help.

There are 2 ways I can get it to work:

1. Download and install the Plugin manually from the Unity site.

OR

2. Close IE, Start Firefox, access the Unity web application with firefox. Close firefox. Now IE works properly.

This is on Windows XP, IE 7, Accessing an existing Unity 2.6 application.

Thanks for any help.