History | Log In     View a printable version of the current page.  
Issue Details (XML)

Key: SDK-12987
Type: Minor Enhancement Minor Enhancement
Status: Closed Closed
Resolution: External
Priority: C C
Assignee: Joan Lafferty
Reporter: Jason The Saj
Votes: 9
Watchers: 8
Operations

If you were logged in you would be able to see more operations.
Flex SDK

Alternative to "navigateToUrl" & "ExternalInterface.call(WINDOW_OPEN_FUNCTION"

Created: 10/10/07 01:10 PM   Updated: Wednesday 03:17 PM
Component/s: Unspecified - App Model
Security Level: Public (All JIRA Users )

File Attachments: 1. Zip Archive extlink.zip (469 kb)


Severity: Incorrectly Functioning
Reproducibility: Every Time
Discoverability: High
Found in Version: SDK Moxie M3 (Beta 2)
Affected OS(s): Mac - OS 10.4
Steps to Reproduce:
Steps to reproduce:

Using either during an "Click" triggered event:
 
navigateToURL(new URLRequest("http://http://www.adobe.com/"), "_blank");

OR

externalInterface.call(WINDOW_OPEN_FUNCTION, "http://http://www.adobe.com/", window, features);
 
 Actual Results:

  First, navigateToURL gets caught by pop-up blockers (unsatisfactory). Where as the externalInterface call works if the Flash .swf is embedded with "allowScriptAccess = 'always'". If not, then it fails to respond. Often the case I do not have control of the hosting environment or the .swf is being pulled via an automated plugin code. Settings "allowScriptAccess='always'" is not an option. That relegates me to navigateToURL which fails due to pop-up blocking.

 Expected Results:
 
I expect when a user clicks on a link to be able to pop out a new browser. At least with a user initiated activity.
 
So neither provides a truly viable option. Think you guys can do something about it for Flex 3? This was not an issue with AS2/Flash. So I view this as a regression.
 
Language Found: English
Bugbase Id: none
Triaged: Yes
Regression: No
QA Owner: Joan Lafferty
Resolved by: Joan Lafferty
Participants: Dean Moses, Jason Epperson, Jason The Saj, Joan Lafferty, Lauren Park, Leo Lee, michael holt and Mike
Browser: Firefox 2.x


 All   Comments      Sort Order:
Joan Lafferty - [11/07/07 05:13 AM - edited ]
this problem is only a issue on Firefox (as far as I can tell). According to the player team, this is related to a Firefox bug where our Actionscript for instance,

on (release) { getURL("http://www.badgerbadgerbadger.com", "_blank"); }

works, but

on (press) { getURL("http://www.badgerbadgerbadger.com", "_blank"); }

does not work.

I'll send this bug for internal review to see if there is something we can change (with low impact) on our click event handlers for Button so that simple code like:

<mx:Button click="navigateToURL(new URLRequest('http://www.adobe.com/'), '_blank');" label="open" />

would work in Firefox.

Lauren Park - [11/13/07 04:21 PM ]
Deferred.

Joan Lafferty - [11/14/07 06:35 AM ]
Actually, I think that this is a Fact of Life until Firefox fixes a bug that doesn't allow this to work. Developers will need to keep using ExternalInterface to call Javascript's window.open() method to get this to work.

Closing bug.

Jason Epperson - [01/17/08 03:42 PM ]
No, not a fact of life...

a) externalinterface is not accessible if the .swf is embedded without allowScriptAccess rights. Guess what, not always do we the coders have access to the hosting environment. Thus the workaround is useless in these circumstances.

b) _getURL did NOT have this problem in any where near the level that navigateToURL does. So can we resort back to that? Please...

I REALLY HATE having to re-write applications I've written in Flex in Flash 7 because of this issue.

Jason Epperson - [01/17/08 04:34 PM ]
Also the work-a-round no longer appears to be working in Safari. Perhaps this is due to the update to Safari 3.

I'm providing a link to test. Can you verify if it works for you...
http://staging.nxtbook.com/fx/clients/nxtbook/dev/jason/extlink/test.html

It works for me in Firefox but not in Safari 3. You can view source, so if there is something that is preventing Safari 3 from working in the code. Please let me know.

This now raises the issue to a much much more critical level. Please re-open issue or provide a better work-a-round!



Jason The Saj - [01/21/08 10:58 AM ]
Example...

Leo Lee - [01/21/08 01:53 PM ]
Multiple people have commented that, the workaround of calling window.open using ExternalInterface is not working with FireFox 2.0.0.11 and flash player 9.0.115.

http://flexgraphix.com/blog/?p=16
http://skovalyov.blogspot.com/2007/01/how-to-prevent-pop-up-blocking-in.html

Leo Lee - [01/21/08 01:55 PM ]
I wish the priority level would be higher on this issue. Not being able to reliably launch user initiated links in new windows is a big issue for our web-applications.

Dean Moses - [02/01/08 12:57 PM ]
This is a major, major issue for all widget developers and widget companies. Our businesses are founded on widgets that don't live on our site: ExternalInterface is not an option.

None of us can move to Flash 9 because we can't reliably open windows. Firefox is a platform that has to work!

Mike - [02/01/08 02:26 PM ]
This is indeed an issue that needs to be addressed very soon. It would also be nice if navigateToURL had a callback as false if the procedure failed.

Jason The Saj - [02/07/08 07:55 AM ]
You know, I am getting so annoyed with this stupid navigateToURL() issue. I just want to be able to open up a link in a new browser window. That shouldn't be an ongoing nightmare.

