Flash Player 9r115 getURL() local

[WhatTheSamHill]

We have developed an application to run online as well as localy. We have used
the getURL method to execute JavaScript functions. Since the release of r115 it
no longer works on our localy run application but continues to work fine on the
online version.

We are not hosting content on seperate domains and so the cross-domain policy
does not come in to play, it is a simple SWF embeded in a HTML page that
contains JavaScript functions. We have "allowScriptAccess" set to "always" and
have updated our security setting to allow the content to run (we have built
several of these apps before) but since the release of r115 it's cactus.

Since there is not an issue of cross-domain policies I am guessing this is a
bug that will fixed soon by Adobe...please. Anybody else had this issue???

[BronwynL]

I've had exactly the same problem. Player 9,0,47,0 worked fine, then when I had
to reinstall a misbehaving CS3 web suite and subsequently downloaded the new
player everything went pear-shaped when running the app locally. Again, it's
getURL() talking to js.

I'm having to delay the delivery of this project to my (very) large client
because of this. I hope this is not because of the overlap of AS 2 code with AS
3 security...

Adobe? Hay-ulp?

[haida]

I'm also having the same problem. I'm working on a CD-based application, so
everything should run locally. I really need Flash-javascript communications
for various functions required by our clients. So far the solution given by
Adobe is for getURL used to open a web address, not when it's used to call
javascript functions. I've also added a trust file in the Flash Player Trust
folder and set Always Allow in the online Global Security Settings but it just
won't do anything. Adobe???

[BWolfe [ADOBE]]

We're testing this. Other reports of this behavior indicate that it might be specific to IE7. Can anyone on this thread confirm or deny that?

[BWolfe [ADOBE]]

OK I answered my own question. Here are the results of my testing:

1. I had an existing CS3 created Flash AS2 SWF that I posted to test the live
use of getURL when this first came out. (Live is no problem. Only local testing
is a problem). A button makes this call:
getURL("javascript:fireFunction();");

The corresponding function in the HTML then does this:
function fireFunction(){
//fire an alert for in-browser testing
alert("function fired!");
// launch a new window

window.open('http://www.adobe.com','win','height=200,width=300,toolbar=no,scroll
bars=yes');
}

2. For testing this on my XP box I added the following path to trusted
locations in the Settings Manager:
C:\Inetpub\wwwroot\escalations\cs3_getURL

3. These are the results of my testing:
Windows XP:
FireFox 2 tested from URL:
C:\Inetpub\wwwroot\escalations\cs3_getURL\getURL_AS2.html
-- no problem after adding trust file. Both alert and new window
open.
FireFox 2 tested from
http:\\localhost\escalations\cs3_getURL\getURL_AS2.html
-- no problem after adding trust file. Both alert and new
window open.
IE6
--no problem after adding trust file. Both alert and new window
open.
Mac OSX 10.4 FireFox 2.0.0.11
-- no problem
Mac OSX 10.4 Safari 2.0.4
-- no problem

IE7 is another story though, and this local getURL issue appears to be IE7
only. Nothing happens when clicking the button. No security errors are
noticed. But no javascript fires.

I'm going to escalate to Engineering and see what happens. In the meantime (in
theory) you can use externalInterface to make these calls. I haven't tested
this yet though.

[WhatTheSamHill]

I did some of my own testing around this. We are using IE6 SP2. I found the
problem with the getURL failing silently only occurred when the flash project
was published out as a FP9 project. We could take the same project and publish
out as FP8 and run it using FP9 locally and the getURL calls would work. It is
not feasible for us to roll this project back to FP8 as we are using some of
the new features included in FP9, and so the best result would be for Adobe to
release a fix for this.

Since the project is running locally and all files are on the same domain it
makes sense that the project wouldn't suffer from increased security. I also
tried adding the filepath of the project in the trusted locations, but this did
not work either.

[BWolfe [ADOBE]]

Engineering is still investigating as of today. So I don't know more than I
knew on Friday other than that they've confirmed the behavior.

The only workaround that will currently work is recoding with
externalInterface.

[BWolfe [ADOBE]]

bump.... no news as of yet.

[etopete]

Do you think that a new player update would come this week ?

Thanks

[BWolfe [ADOBE]]

No, no new player update will be coming this week. In fact, I cannot comment on when or how this might be addressed at this point. Sorry.

[etopete]

I would hope that adobe fixes this soon as this affects many of us worldwide
who burn Flash apps onto CD for our clients; the great majority of them have
IE7 as their default browser. We're already getting calls in from some of our
clients telling us their CD's are not functioning.

So my only solution to this is recoding all my apps ?

Is the correct solution is changing all the getURL for the
externalInterface.call function?

[Sofax222]

Me too !
When FP9 r115 and IE7 work together on local, the getURL with
javascript/vbscript will fail !
But, after my changing the register of Microsoft Web Browser (Microsoft
Internet Control {8856F961-340A-11D0-A96B-00C04FD705A2}) from "ieframe.dll" to
"shdocvw.dll", it will work successfully once in first page.
And it still fail in subsequent pages.

[JasonHolm]

