While implementing creating multiple viewers, I stumbled across a few bugs with the Firefly image viewers.
First,
The extension where we can read the mouse coordinates and translate them to pixel coordinates will read from any viewer. For example, say I have 2 image viewers, V1 and V2. If V1 is in focus (clicked on by the mouse), and then the cursor hovers over V2, the readout from V1 will continue to update while on the V2 image.
Here is a gif demo-ing this bug: https://giphy.com/gifs/26BRwJ59y0v2ymU0M
We should be reading the cursor coordinates from the viewer on the left (ffview) and outputting the result into the box on the right side. However, when I hover the second viewer (asdf), we can see we still get a readout from firefly (which has the plotId ffview, meaning it thinks it’s reading from ffview). Later in the gif, I focus the second viewer, and the box stops updating.
Second,
There is a typo in the AREA_SELECT extension (at least this is the only one I checked). In the parameter that the readout callback receives, there is a property called PlotId, when it should be plotId (Notice the capitalization on the ‘p’).
Third,
This isn’t a bug, but as far as I can tell, there is no way to release an image viewer. So if a user wants to delete a viewer, then create a new one with the same name, makeImageViewer won’t return a new one.
I’ve noticed another weird error only on our CS Server: whenever mouse readout is called, Firefly fails to return because of some internal exception. Also the floating bar (with pixel information) on the top right of browser window would not show up either. It will produce thousands of errors in the console if the user moves the cursor continuously over the image. Below is one of the errors reported. You can open the link to the server and check the error in console.
fftools-0.js:32244 Mon Jul 25 19:56:28 GMT-500 2016 fullLogger
SEVERE: Chrome Version: 51.0 : Uncaught Exception: com.google.gwt.core.client.JavaScriptException: (TypeError) : r.setNumberExtValue is not a function
at Unknown.notifyExternal(fftools-0.js@5:165399)
at Unknown.updateReadout(fftools-0.js@9:164801)
at Unknown.update_18(fftools-0.js@10:164792)
at Unknown.move_2(fftools-0.js@14:164548)
at Unknown.onMouseMove_15(fftools-0.js@16:165235)
at Unknown.onMouseMove_10(fftools-0.js@29:156586)
at Unknown.onMouseMove_9(fftools-0.js@8:156565)
at Unknown.dispatch_20(fftools-0.js@11:13507)
at Unknown.dispatch_21(fftools-0.js@8:13511)
at Unknown.dispatch(fftools-0.js@8:12530)
at Unknown.dispatchEvent_3(fftools-0.js@11:14470)
at Unknown.doFire(fftools-0.js@16:14551)
at Unknown.fireEvent_2(fftools-0.js@8:14621)
at Unknown.fireEvent_1(fftools-0.js@19:14431)
at Unknown.fireEvent_0(fftools-0.js@27:4188)
at Unknown.fireNativeEvent(fftools-0.js@23:12585)
at Unknown.onBrowserEvent(fftools-0.js@10:4237)
at Unknown.dispatchEventImpl(fftools-0.js@12:24466)
at Unknown.dispatchEvent_5(fftools-0.js@9:24456)
at Unknown.dispatchEvent_7(fftools-0.js@9:37180)
at Unknown.apply_1(fftools-0.js@23:6292)
at Unknown.entry0(fftools-0.js@23:6341)
at Unknown.<anonymous>(fftools-0.js@21:6322)
But everything works fine on my own laptop. So I think maybe something was wrong when building the Firefly. On the CS server, I used node v4.4.7, grafaileddle 2.14.1 and jdk_1.8.0_102 to build Firefly and fftools (on branch rc). I noticed two warnings about ignoring the compilation error when compiling the module edu.caltech.ipac.fftools.FFTools. I’m not sure if this relates to the error in the mouse readout.
...
>> Environment is set to local
:fftools:gwtCompile
Compiling module edu.caltech.ipac.fftools.FFTools
Ignored 1 unit with compilation errors in first pass.
Compile with -strict or with -logLevel set to DEBUG or WARN to see all errors.
Ignored 3 units with compilation errors in first pass.
Compile with -strict or with -logLevel set to TRACE or DEBUG to see all errors.
Compiling 5 permutations
...
You are right, There is a problem with mouse readout, which for me shows when you select in one image, then select in another image. May be it shows in some other scenario, but certainly not all the time, that’s why reloading seems to clear things out.
We have it in our bugs-to-fix list. Thank you for you report.
Given all recent bug reports we are thinking that it’s time to migrate to the new JavaScript based Firefly API. We are trying to devise a plan for this migration by Friday. We might want to add this as a topic to this week’s agenda.