:-(

So close, but still no cigar...

Started with Firefox pop-up blocker. So I switched to the externalInterface method. That worked, but then Safari 3 came out, and it now longer worked with the method. So I modified it again - which in turn broke Safari 2. I have since modified and refined it further...now I am getting a pop-up blocker in IE. (I think because it doesn't like the conditional logic being used on the click.)

*blargh*

Here I am, wasting all this time on what Adobe should already have done. Not happy.

***

I'm starting to get royally PIEVED OFF!!!

I should be developing our application, not developing multiple work-a-rounds for the Flex framework's failure!!!

And you guys won't even acknowledge this is a bug. (Outside of being a Firefox bug.) And if it is a Firefox bug, well they're an open source project. How about Adobe drop $100,000 donation to Mozilla to fix the issue in Firefox.




michael holt - [02/13/08 10:42 AM ]
Every reference to the navigateToURL getting caught by the pop-up blocker seems to imply it only happens in Firefox. So I must ask: What I am doing so special that I am having the problem in IE as well?

I am using a DataGrid with an itemClick function.

<mx:DataGrid id="dgData" x="0" y="20"
width="100%" height="100%"
dataProvider="{transactionRequest.lastResult.mydata}"
itemClick="goto_somewhereelse(event)"
alternatingItemColors="[#bfdfff, #ffffff]"
>

private function goto_somewhereelse(event:ListEvent):void
{
if(event.rowIndex.valueOf() > 0)
{
var urlRequest:URLRequest = new URLRequest();
urlRequest.url = "http://www.somewhereelse.com?myid=" + dgData.selectedItem.my_id;
flash.net.navigateToURL(urlRequest,"_blank");
}
}

Jason The Saj - [02/13/08 10:50 AM ]
Hi Michael,

Are you using SWFObject, recently I've traced the IE pop-up to only be occurring while using SWFObject.

I've done quite a bit of experimentation on this issue - still no full resolution. Can I say weeks of development time for my company lost on an issue Adobe is pretty much ignoring. But you can follow my results and examples here.

http://thesaj.wordpress.com/2008/01/24/the-nightmare-that-is-_blank-flex/

Also, here are three examples embedding the same .swf, demonstrating when the IE pop-up occurs.

http://thesaj.wordpress.com/2008/02/12/the-nightmare-that-is-_blank-part-ii-help/

If anyone has some insights, please let us know!

Jason The Saj - [02/13/08 02:41 PM ]
After further research, the issue was NOT with SWFObject, but rather caused by a particular parameter entry:

wmode="transparent" causes IE to pop-up block.

I have posted a solution on my blog. I have tested it on XP in IE, Firefox, Safari 3, Opera and on OSX in Firefox, Safari 3, Safari 2

http://thesaj.wordpress.com/2008/02/12/the-nightmare-that-is-_blank-part-ii-help/

Exceptions:
1. Requires use of "allowScriptAccess"
2. Fails in IE when wmode property = "transparent"

So there we have it, a solution for most instances for most browsers - no thanks to Adobe!

michael holt - [02/13/08 02:47 PM ]
Thank you for the help Jason. I have found a work-around based upon your code. I made on modification and now it works in IE and Firefox when wmode is set to window, opaque, or transparent. I modified the openWindow function to:

private function openWindow(my_earl:String, window:String = "_blank", features:String = "") : void
{
var WINDOW_OPEN_FUNCTION:String = "window.open";

if(getBrowserName() == "Firefox")
{
ExternalInterface.call(WINDOW_OPEN_FUNCTION, my_earl, window, features);
}
else
{
ExternalInterface.call("function setWMWindow() {window.open('" + my_earl + "');}");;
}
}

Jason The Saj - [02/13/08 03:49 PM ]
One issue I ran into is that Safari wasn't responding to:

else
{
ExternalInterface.call("function setWMWindow() {window.open('" + my_earl + "');}");;
}

So I was going to place the code just for IE. However, I've discovered that IE is no longer returning browserAgent info to my code. It was last week. And IE 7 does. But IE6 is no longer doing so, I am worried that the new IE6 security update I just ran this morning might have affected something.

Jason The Saj - [03/05/08 11:47 AM ]
I've since updated the example:

I successfully tested it on IE6 (PC), Firefox 2 (PC/Mac), Safari 2 (Mac), Safari 3 (Mac/PC), Opera 9 (PC)
http://www.easternstorm.net/sassie/example2/example2.html

A few caveats, if you are using SWFObject 2.0, make sure you've upgraded to RC2. Also, the wmode parameter must be set to either "opaque" or "transparent" to work in all browsers.

***
Not a perfect solution, and a bit cumbersome...but it's finally getting the job done in most cases.

(Exception, we still have no solution for when you don't have control over the .swf embed environment and are unable to have allowScriptAccess = "always". Really would be nice to see Adobe step up to the plate on this one. Maybe hopefully come Flex 4 sometime in late 2009 this issue will be resolved.)

Jason The Saj - [05/13/08 03:04 PM ]
Thank you Adobe for re-opening this issue!

Joan Lafferty - [05/13/08 04:45 PM ]
This is a player bug. It was fixed by the player team for Windows as of their last player 9 update. So, if you have player 9,0,124, navigateToURL should work w/o getting blocked by the popUp blocker. I have verified this. Flash player bug references are #216592 and #215584.

When I tried this on Mac, I found that the bug still existed, so, I have filed a new flash player bug. Reference #225434.

Jason The Saj - [05/14/08 03:17 PM ]
I tested in Mac, it worked on the first click but then would be blocked on subsequent. After several tests it seems to just be blocked now.

I had a co-worker test on Firefox in Linux, he too was blocked.


Safari 2, Safari 3, and Opera were all fine on Mac.
IE6, Firefox, Safari 3 were all fine on Windows XP.

So the issue appears to be limited to Firefox on OS X & Linux. (Unix code versions.)

Hope that helps! Thank you so much Joan for following up and being diligent with this.

:-)

This is definitely a significant improvement.