Opened 8 years ago

Closed 7 years ago

Last modified 7 years ago

#52 closed defect (fixed)

Flickering http://www.speedtest.net/ - unusable

Reported by: Michaelhz Owned by:
Priority: major Milestone: 0.4.0
Component: wrapper Version:
Severity: high Keywords:
Cc:

Description

Hi,

checking ISP-connetction with http://www.speedtest.net/ does not work. The different views of the application are displayed in sequence, without the corresponding program steps are performed.

Change History (30)

comment:1 Changed 7 years ago by Silvan Scherrer

Milestone: Next0.3.3

comment:2 Changed 7 years ago by Silvan Scherrer

Severity: high

comment:3 Changed 7 years ago by dmik

This is a very good testcase, it reveals several problems. In particular, I get this:

SecurityError: Error #2060: Security sandbox violation: ExternalInterface caller http://c.speedtest.net/flash/speedtest.swf?v=307120 cannot access <unknown>.
	at flash.external::ExternalInterface$/_evalJS()
	at flash.external::ExternalInterface$/call()
	at _-3k::ExternalMouseWheelSupport/_-BQ()
	at _-3k::ExternalMouseWheelSupport()
	at _-3k::ExternalMouseWheelSupport$/getInstance()
	at DocumentClass()

I guess the reason of the problem is the same as in #34.

I'm working on this issue now. I think we must fix it before the release as it seems to be quite common.

comment:4 Changed 7 years ago by dmik

It seems that this fails just right after attempting to check Firefox too (see #34, comment 9.

comment:5 Changed 7 years ago by dmik

No, as in case of #34, this assumption seems to be wrong. My current guess is that something is missing in the environment (registry, or some file). I found a couple of cases in Google where this error (specifically saying "cannot access <unknown>") is fixed by reinstalling Flash on the user's (Windows) machine.

comment:7 Changed 7 years ago by dmik

JFYI. I've set up Adobe Flash Builder so that I can write test SWF and try to find the problem from this end. I want to reproduce the failing case using the ActionScript? source code I can control/debug.

comment:8 Changed 7 years ago by dmik

I found a simple test case that produces the same error #2060: http://kiks.yandex.ru/system/fc06.swf. Here's the error:

SecurityError: Error #2060: Security sandbox violation: ExternalInterface caller http://kiks.yandex.ru/system/fc06.swf cannot access <unknown>.
	at flash.external::ExternalInterface$/_initJS()
	at flash.external::ExternalInterface$/addCallback()
	at FlashCookie()

Trying to "disassemble" this file.

comment:9 Changed 7 years ago by dmik

Some more findings. I can get the exact error #2060 as above if I run a test SWF locally with an ExternalInterface.addCallback(...) call in it AND I don't have the directory containing the SWF in the list of trusted locations in global Flash settings. Once I mark this directory as trusted, the error goes away. In case when the SWF is located on the network resource, security is controlled by the param of the embed object named "allowScriptAccess" in the embedding HTML file (or in a special HTTP server settings file). Obviously, all tested HTML files have a correct setting for this param ("always" or "sameDomain") which is not a surprise since it would not work on other platforms too otherwise. Given that, my guess is that for some reason the Flash plugin mistakenly treats the SWF from the network as if it were the local one. I will try to think in this direction.

Another finding is that this ExternalInterface? thing doesn't seem to work at all here. At least, the ExternalInterface.call("fooBar") method always returns null under OS/2 (i.e. as if there were no "fooBar" method defined in the containing HTML) while the very same HTML + SWF works perfectly on Windows. This needs investigation too.

So we have at least something.

comment:10 Changed 7 years ago by dmik

JFYI, found a great site and it successfully disassembled the above SWF (fc06.swf). The site is http://www.showmycode.com. The code is:

package {
    import flash.events.*;
    import flash.display.*;
    import flash.net.*;
    import flash.system.*;
    import flash.external.*;
 
    public class FlashCookie extends Sprite {
 
        private var listDomains:array;
        private var so:sharedobject;
        private var listSubDomains:array;
 
        public function FlashCookie(){
            var _local2:string;
            var _local3:string;
            listDomains = ["yandex.ru", "yandex.ua", "yandex.kz", "yandex.by", "yandex.com", "moikrug.ru"];
            listSubDomains = ["kiks"];
            super();
            var _local1:sharedobject = sharedobject.getlocal("fuid01", "/");
            _local1.addEventListener(AsyncErrorEvent.ASYNC_ERROR, asyncErrorHandler);
            _local1.addEventListener(NetStatusEvent.NET_STATUS, netStatusHandler);
            for each (_local2 in listDomains) {
                Security.allowdomain(_local2);
                for each (_local3 in listSubDomains) {
                    Security.allowdomain(((_local3 + ".") + _local2));
                };
            };
            ExternalInterface.addCallback("setLocation", setLocation);
            ExternalInterface.call("requestData");
            _local1.close();
        }
        private function createIframe():void{
            ExternalInterface.call("getIFrame", "yandex.ru");
        }
        private function setLocation(_arg1:string, _arg2:string):void{
            var domain:* = _arg1;
            var cookie:* = _arg2;
            var so:* = sharedobject.getlocal("fuid01", "/");
            var soValue:* = so.data.fyandexuid;
            domain = domain.tolowercase();
            if (((soValue) && ((soValue.length > 0)))){
                if (soValue != cookie){
                    ExternalInterface.call("setCookie", soValue);
                };
            } else {
                if (((((cookie) && ((cookie.length > 0)))) && ((domain == "yandex.ru")))){
                    so.data.fyandexuid = cookie;
                    try {
                        so.flush();
                    } catch(e) {
                    };
                };
            };
            so.close();
            if (domain != "yandex.ru"){
                createIframe();
            };
        }
        private function netStatusHandler(_arg1:NetStatusEvent):void{
        }
        private function asyncErrorHandler(_arg1:AsyncErrorEvent):void{
        }
 
    }
}//package

We can see here the same ExternalInteface? calls which (according to other tests) don't work on OS/2. The reason why it throws an exception instead of silently failing (as in simple tests) may be that the Security class (which sets up domain allowance) doesn't work either.

comment:11 Changed 7 years ago by dmik

Here's a good example that demonstrates the two-way JS - AS communication and it fully demonstrates that both ways are broken on OS/2. The symptoms are completely equivalent to what we see in other non working cases, so it's definitely it.

comment:12 Changed 7 years ago by dmik

I'm starting to suspect that something related to the ExternalInterface? implementation is broken in the OS/2 build of Firefox as the JavaScript? engine is provided by Firefox (while ActionScript? is provide by the Win32 Flash DLL so it's definitely equal to Windows). This would explain why I don't see any symptoms of the problem in the Odin logs -- Firefox is a native application that doesn't use it for its own needs.

