Hi Aaron,
I have made some changes to this page. Now buttons are moved on top
of the site, also I have added proper info message there and when
plugin is not loaded properly and user clicks start button then
error message will be shown and test would not be started. Also I
have made plugin show only as a small bar. Please let me know if new
version of this page looks ok for you :)
Regards
Sebastian
On 14.11.2014 13:44, Aaron Brown wrote:
Hey Sebastian,
The problem comes in with flash blockers, which are pretty
common, especially among network engineers. I’ve attached a
screenshot of what I see when I go to the page, and click “Use
Flash”. It’s completely unclear to me that I need to hit
anything other than “Start Test”. However, if I click “Start
Test”, it will bomb out in a bizarre fashion, because I haven’t
clicked on the flash applet below the buttons to get around the
flash blocker, and since I can’t scroll the page at all, I can’t
even see that there is something for me to click. I just have to
blindly click in that box that’s below the blue page, and I’m
given no guidance to do that. Beyond that, it’s rather jarring
to have both appear in that page. If we could shrink the applet
down so that it’s a very small bar, and specifically note the
“flash block” issue in the text somewhere (especially if they
click “Start Test”, and it bombs out), that’d be vastly more
intuitive.
If you want to try to see the issue for yourself, install a
flash blocker in Chrome or FF, and then navigate to
http://desk179.internet2.edu:7123/
and select “Use Flash”.
Cheers,
Aaron
On Nov 14, 2014, at 6:23 AM, Sebastian Kostuch <>
wrote:
Hi Aaron,
I'm not sure I understand you correctly. The purpose of
this site is to provide the user JS UI and the ability to
choose which client (java or flash) should be used as
backend right? But this client itself is not supposed to
be used directly here as the GUI written in HTML + JS does
the whole work. If we want to provide user these clients
direct then we have separated pages for it (tcpbw100 and
tcpbw100-java). So what about hiding these controls on the
widget.html site so that only JS UI will be visible? Or am
I missing something and it should work different way?
Also for ensuring: by writing that it worked you mean JS
UI or running flash client located on the bottom of the
site?
Kind regards
Sebastian
On 13.11.2014 15:43, Aaron
Brown wrote:
Hey Sebastian,
Ah ok. I’ve got Flash Block on the browsers so the
applet did load, but because of how the page loads,
wasn’t visible so I didn’t realize I needed to click
on it first. Once I clicked on that, it worked. Given
the prevelance of flash blockers, and the odd nature
of this HTML5 + Flash combo, is there a better way
that we can better locate the actual Applet on the
page itself so that, and put some text in, letting
folks know they may need to click on the hidden flash
applet first?
Cheers,
Aaron
On Nov 13, 2014, at 9:36 AM, Sebastian Kostuch
<>
wrote:
Hi Aaron,
as Pawel mentioned there is currently problem
with calling applet functions from JS as from
java 7u45 update there are more security
restrictions to applets. You can read more about
it
here.
Basically now it is necessary to add
Caller-Allowable-Codebase line to manifest file
(which I have already commited) and jar file
must be signed by a trusted CA.
When it comes to issues you have mentioned, is
there also problem with calling start directly
from applet or flash embedded on the same site
where JS UI is? Are there any errors?
Kind regards
Sebastian
On 13.11.2014
15:20, Aaron Brown wrote:
Hey Pawel,
On Nov 13, 2014, at 9:11 AM, Paweł
Gesek <>
wrote:
Aaron,
I've taken a look and talked with
Sebastian about this. The new page
uses the applet by default if your
browser supports java, however there
is some sort of problem with the
_javascript_-applet communication,
making the gauges do nothing if you
are using the applet. Have you tried
pressing the flash button below in
order to switch the client to flash?
It doesn’t matter what I use, both bomb
out, and don’t (as far as i can tell
anyway) perform any tests.
One
question regarding your changes, any
reason to change nobase_ndt_DATA to
ndt_DATA in
HTML5-frontend/Makefile.am? Without
the nobase modifier
HTML5-frontend/images and
HTML5-frontend/fonts get installed
in /usr/ndt without the fonts or
images subdirectory, which leads to
missing resources on the webpage.
The install had failed as is, and as part
of my monkeying, i’d removed it, and then
forgot about it when it didn’t fix the
issue. It’s been restored in my latest
commit.
Cheers,
Aaron
Regards,
Paweł
On 11/12/2014 05:04 PM, Aaron Brown
wrote:
Hey Pawel,
I couldn’t get the RPM to build
using mock, so I committed some
changes so I could build the RPM.
However, after installing the RPM,
going to the web and hitting
start, it doesn’t seem to do
anything for me. Navigating to the
flash client directly, however,
does seem to work.
Cheers,
Aaron
On Nov 12, 2014, at 8:53
AM, Paweł Gesek <>
wrote:
I've
added the flashpolicyd
script with some small
modifications to the NDT
repository. It is started
by the ndt daemon and can
be disabled in the
sysconfig file in the same
way as the fakewww daemon.
I believe I am finished
with the RPM work, the
changes are on the branch
"Issues162". Please review
and let me know if I
missed something or you
feel something needs to be
changed.
Regards,
Paweł
On 11/07/2014 04:14 PM,
Paweł Gesek wrote:
Great,
I'll look at packaging
that script with NDT. I
assume we should bundle
it with the ndt-server
rpm. I'm also thinking
that we can handle this
in a similar fashion we
do with fakewww - the
ndt daemon will handle
starting and stopping of
that script. Is that
okay?
It's possible I missed
fakewww, I'll take a
look and make sure its
consistent with httpd.
As for widget.html it
allows switching between
the applet and flash
client.
Regards,
Paweł
On 11/07/2014 03:42 PM,
Aaron Brown wrote:
That script looks
reasonable. As long as
it can be reasonably be
packaged with NDT, I’d
be fine with it.
Cheers,
Aaron
On Nov 7, 2014,
at 8:15 AM, Jordan
McCarthy <>
wrote:
-----BEGIN PGP
SIGNED
MESSAGE-----
Hash: SHA512
For what it's
worth, the M-Lab
platform uses
the second
approach,
embodied in this
file:
https://github.com/m-lab-tools/ndt-support/blob/master/flashpolicyd.py
If this code
looks reasonable
to you all,
please feel free
to use it!
Jordan
Jordan McCarthy
Open Technology
Institute | New
America
Foundation
Public Key:
0xC08D8042 |
4A61 3D39 4125
127D 65EA DDC2
BFBD A2E9 C08D
8042
On 11/07/2014
04:46 AM, Paweł
Gesek wrote:
Hello
everyone,
I have been
looking at
updating the
NDT RPM so
that the flash
client there
works out of
the
box(Issue162
<https://code.google.com/p/ndt/issues/detail?id=162>).
I've
committed
changes to the
branch
Issue162(https://code.google.com/p/ndt/source/detail?r=1144),
which
make the
HTML5-frontend
install with
NDT and
changed the
index page
in the apache
configuration
to the new
widget.html.
As far as
running the
Flash client
out of the box
goes, the NDT
server has to
expose the
crossdomain.xml
file, which is
required
for the Flash
client to
allow opening
sockets to the
server.
Unfortunately
the socket
policy does
not go through
HTTP, but a
simple
proprietary
protocol that
uses the TCP
port 843. I am
wondering for
the best way
to handle this
in the NDT
rpm. We can
possibly add a
requirement
for a package
like
https://code.google.com/p/flashpolicyd/
and use that
to serve the
file. We could
also consider
bundling some
sort of a
simple server
script(like
this
https://github.com/xantus/mojo-websocket-examples/blob/master/script/flash-policy-server)
that would serve
the policy file.
Do you
preferences on
how to resolve
this?
Regards, Paweł
-----BEGIN PGP
SIGNATURE-----
Version: GnuPG
v1.4.11
(GNU/Linux)
iQEcBAEBCgAGBQJUXMYFAAoJEL+9ounAjYBCzD4IAKkSGdqsimCHWyD0ZdQcdD7W
wXH7emXDbO7z2jSojcNSKGqQe6wLPWFsQPN5PPwQqYdTs8bigxaKb7wGNC3qNBD5
B2FJ1Ohle10Et2NW20m+TCoORSQiYjpGCI+UenhbiV5B57BBE3t8cRgpHtxOiHjc
c2zxelECxdHq5eZ7f1JvAxWqdhUJZNVbWr7uIVGggcwe/b5Vg0yq9cqzIaVEX/bL
t9PEeYdzmmNq8ctjfKzgNEjNQo3Sp9O29nFB70KR9YNXvf0bOupJ76msI+FbRWaV
iOhgbCzfyHuHcTxQuHfxtUm5mf03cJ0QDWP5qFgTJPQSFrPYB5h4uENuMcgxKRw=
=bfO0
-----END PGP
SIGNATURE-----
|
