Applet's in browser, slow loading, remote and (in some bright future) graphical testing and some minor improvements (was Re: Icedtea-web splashscreen implementation)

[Pavel Tisnovsky]

Jiri Vanek wrote:
> On 03/12/2012 12:11 PM, Pavel Tisnovsky wrote:
>> Hi Jiri,
>>
>> I'd like to comment the last patch with new test framework functionality:
>>
>> 1) the idea of adding some delay to see/test splashscreen is great,
>> but is not
>>     it better to add some annotation to such tests instead of using
>> "magic" test name?
>>     Similar functionality is used in JTreg tests (not "true"
>> annotations, but similar approach).
>>     I'm sure we'll need to add more per-test parameters in the future.
> 
> hmhm interesting idea, but I need to specify this inside JNLP file or
> inside applet tag in html file. And I wanted to lunch it outside the
> engine.... Have you any clue how to do this with annotation?

Yes, you can AFAIK use "property" tag in JNLP file. It contains "name"
and "value" and this pair should be available through System.getProperty()
(there probably exist tests which check this functionality :-)

So we could prepare a list of some properties used by the test machinery.

>>
>> 2) some notes to the patch:
>>
> Indentation - Damn this:-/ I was doublechecking this across all the
> files :-/
>> tests/netx/jnlp_testsengine/net/sourceforge/jnlp/ResourcesTest.java:
>> - seems there's a bad indentation for the last 11 lines
> ..not found...??
>> tests/netx/jnlp_testsengine/net/sourceforge/jnlp/ServerAccess.java
>> - bad indentation in a method getIndependentInstance()
> fixed
>> - -//- for executeJavawsHeadless
> fixed
>> - -//- executeJavaws, executeBrowser
> fixed
> 
> 
> And concept of  executeBrowser and listeners at all?
> Is it worthy to continue this way? What about "firefox" issue?
> And posted testcases? Especially the applet in browser one? And change
> in main method? And issue with link?

Well it's focused to test Firefox only at this moment, but I think
that we can start with your solution and then update it to support Chrome
etc. etc. (it should be easy IMHO).

> 
> The issue with link and with browser is quit fundamental and I'm not
> sure how to continue with it. There is -Dvariable for setting up bowser,
> but it do not solve anything at all :( And the link issue is even more
> tricky with various (means supported x the testing one)  browsers. Or
> should ve be happy with firefox? Or should this test to be
> multi-browsers? (== during each run, each html test wil be lunched in
> all possibel browser [I do not believe this is worthy, but recent
> regression on chromium shows differently])

But why not? After all the number of browsers supported is still quite small (er Opera er ;-)

> 
> Although I have posted this in-browser tests as proof-of concept, there
> is already need for applets tests so I'm for to push it in, because
> abstraction, as it is written, is quite enough and improvements can be
> done in "runtime".

I agree.

> 
>> - -//- splitArray (it needs JavaDoc
> definitely. Sorry for forgot it.
> too, contains double ";;" on one line etc.)
> damn. YY - fixed
>>    I think it could be simplified to use one loop only and two index
>> variables
>>    (we can talk about this personally)
> Can it? Make your shot! O:) Btw  - I have *one* loop, tehn second O:)
> for copyying of aray (As I'm not friend of copyarray method :( ) and
> *one* index, but yes, the header of method is not nice. But it was still
> fighting with me:-/ Make your shot!
will send :-)
>
>> - I'm probably wrong but is seems that all applet/jnlp tests are using
>> only "localhost" network interface.
>> If it is true I'm afraid we miss some iptables-related or IPv6 related
>> issues.
> Hmhm.. very interesting topic (== you are not wrong), but it should be
> raised when the test-engine was done (bud good that wasnt O!o) )
> On the other side, the  testing framework on client itself can handle
> this. The problem is to have some server running. To have it integrated
> inside current makefile can be quit tricky, and I'm strongly against.
> Currently I'm against to add this feature at all, because there is no
> known issue with this and local host seem to be enough.
> In case this issue will rise with higher priority, then my suggestion
> will be:
> 1) to have  some remote server running and working - absolutely out of
> icetea-web makefile's control
> 2) set eg  --with-remote-server=my.server.org:xyz/something  the remote
> server configurated for coopeartion
> 3) makefile will sed urls in (selected?) jnlps/htmls and, and will pass
> this url to testengine so it will know where to requests jnlps and htmls
> 4) makefile will copy (selected?) resources to this remote server,
> 5) the tests run will run as usual, because stdout/err/gui examination
> will behave in same way as in localhost.
> 
> Acctually I do not see some big issue with this approach at all, and in
> case it will become handy it can be implemented.
>  The only change in current implementation will be passing list of tests
> which should run remotly.  In testengine run I can imageine some
> extension to executeJavaws(..) method Eg executeRemoteJavaws(...) -
> there is enough  abstraction  level to handle this properly. During
> compilation of reproducers and copying of resources it will need some
> list (or directory) to specify remote ones .
> 
> But really - until there is some real need for this reproducers, I would
> rather stand without this.
>>
>> Cheers,
>> Pavel
>>
>> (Hint: Eclipse Ctrl+F)
> Yap NB have the same. But the issue is between computer and keyboard (as
> always with me and indentation)
>>
>> Jiri Vanek wrote:
> Snip
>>
>> *Testing*
>> _splash tests_
>> I was "facing really huge problem" When I wanted to see spalshscreen
>> inside browser - it was always to quickly lost :) So Ihave added magic
>> prefix XslowX to be rocgnized by internal server. When some resource
>> starts with this prefix, its without-prefix-version is returned as
>> resource. The difference is that its downloading is delayed to 10s
>> (10%per seccond). It is done by spliting this resource's byte[] to 10
>> peaces. This throws BrokenPipe Exception, but is working fine.
>> Minor improvement inside ServerAcces.main() is tighter integration with
>> testing framework - It can now be lunched instead of eg python
>> smallHTTPserver and working directory is set in same way as during tests
>> by -D property (so it can be lunched with same environment settings as
>> in-ide tests)
>> Second problem I was facing was automated testing of applets in firefox.
>> The integration of "lunch html with browser, examine stdout/stderr,kill
>> firefox" required just small changes and is working really well.
>> But there is one big TODO - to configure (in make?) browser so it works
>> with JUST BUILT iced-tea-web-plugin. Currently it expects to have
>> firefox well configured (= to link
>> /usr/lib/mozzila/libs/plugins/icedteaweb-plugin.so (or wherever firefox
>> have plugins) with the one in --prefix path). But it is not the best
>> way. To future I'm thinking about customised "embeded" firefox or to
>> some  link-plugin makefile target (run under root) which fill create
>> this link (currently iced tea-web's install do not create this link, it
>> is done in RPM post), or to have some local firefox which can be
>> linkable without root and provide --with_browser.... - *any ideas
>> welcomed* !
>> And one small to do - in some future integrate awt-robot (+stdin/out)
>> listeners
>> _new tests_
>> One new automated test is added to demonstrate the powers of testing of
>> applets inside browser
>> Bunch of new test which are using XslowX to allow everybody to see
>> various cases of spalshscreens. Those tests are not automated and are
>> testing custom splash, broken custom splash, my splashes... broken
>> stuff..both for applets and javaws
> 
> ...snip...
> 
> J.
> 
>