I will have to download and build Firefox by hand. I know who to ask if I'm stuck (Dave Yeo).

comment:13 Changed 7 years ago by dmik

Autoconf is hell. I somehow managed to generate configure with a newer autoconf I had and even almost built it but then I discovered that makefiles were wrong; I found out that only autoconf 2.13 is OK for mozilla. The next problem is that it wants pdksh... It was almost fine with ash when it came out that mozilla stuff depends on the echo -E functionality which is missing in ash. Now, after switching to pdksh I got a bunch of other problems. E.g. it can't find the C++ compiler now.

Autoconf is hell.

comment:14 Changed 7 years ago by dmik

Ok, I got the C++ problem. pdksh doesn't understand symlinks. So it can't be used in the RPM-managed environment. I will go for ash again and just manually hack configure to remove all 'echo -E' crap. Since I have to manually fix configure anyway after autoconf which creates really weird EOLs (0x0D 0x0D 0x0A -- the result of reading the file as binary and writing it back as text I suppose which may be a bug of some recent gawk or sed or whatever), it's not a big deal.

comment:15 Changed 7 years ago by dmik

Some other weird bug somewhere: test -s on a just generated object file (one of the conftests) doesn't work (returns non-zero). Doing the same from a separate shell script works fine. Looks like some file cache issue... (this happens on JFS) Fixed by adding 'ls' before 'test'. All is really weird but I don't care.

Last edited 7 years ago by dmik (previous) (diff)

comment:16 Changed 7 years ago by dmik

Latest findings. The other failure was due to RANLIB=ranlib (surprise!) in my setup. Turns out you have to set it to 'echo' to make it work since ranlib can't work with OMF on OS/2 (and makes no sense). I wonder why they didn't fix it in configure.

The 0x0D 0x0D 0x0A problem is related to gawk 4.0.0 installed from RPM (libc build). gawk 3.0.4 from MozTools?'2007 (EMX build) works fine.

comment:17 Changed 7 years ago by dmik

Okay, the cause for the 'test -s' problem is also found: it's the combination of the -pipe gcc option and redirecting stdout to stderr with 1>&2. My wild guess is that sh (which manages redirection) somehow doesn't close some stream at a time and this causes 'test' to fail. The workaround is to remove the -pipe option (should be harmless as it only defines the method of communication between various gcc executables).

comment:18 Changed 7 years ago by dmik

BTW, pdksh is free from this problem, so it's definitely a bug of our RPM ash build. Here's a simple test case which reveals it:

ac_n=
ac_c=
ac_t=
ac_ext=c
CC=gcc
OBJ_SUFFIX=o
ac_exeext=.exe
CFLAGS='-fno-strict-aliasing -Zomf -pipe'


echo $ac_n "checking what kind of list files are supported by the linker""... $ac_c" 
echo "configure:22732: checking what kind of list files are supported by the linker" 
if eval "test \"`echo '$''{'EXPAND_LIBS_LIST_STYLE'+set}'`\" = set"; then
  echo $ac_n "(cached) $ac_c" 