So how does one go about converting a getURL() function to an
externalInterface.call() function? Is it as easy as adding an "include" line
and copying the contents of the parentheses from one to the other?

[BWolfe [ADOBE]]

"So my only solution to this is recoding all my apps ?"

I hope not, but I do not know yet. Engineering is actively testing. It's
definitely something we introduced in some changes made in Flash Player
9.0.115.0. Just not sure what their verdict is at this point.

So your choice is wait to see what they say, or recode for externalInterface
if possible.

Sofax222, the registry key thing makes no sense to me. And doesn't seem to
work very well. So I'd avoid that. It's our bug, we'll deal with it.

Converting to externalInterface requires rewriting your code and republish the
content. The externalInterface API is here:
http://livedocs.adobe.com/flash/9.0/main/00000340.html

[Sofax222]

Converting to externalInterface still didn't work

[Mode Conkey]

Okay, I'm have Flash 8 with Actionscript 2, and I'm trying to use the
'ExternalInterface.call' method. I've made a simple movieclip onPress function
that used to use the '[b]getURL[/b]' command, but now it uses the
'[b]ExternalInterface.call[/b]' method to call a javascript function that runs
the 'window.open' command to open a local html popup on the computer. Neither
seems to work. Here are the basics:

this.onPress = function(){
ExternalInterface.call("popUp", "C:/...filepath to html page on
computer", "windowName");
}

Obviously, "popUp" is the name of the javascript funtion (which is written in
the html page embedding this swf AND in the source js file), "C:/... filepath"
is the filepath parameter to be passed, and "windowName" is the window name
parameter being passed.

The basic javascript function is this:

var winn = null;
function popUp(filePath,windowName){
winn = window.open(filePath, windowName)
}

What am I doing wrong? Neither the getURL or ExternalInterface.call methods
will work to call javascript, and I've got clients calling in to tell me our
software has stopped working. Am I passing the string parameters the wrong way?

[bnicer]

Hi,

In an earlier thread it was suggested, "both methods (HTA and
FlashPlayerTrust) appear to have stopped working."

That's affirmative. HTA doesn't work either. HTA is not necessarily IE7.

I haven't tested HTA with IE6 installed. Most likely it is not affected, I
reckon. Would it help if I tested it?

The earlier thread also said, "Keep up the good work!" I second that.

[WhatTheSamHill]

OK, after further experimentation with the Flash Player r115 I have been able
to isolate the problem I am having, and it is definitely a problem with the
player.

As previously reported the I am experiencing the problem with Flash Player 9
r115 & IE6 sp2 and getURL when trying to execute Javascript on a local file
system.I have discovered the problem exists when running content within a
frameset. All files are running in the same folder on the same drive but getURL
does fail when the page that the flash file is on is run within a frameset. To
see the conclusive evidence download this simple flash file.

www.omniap.com/downloads/geturl-flash9r115-240108.zip (9kb)

As you can see with this example the flash file calls a javascript function
which simply alerts some text to the screen. When run outside of the frameset
this works fine, however when the page is included as a frame in a frameset,
the getURL fails. This is the case on local files systems only and works fine
online. Please Adobe, fix this.

[itairaz]

Does anyone know if adobe is working on fixing this, and some sort of ETA?

This is killing us...

[CBT Developer]

This issue is 100% because of updates in the v9.0.115.0 Flash Player. Flash
Player v9.0.47.0 is fine. The issue occurs in both IE6 and IE7. The issue
occurs in content played locally, where the getURL(); function is calling
JavaScript and the Flash <object> is within a Frame. The issue does not occur
when the same content is played through a web-based network / web server...
only for local content.

The problem - at least from a Flash Developer or End-User perspective - has
nothing to do with files being trusted (or not trusted), or the
AllowScriptAccess parameter.

Ultimately, the solution will have to come from Adobe with a patch / fix / new
player release. For me, the developer, the immediate solution is to either
simply not use the v9.0.115.0 release and wait for the updated release that
will resolve the issue, or play the content from my local web server (IIS,
Apache, etc.)

Since we have control over my end-users Flash Player version, and in any case
they will not view the content locally (It's only my team and I who are
affected.), I choose to rollback to v9.0.47.0 and wait for Adobe.

Adobe, please place a high priority on this issue.

[shancan]

I author videos in Camtasia using the embedded flash in html. Started getting
bug reports about 10 days ago from users. Alien sounds gurgles and boings in
the videos. Checked with Camtasia and they said "Problems with sound on .swf
files with mp3 audio are because of the latest Adobe Flash Player 9.0.115.0.
They play fine in earlier versions of Flash Player.
We've reported this bug to the Adobe Flash Player team, because earlier Flash
Players play these same SWF files without the garbled audio."

No idea when or if Adobe is going to come out with an update to fix their
update. But Camtasia provided me with a downloadable utility fo fix the .swf
files it's called "SWFMP3FIX" but I have over 500 videos and can't possibly
take the time to fix what was never broken until Adobe's new Flash Player
wreaked havoc on my world! This is very frustrating!

[bnicer]

Topic: FP9 r115 getURL() local