else
  echo "int main() {return 0;}" > conftest.${ac_ext}
     if { ac_try='${CC-cc} -o conftest.${OBJ_SUFFIX} -c $CFLAGS $CPPFLAGS conftest.${ac_ext} 1>&2'; { (eval echo configure:22737: \"$ac_try\") ; (eval $ac_try) ; }; } && test -s conftest.${OBJ_SUFFIX}; then
         echo "INPUT(conftest.${OBJ_SUFFIX})" > conftest.list
         if { ac_try='${CC-cc} -o conftest${ac_exeext} $LDFLAGS conftest.list $LIBS 1>&2'; { (eval echo configure:22739: \"$ac_try\") ; (eval $ac_try) ; }; } && test -s conftest${ac_exeext}; then
             EXPAND_LIBS_LIST_STYLE=linkerscript
         else
             echo "conftest.${OBJ_SUFFIX}" > conftest.list
             if ({ ac_try='${CC-cc} -o conftest${ac_exeext} $LDFLAGS @conftest.list $LIBS 1>&2'; { (eval echo configure:22743: \"$ac_try\") ; (eval $ac_try) ; }; } ||
                 { ac_try='${CC-cc} -o conftest${ac_exeext} $CFLAGS $LDFLAGS @conftest.list $LIBS 1>&2'; { (eval echo configure:22744: \"$ac_try\") ; (eval $ac_try) ; }; }) && test -s conftest${ac_exeext}; then
                 EXPAND_LIBS_LIST_STYLE=list
             else
                 EXPAND_LIBS_LIST_STYLE=none
             fi
         fi
     else
                  { echo "configure: error: couldn't compile a simple C file" ; exit 1; }
     fi
     rm -rf conftest*
fi

echo "$ac_t""$EXPAND_LIBS_LIST_STYLE" 

comment:19 Changed 7 years ago by abwillis

You are probably running into the grep problem in libffi:
https://bugzilla.mozilla.org/show_bug.cgi?id=538002#c1
set grep=x:\usr\bin\grep.exe
I had forgotten this as I only built a few times with libffi. I have to do that sometimes when building other applications. Configure in libffi is built with autoconf 2.63 and as my mozilla environment is using 2.13 I haven't looked to see if it is easily fixed there.

comment:20 Changed 7 years ago by abwillis

set GREP=grep is enough, doesn't require full path

comment:21 Changed 7 years ago by dmik

No grep was not my problem. All that I described above was.

Anyway, my first FFox (10.0.10) is finally built (I'm actually writing this comment from it)! Within our current RPM build environment which is also very good (especially in terms of building the mozilla RPM).

Now I may debug the JS code in it.

comment:22 Changed 7 years ago by abwillis

Just installed Flash 11.5 and speedtest.net is now working (did not previously here either).

comment:23 Changed 7 years ago by dmik

Built the debug version of Firefox here (for debugging JS) but it crashes in XUL.DLL. Nice!

comment:24 Changed 7 years ago by abwillis

There happens to be some discussion of debug in the Warpzilla newsgroup.
https://groups.google.com/d/msg/mozilla.dev.ports.os2/Y5xg8hCJ0Tc/VtD2VzSmHj8J
Starting about here in the thread.

comment:25 Changed 7 years ago by dmik

Okay, I found the reason why ExternalInterface? doesn't work. Firefox asks if the plugin supports this interface by calling NPP_GetValue() on its instance with code 15 (NPPVpluginScriptableNPObject) but our wrapper doesn't know this code and it always returns NPERR_GENERIC_ERROR instead of passing this call to the plugin (It does so for all unknown codes because returned values may potentially require custom marshaling which will translate between Win32 and OS/2 types and structures).

According to https://developer.mozilla.org/en-US/docs/Gecko_Plugin_API_Reference/Scripting_plugins, Values of NPPVpluginScriptableNPObject are NPObject's. I will check now what sort of marshaling is required for them and will try to implement it.

Regarding Flash 11.5, I will check it later. I wonder how you got it working, for me it didn't want to run even simple test SWF. (Or was it 11.4?)

comment:26 Changed 7 years ago by abwillis

11.3 is the only one I have had problems with... and that was audio as I recall. I did have some issues with 11.5 crashing the browser occasionally but nothing I could recreate reliably.

comment:27 Changed 7 years ago by abwillis

They either changed the page or 11.5 ended up cleaning something else up as now I can go to 11.4 or 11.2 and the page works fine.

comment:28 Changed 7 years ago by dmik

The problem is more complex than it first appeared. I created #69 for it and will continue there.

comment:29 Changed 7 years ago by Silvan Scherrer

Resolution: fixed
Status: newclosed

as this test now works great with flash 0.3.2 and win plugin 11.2 i guess we can safely close it. we have enough other test flash which do not work.
for me it seems they changed the way the flash works.

comment:30 Changed 7 years ago by dmik

JFYI, this now fully works after doing #69, with the recent Flash etc.

Note: See TracTickets for help on using tickets.