The problem occurs in a normal browser window without frames in IE7, eg.
viewed in a normal window messages sent to the status bar triggered in Flash.

I agree with CBT Developer, getURL() is broken in spite of and not because of
trusted folders. It would suit me fine however if Adobe decided to drop
FlashPlayerTrust in the next Flash release and that happened to fix the current
getURL() issue. FlashPlayerTrust was introduced in Flash 8 to make it more
secure locally, not impossible, to execute JavaScript from Flash.

[coitza]

any update on this, i still have this problem :(

Milo,
http://www.pegasusdirectory.com

[shancan]

FlashPlayer 9.0.115.0 is the FlashPlayer from hell, as far as I'm concerned.
Doesn't matter if you're on Mac or PC, Explorer, Firefox, or Safari...if you
have this FlashPlayer version it causes utter havoc! I've been a content author
for years, using Camtasia Studio producing .swf videos with mp3 codec for voice
that are nicely produced being embedded in an html page. The new flashplayer
has broken the sound on all videos produced this way, whether they're online or
CDs. It has introduced a gurgle, boing, alien type noises on the sound track.
No previous versions of FlashPlayer do this. Yet Adobe still has the dang thing
up there as the update and to download. It's horrible. Camtasia does have a
utility they are providing that fixes this. It's called SWFMP3FIXER which you
can download from their site. It involves dropping the.swf file into the
utility, hitting fix and then reuploading to your server. A TON OF WORK! And
this of course doesn't help the customers who have CDs or DVDs with
instructional videos but have had their browser update to the funky new
FlashPlayer. I'm about to lose my mind...can u tell? Where does the liability
and responsibilty lie here? From what I've learned Adobe has been aware of the
issue for almost a month....yet nothing has been done or posted about when they
will fix it. I don't know whether to tell my customers to uninstall the new one
and reinstall an earlier version, because I also noticed threads of problems
with trying to get rid of the flash player. I need some sound (no pun intended)
advice and a DATE when this issue will be fixed. I can't seem to get any
answers other than "Adobe is aware of the issue" how bout an "Adobe will
release the fix by such and such a date"

[bnicer]

Bring back Macromedia.

The latest version of Adobe Reader also has a problem with local trusted
content. I requested the feature, since the prompts to open files are getting
on my nerves. Still waiting to hear from Adobe.

[etopete]

Bentley:

Do you have any update from the developers on the time that will take them to give us a solution for this bug ?

[BWolfe [ADOBE]]

[q][i]Originally posted by: [b][b]etopete[/b][/b][/i]
Bentley:

Do you have any update from the developers on the time that will take them to

give us a solution for this bug ?[/q]

The bug for getURL("javascript:blah()") failing when the content is local to
a drive or cd or dvd is still open. If you need a fast workaround my tests
with externalInterface have been successful. I am pushing for a fix in the
next Flash Player update but I cannot guarantee that will happen, nor can I say
when that update is coming.

In the meantime we've nailed down a similar getURL("javascript") bug only this
one's with live content. If the HTML and SWF are in separate domains the
getURL("javascript") calls will fail in IE6 and IE7 only. ExternalInterface
has been successful as a workaround for that as well.

I expect to have both of these in a technote shortly so that while a long-term
solution may not be immediate we can at least save a lot of folks from
struggling with this issue.

[WhatTheSamHill]

Can Adobe guarantee that a patch will be released at some point in time. It's
additional cost to our business and frustration for our client to make these
late changes to our project (externalInterface). I would have thought any issue
such as this would warrant a very quick release of a patch, or are there not
enough people complaining yet?

[BWolfe [ADOBE]]

[q][i]Originally posted by: [b][b]WhatTheSamHill[/b][/b][/i]

enough people complaining yet?[/q]

Unfortunately no, I cannot guarantee what's going to happen or when. I'm
pushing for a fix, and that's all I can say at this time. Keep in mind that
updating Flash Player is a -very- non-trivial task, involving several thousand
man-hours of testing just for a single dot release, and hundreds of thousands
of testing hours for a major release.

[--MastaShake--]

We've been using getURL for years and a lot of ppl that I work with still use
getURL because it seems easier to them than ExternalInterface. So all those
swfs we've made are now not working when our sales ppl take local copies to
show to potential clients. Within the past month we've had numerous extremely
embarrasing situations where a sales rep couldn't even get past the Splash
Intro screens within our courses.

Then I have ended up embarrased because, after ensuring that their trusted
paths were added to the security manager and that active content was allowed to
run in IE7 and everything else I have ever known to make this work, I have no
answers for them. I thought I was going crazy. And asking them to use Firefox
would be like asking my mom to use the cmd line.

This is absolutely eating into our schedules, and now I have to QA an enormous
amount of swf content to ensure that all getURL() calls are converted to
ExternalInterface.

Please Adobe, I love you, but this is hurting bad :(

[--MastaShake--]

[q][i]Originally posted by: [b][b]CBT Developer[/b][/b][/i]Since we have

control over my end-users Flash Player version, and in any case they will not
view the content locally (It's only my team and I who are affected.), I choose

to rollback to v9.0.47.0 and wait for Adobe.[/q]

Is there a link to the v9.0.47.0 flash player? I'd like to have my sales ppl
install this version as a temporary fix.

Is there any dangers with rolling back to v9.0.47.0?

[shancan]

Here's a link to d the download page for earlier versions but read the
instructions and be sure to download the uninstaller first. Uninstall current
version then reinstall the older version. However, I caution you, because of
other posts I see on this forum about uninstall/installs of FlashPlayer...so
reasearch thoroughly!

http://kb.adobe.com/selfservice/viewContent.do?externalId=tn_14266&sliceId=2http
://kb.adobe.com/selfservice/viewContent.do?externalId=tn_14266&sliceId=2

[--MastaShake--]

Yeah I had seen that page, but unfortunately it only has major release versions available, not any dot releases.

[CBT Developer]

[q][i]Originally posted by: [b][b]--MastaShake--[/b][/b][/i]

Is there a link to the v9.0.47.0 flash player? I'd like to have my sales ppl
install this version as a temporary fix.

Is there any dangers with rolling back to v9.0.47.0?

[/q]

Player Archive:
http://kb.adobe.com/selfservice/viewContent.do?externalId=tn_14266

The uninstaller will tell you a newer version is available and prevent the
uninstall... so from cmd go to where you placed the uninstaller and run it with
"/clean" after (no quotes). Then install the older player.

I imagine the only issues would be if you have already developed content using
the functionality now available in the v9.0.115.0 player. You'd lose that when
rolling back.

[CBT Developer]

[q][i]Originally posted by: [b][b]--MastaShake--[/b][/b][/i]

Yeah I had seen that page, but unfortunately it only has major release

versions available, not any dot releases.[/q]

Minor releases are organized in folders inside the .zip files linked to from
that page.

[BWolfe [ADOBE]]

[q][i]Originally posted by: [b][b]--MastaShake--[/b][/b][/i]

Then I have ended up embarrased because, after ensuring that their trusted
paths were added to the security manager and that active content was allowed to
run in IE7 and everything else I have ever known to make this work, I have no
answers for them. I thought I was going crazy. And asking them to use Firefox
would be like asking my mom to use the cmd line.

This is absolutely eating into our schedules, and now I have to QA an enormous
amount of swf content to ensure that all getURL() calls are converted to

ExternalInterface. ([/q]

I understand your pain, and I've represented that to the team. That's about
all I can do.

externalInterface has a bad rap. It's really not that difficult to learn, and
it gives you a number of advantages that getURL just doesn't have.

Someone wrote that "Archived Flash Players available for testing purposes"
(http://www.adobe.com/go/tn_14266) does not contain any minor versions. That is
incorrect. 9.0.47.0 is included there as well as all earlier revisions.

[--MastaShake--]

[q][i]Originally posted by: [b][b]BWolfe [ADOBE][/b][/b][/i]
Someone wrote that "Archived Flash Players available for testin purposes"

(http://www.adobe.com/go/tn_14266) does not contain any minor versions. That is
incorrect. 9.0.47.0 is included there as well as all earlier revisions.

[/q]

Woops I am sorry. I didn't realize that it was a zip file that contained the
minor versions.

[itairaz]

Dear BWolfe,

Though I am not the one to escalate a discussion usually, certainly not in a
newsgroup, this time I'll make an exception.
I'm not a big flash expert. I am a development manager in a company that
relies on flash technology heavily. I have a few flash programmers working in
my team, and a few flash designers working for me on a regular basis.
Now let me tell you a story - One day I bumped into a piece of code that one
of our developers wrote, where they used geturl to call a Javascript function.
Without any knowledge of flash, it looked like sort of a workaround to me. It
just didn't make sense to me that a function called getURL would be used to
call a js function conventionally. I've been told that this is used a lot, all
over our code. I therefore sent one that developer to research and make sure
that usage of geturl for js calls is documented in the official adobe
documentation. My concern was that if this is an undocumented usage of this
function, it will one day vanish off the face of the earth. The developer came
back and showed me that this type of usage is indeed documented in Flash CS3
help files. I felt pretty safe back then.
Now let's think about where this new problem comes into effect. You could
claim that it's just an esoteric issue. Consider the ultra-popular social
platforms like facebook, bebo, myspace, etc. Do you know how you create an
application for these platforms? (hint: it's an iframe). So how many people use
facebook applications out there? I say there are enough to consider this new
problem pretty extensive.

At the bottom line - The new flash player is an embarrassment. Adobe released
a product that instantly breaks thousands of application and websites all
around the world. Now, all of us produce bugs (except for me, of course) and we
all know what software development cycles are, and how painful it is to push a
version out the door. At the same time I really don't understand the statement
which tells me that releasing a flash player takes lot of work. You have a
major major bug, screwing up thousands of your customers, if not millions of
them. My company bought thousands of dollars worth of your product and
established major parts of our software on your Flash platform, thinking that
you are serious enough to take care of us.
If I were in your shoes I would immediately release a new version of the
product, which will simply be an older version with a new number. I would
immediately cease the distribution of the bad version, and work my a** off to
issue a newer version that does not have this geturl bug.

Disappointment.

[MagnifiMag10]

Bentley: I'm CEO of an animation company that uses Adobe's products. I am also
very disappointed to hear that Adobe has no immediate plans to fix this very
serious flaw. It's more than a 'bug' - it's an absolute non-starter. It is now
impossible for us to send out CDs that utilize Flash if the intent is to run
the application locally. The fact that Adobe is now subjecting its developers
to write code to circumvent this problem is like purchasing a car without an
engine and then being told by the manufacturer to figure out how to get around
under our own power. We're not investing in Adobe's products to fix its holes.
We expect them to be fixed ASAP by Adobe. Please escalate this issue to your
upper management. They're running a business and so are we. They must surely
understand this.

[shancan]

MagnifyMag10 You put your thoughts out very politely. I wish I could be as
calm! Because I'm a content author and make my living with this, I have had to
take matters into my own hands. I have exhausted myself this past week using
Camtasia's SWFMP3FIXER application to 'fix' all my .swf files and re-upload to
my site, as well as having to re-master and resend CDs/DVDs that no longer
worked for my customers. The time and expense has been so frustrating. If I
didn't love Adobe's other products so much and if I weren't a stockholder I'd
sue them! I don't know if the Adobe FlashPlayer Techs are so overly genius or
intelligent that it blocks simple common sense! If a can of soup on the
grocercy store shelf is known to cause food poisoning, the manufacturer issues
a recall and the product is removed from the shelf. If Adobe made the soup,
their reaction would be...we're working on a cure for food poisoning and NOT
removing the poison soup from the shelf! This problem has been infecting the
population since December 3, 2007. Two whole months and how much longer will
they wait until they REMOVE IT! Replace it with the previous version, that did
not break content, for goodness sake! One tech replied to another poster here
that they couldn't just put up a fix, that it takes thousands of tests! What a
joke...I guess everyone went on vacation and forgot about that protocol for
version 9.0.115.0! Obviously that was released without intelligent testing!

[fcft]

Have to laugh out loud here... For a company hoping to protect its territory
and expand the use of an end-user plug-in that supports their PAYING CUSTOMERS
- I've seen some baffling moves on the part of Adobe / Macromedia.
ExternalInterface, while superior to getURL, is in no way or form supported on
player versions older than FP8. The suggestion that paying customers simply
update their function calls to use EI is simply ludicrous. getURL, while not as
functional as EI, is compatible with older player versions. The best solution
(to ensure backward compatibility) would be to fire all external calls through
a class or function that takes the detected player version into account for
?Outgoing calls?, enabling a getURL call to host page scripts for FP7 and older
and an External Interface call for FP8+. Many of our customer sites, for
instance, still operate with significant pockets of FP7 ? cutting over to EI
would certainly break things for all of these users. This does not bode well
for the continued acceptance of the Flash player by the mainstream, much less
the development community. And who does this affect? Your paying customers. And
eventually, these mistakes will make their way back into your bottom line. A
staunch supporter and paying customer myself, I am already primed to lean
towards the next big thing and make the leap. Souring your fanbase is just bad
business. This isn?t the first time in the past few years Adobe / Macromedia
has made a decision to restrict functionality that affected their paying
customers, by providing additional options to their player?s end-users. The
security lockdown was a debacle that SHOULD have been resolved by providing an
option to tune down security, not a default lock-down. Why Macromedia made the
decision that all users would benefit from a lockdown of security, therefore
the default will be lockdown, seriously confuses me. Especially when not a
single one of the end-users that Adobe / Macromedia hoped to service with this
'feature' has ever, nor will ever, shell out a single red cent for Adobe /
Macromedia software. Think of your developers first, I beg you...

[shancan]

I purposely installed FlashPlayer 9.0.115.0 on my brand new MacBook Pro (Tiger)
and I can tell you there are issues in ALL of the following Web Browsers:
Safari, Explorer, and Firefox! It breaks the content on .swf files with
mp3soundtrack that were produce via Camtasia Studio 3, &amp; 4. Alien noises
that were not there in any of the previous FlashPlayers are now introduced into
the video in ALL THE ABOVE MENTIONED WEB BROWSERS, not just IE. This occurs
from playing from a CD/DVD or from local drive and viewing movies from a server
online.

[BWolfe [ADOBE]]

All, I appreciate the comments and please feel free to keep them coming. They
are being read by the right people (ie not just me...) In the meantime we did
post a technote to help alleviate the difficulty of spreading the info:
'getURL and navigateToURL issues with Flash Player 9.0.115.0 ActiveX control'
http://www.adobe.com/go/kb403072

[CBT Developer]

[q][i]Originally posted by: [b][b]BWolfe [ADOBE][/b][/b][/i] All, I appreciate

the comments and please feel free to keep them coming. They are being read by
the right people (ie not just me...) In the meantime we did post a technote to

help alleviate the difficulty of spreading the info: &amp;quot;getURL and
navigateToURL issues with Flash Player 9.0.115.0 ActiveX control&amp;quot;
http://www.adobe.com/go/kb403072 [/q] I read the technote, but the first issue
indicates the problem is with Internet Explorer 7 only. This is not the case
since I use both IE7 and IE6 (different systems) and experience the issue with
both versions. There is no cross domain issue since we are literally opening
the browser to a local .htm page that embeds a .swf sitting right next to it.
However, if I do the very same thing - but use my web server (localhost)
directory list to navigate to the .htm file and open, it works fine. My
content does sit inside a frame, but all within the same domain. To the point
of a previous poster... my end-users currently have Flash 7, but we are rolling
out v9.0.47.0 - so until then, using externalInterface is not an option. Even
with the best player out there (v9.0.47.0 NOT v9.0.115.0) there is no way we
are going to rollout modified code for hundreds of training courses that are
currently sitting local in over 5,000 locations. Adobe should be pulling the
release to resolve the issue. But, from the technote it is clear they won't -
now my business partners are throwing around the idea of 'SilverLight'. God
help us all.

[fcft]

Very funny - the same thing is happening here - throwing around 'SilverLight',
where it wasn't a point of discussion before. If this is any indication, Adobe
is on a slippery slope indeed... Best to get closure on this folks... and how.

[BWolfe [ADOBE]]

[q][i]Originally posted by: [b][b]shancan[/b][/b][/i] I purposely installed

FlashPlayer 9.0.115.0 on my brand new MacBook Pro (Tiger) and I can tell you
there are issues in ALL of the following Web Browsers: Safari, Explorer, and
Firefox! It breaks the content on .swf files with mp3soundtrack that were

produce via Camtasia Studio 3, &amp;amp; 4. Alien noises that were not there in

any of the previous FlashPlayers are now introduced into the video in ALL THE
ABOVE MENTIONED WEB BROWSERS, not just IE. This occurs from playing from a

CD/DVD or from local drive and viewing movies from a server online.[/q] This
is an entirely different issue than what we're discussing here. We're aware of
this audio issue and have discussed it with Camtasia... we just don't have a
fix for existing content at this time. When we have more info on this we'll
post it (to another thread)

[BWolfe [ADOBE]]

[q][i]Originally posted by: [b][b]CBT Developer[/b][/b][/i] I read the

technote, but the first issue indicates the problem is with Internet Explorer 7
only. This is not the case since I use both IE7 and IE6 (different systems)
and experience the issue with both versions. There is no cross domain issue
since we are literally opening the browser to a local .htm page that embeds a
.swf sitting right next to it. However, if I do the very same thing - but use
my web server (localhost) directory list to navigate to the .htm file and open,
it works fine. My content does sit inside a frame, but all within the same

domain. To t ghe point of a previous poster... my end-users currently have

Flash 7, but we are rolling out v9.0.47.0 - so until then, using
externalInterface is not an option. Even with the best player out there

(v9.0.47.0 NOT v9.0.115.0) there is no way we areoing to rollout modified code

for hundreds of training courses that are currently sitting local in over 5,000

locations.[/q] I have not been able to make any of my local content tests fail
in IE6. So if you have a failure in IE6 PLEASE open a support case and
provide test files so we can update the bug appropriately. It's possible that
there's some other variation that my test isn't considering. Let me also note
that these issues are injections specific to FP 9.0.115.0. If you're rolling
out 9.0.47.0 you won't have these problems.

[Comedy#MMM]

[fcft]

Oh - come on... Remove the player update already. Please. This is a pretty
serious problem for my shop. We are losing $$$ productivity everytime we can't
run something locally to test, and we lose confidence with the customer (why
did you choose such a squirrelly piece of technology) every time this happens.
How much notification do you need that this is a freaking serious problem
before you pay attention?

Have a nice weekend. We'll post 'again' on monday since I have zero faith that
this will be resolved before then. Pattern repeat next week...

must... resist... looking... into... silver... light...

[emberarc]

[q][i]Originally posted by: [b][b]WhatTheSamHill[/b][/b][/i]
We have developed an application to run online as well as localy. We have used
the getURL method to execute JavaScript functions. Since the release of r115 it
no longer works on our localy run application but continues to work fine on the
online version.

We are not hosting content on seperate domains and so the cross-domain policy
does not come in to play, it is a simple SWF embeded in a HTML page that
contains JavaScript functions. We have "allowScriptAccess" set to "always" and
have updated our security setting to allow the content to run (we have built
several of these apps before) but since the release of r115 it's cactus.

Since there is not an issue of cross-domain policies I am guessing this is a
bug that will fixed soon by Adobe...please. Anybody else had this issue???[/q]

I have a very similar problem. I use Ubuntu Linux 7.10.0 (gutsy), Firefox
2.0.0.12, Flash player 9.0.115.0. My page is http://www.sciforex.hu where the
HTML content is displayed by a getURL() js function call. This is working under
Win XP sp2 in IE7 and Firefox correctly, but when I try to check it out under
Ubuntu, getURL() doesn't call any js functions in Firefox.

[Sofax222]

When can I get the new version of FlashPlayer ?
At least, change the download FlashPlayer back to to the v9.0.47.0 !

[xphysicsguy]

I recently installed Flash Player 9,0,115,0 with IE7 and found similar issues.

I create flash content using Adobe Captivate 3 and have javascripted buttons
that call other html/flash objects. We use javascript to control the called
window. I can only assume based on previous post descriptions that the getURL()
is used in captivate to execute Javascript. I suppose if it used the
recommended EI it shouldn't fail.

As far as I know, I can't modify which method is used in Captivate.

It also appears to break when delivered through our Learning Management
System. I've verified it isn't crossdomain or the other suggested changes
(allowScriptaccess, allownetworking, etc.).

Too bad those thousands of dollars and hours of testing didn't catch this
problem. And too bad it breaks other Adobe applications.

[WhatTheSamHill]

[q]I have not been able to make any of my local content tests fail in IE6. So

if you have a failure in IE6 PLEASE open a support case and provide test files
so we can update the bug appropriately. It's possible that there's some other
variation that my test isn't considering.

Let me also note that these issues are injections specific to FP 9.0.115.0.

If you're rolling out 9.0.47.0 you won't have these problems.[/q]

I previously posted this message and a link to some example files. This will
fail in IE6. The issue seems to be related to framesets. Please download this
BWolfe and test it.

[q]As previously reported the I am experiencing the problem with Flash Player
9 r115 & IE6 sp2 and getURL when trying to execute Javascript on a local file
system.I have discovered the problem exists when running content within a
frameset. All files are running in the same folder on the same drive but getURL
does fail when the page that the flash file is on is run within a frameset. To
see the conclusive evidence download this simple flash file.

http://www.omniap.com/downloads/geturl-flash9r115-240108.zip [/q]

I have another idea for Adobe if they are not going to release a fixed version
of the Flash Player, why not just re-release 9r47 and cunningly call it 9r116.
I'm dead serious. That way if our projects do not work we can advise our
clients to upgrade there player version rather than re-working several projects
or explaining the process of rolling back there player version. Maybe Adobe
should have done this as soon as they realised r115 had so many problems and
was costing their customer base so many $s.

Thanks,
Sam

[Troubleatmill]

It is costing my company untold $ as we cannot release our product to the
market and this has been delayed for 2 months now. It is an audio application.
It works perfectly unless you have 115.0 then it is highly unstable. As this is
a global consumer product for the music industry it is a complete disaster. We
cannot even do a closed beta. We are tearing out hair out.

I cannot believe that Adobe have not fixed this and it is nearly 3 months

[Troubleatmill]

[--MastaShake--]

[q][i]Originally posted by: [b][b]Troubleatmill[/b][/b][/i]

It is costing my company untold $ as we cannot release our product to the
market and this has been delayed for 2 months now. It is an audio application.
It works perfectly unless you have 115.0 then it is highly unstable. As this is
a global consumer product for the music industry it is a complete disaster. We

cannot even do a closed beta. We are tearing out hair out.[/q]

Troubleatmill, Are there other things that are causing the unstability of your
application when it is ran in v115, besides the getURL calls? Please let us
know what those "other" bugs are, as they should be brought to light.

Otherwise, if you are delaying a major application that your company is
relying on because of some getURL's not working, just go change them to
ExternalInterface calls. I realize that a large app may have hundreds of getURL
calls but surely it wouldn't take THAT long to replace them all.

I wish you the best!

[CBT Developer]

I don't know specifically about Troubleatmill's issue(s), but I do know that
externalInterface has a boat load of problems on its own - look at livedocs for
many of them. Using externalInterface could open a can of worms.

For me externalInterface is not an option and gets me in a catch-22. I need
to build code using features available in the newest players (r9.0.42.0 and
up), but can't until our end-users have the newest player - most currently have
r7, but we do directly control the player installed for 90% of those users.
However, I can't roll out the new player, because doing so will break existing
content (that uses getURL). That equates to hundreds of courses (CBTs) - all
of which would need upgraded to use externalInterface BEFORE allowing a roll
out of the new player. However, I can't upgrade even one of those courses now,
because 90% of those users still have r7 which doesn't support
externalInterface at all.

The workaround (because we - for the most part - can control what player is
installed for the user) is to roll out r9.0.47.0 which doesn't have an issue
with either getURL or externalInterface... then I can use the new features
available in the new players (except for r9.0.115.0) in all my new content, and
leave my old content alone until - I hope - Adobe resolves the issue in the
next build of the player. Otherwise, I'll have to then begin the long
processes of upgrading old content to externalInterface, and rolling out that
content again to all of our end points before continuing with any player
upgrades past r9.0.47.0.

The issue then remains with the other 10% of our users, who have already begun
to upgrade the player on their own. To the average - simple - user, you cannot
rollback the player because you get the annoying "There's a newer player
available." message (resolved with the "/clean" param during uninstall).
Unless we individually walk through the process with each user (about 4,000
users in that category), we'll need to create a package that handles this
rollback, and prevent reinstall of r9.0.115.0 later.

I agree with a previous poster, that Adobe in all its hundreds (if not
thousands) of hours spent testing - should have discovered the getURL issue and
resolved it before release of the player. But even so, now that it is out,
they should patch it with a new release or minimally re-release r9.0.47.0 under
a new build number. This should be done NOW so the number of users negatively
affected by the removal of new features only available in r9.0.115.0 is at a
minimum. The value added from the previous player to this one is not
substantial - so there is no reason why this issue cannot be resolved now.

Bring back Macromedia!

[WhatTheSamHill]

This is unecassary rework that we as the client should not be footing the bill
for. Any change to a large application means that it has to go through testing
again. ExternalInterface is only supported by versions 8+ of the player I
believe, meaning you then have to detect the player version and present two
different versions of the application based on their player version.

[WhatTheSamHill]

Come on Adobe, its all gone very quiet over there. As time goes by we are
finding the problems with getURL are effecting more and more of our online
courses. We use getURL extensively with Flash as our courses are deployed to
SCORM compliant LMSs. Please stop allowing people to upgrade to this buggy
piece of software and start acting like you care.

[murrang]

Agreed Adobe is dramatically effecting customer relations on this one. Some
kind of official statement is required to explain the mess up. Is this
functionality related to Air that is causing the problem with getURL() local?
Most companies affected have too much invested to simply change every piece of
code at the drop of a hat.

[BWolfe [ADOBE]]

[q][i]Originally posted by: [b][b]murrang[/b][/b][/i]
Agreed Adobe is dramatically damaging customer relations on this one. Some

kind of official statement is required to explain the mess up. Is this

functionality related to Air that is causing the problem? Most companies
affected have too much invested to simply change everything to Flash 8 methods
at the drop of a hat.[/q]

The official statement is in this technote:

"getURL and navigateToURL issues with Flash Player 9.0.115.0 ActiveX control"

( http://www.adobe.com/go/kb403072).

As the technote says, this will be addressed in an upcoming update to Flash
Player. That is all I can say at this time.

[sychronicity]

[q][i]Originally posted by: [b][b]BWolfe [ADOBE][/b][/b][/i]

[Q][I]Originally posted by: [B][B]murrang[/B][/B][/I]

Agreed Adobe is dramatically damaging customer relations on this one. Some
kind of official statement is required to explain the mess up. Is this
functionality related to Air that is causing the problem? Most companies
affected have too much invested to simply change everything to Flash 8 methods

at the drop of a hat.[/Q]

The official statement is in this technote:
"getURL and navigateToURL issues with Flash Player 9.0.115.0 ActiveX control"
( http://www.adobe.com/go/kb403072).

As the technote says, this will be addressed in an upcoming update to Flash
Player. That is all I can say at this time.

[/q]

Your link doesn't wok, Mr. Wolfe, I think you mean this:
http://www.adobe.com/go/kb403072

[BWolfe [ADOBE]]

Thanks, fixed now. That habit of putting a parenthesis at the end catches me out all the time on these forums :(

[NagRock]

Hi,

what should I do if I publish content for flash player 7, so I can't use ExternalInterface but it also must work on Flash Player 9.0.115.0 ?

[BWolfe [ADOBE]]

All,

This local getURL issues is fixed in Flash Player 9.0.124.0. I've updated

"getURL and navigateToURL issues with Flash Player 9.0.115.0 ActiveX control

(Windows)" (http://www.adobe.com/go/kb403072) accordingly.

[CBT Developer]

[q][i]Originally posted by: [b][b]BWolfe [ADOBE][/b][/b][/i]

All,

This local getURL issues is fixed in Flash Player 9.0.124.0. I've updated
"getURL and navigateToURL issues with Flash Player 9.0.115.0 ActiveX control

(Windows)" (http://www.adobe.com/go/kb403072) accordingly.[/q]

I haven't tried the new player yet - but will shortly. Thanks for all your
help!

We've got to break you of the URLs in "( )" habit... the link is
http://www.adobe.com/go/kb403072

[BWolfe [ADOBE]]

"We've got to break you of the URLs in "( )" habit...:

personally I'd prefer that fusetalk be less dumb about it's URL's. After all
this time I don't seem to be able to break the trailing paren habit...

[mydognacho]

I have an issue that seems to be related. We have a Flash tool which resize
it's height based on it's content.

http://lexusofdanversma.redlinecontent.com/Pages/Page.cfm?pageID=118873

Problem is that one of our clients is framing this page using the iframe tag
on another one of their sites:
http://www.lexusofdanversma.com/menu_Build_A_Lexus_3315

If you view the first link, you'll see that the resize works perfectly.
However, when the page is viewed from within an iframe the resize doesn't
appear to work. The Flash movie is making a getURL call as below:

getURL("javascript:newSize(" + Number(JSnewheight + footer.disclaimer._height
+ 25 + header._height) + ")","_self");

You can see the JS function on the actual page itself. I've tried everything I
can think of but nothing appears to fix this problem. Flash doesn't even make
the JS function call.

I can't find anything online that seems to indicate this is a problem. Does
anyone in this topic have any ideas?

[WebmasterBlog]

For me works fine only with Flash Player 9.0.124.0.