[ome-users] OMERO.figure behaviour on different machines

Mon Jul 9 12:58:03 BST 2018

Hi Kai,

 I managed to reproduce the bug on a Windows laptop and have a fix pending testing at
https://github.com/ome/omero-figure/pull/301

 Regards,

  Will.

On 6 Dec 2017, at 12:42, William Moore (Staff) <wmoore at dundee.ac.uk<mailto:wmoore at dundee.ac.uk>> wrote:

Hi Kai,

 Thanks for the video.

OK, so it appears the failure happens after the point that we reached with
the debugger.
The cloned $span element fails to replace the existing one in the drop-down button;
Line 5662:
$('span:first', $button).replaceWith($span);

Maybe just try taking the debugging a couple of steps further to see if you notice anything.

I’ll ask around here and see if anyone can reproduce it on their machines, which would
allow us to debug here.

In the meantime, there are a couple of potential work-arounds which would at least allow
you to create labels of the right position, colour and size…

Using the devtools console, you can manually set the attribute of the position chooser button
using this:

$(".new-label-form .label-position span").attr('data-position', 'top')

Possible values are ‘top’, ‘left’, ‘right’, ‘bottom’, ‘topleft’, ‘topright’, ‘bottomright’, ‘bottomleft’ and ‘leftvert’  (left vertical).
This won’t change the appearance (icon) of the button, but when you click Add, this value will be used in the new label.

Same trick for color:

$(".new-label-form .label-color span").attr('data-color', 'FF0000’)

Similar trick for font-size

$(".new-label-form .font-size span:first").text('32’)

Another approach is to directly add the labels to selected panels.
Select panels you want to edit in the UI as normal. Then in the console paste this to add new labels to each selected panel:

figureModel.getSelected().forEach(function(p, i){ p.add_labels([{text: "New Label", size: 14, position: 'topleft', color: 'FFFFFF'}]); });

Editing existing labels is not so simple, but in the worst case you can remove them and add new ones.

Hopefully we can work out what is going on and find a fix…

  Cheers,

   Will.

On 6 Dec 2017, at 09:04, Kai Schleicher <kai.schleicher at unibas.ch<mailto:kai.schleicher at unibas.ch>> wrote:

Hi Will,

Does it then fail to show the ‘position’ icon that you clicked on?
yes, it sounds like that. I've captured my screen in a short recording, maybe its helpful.

You should receive a download-link in a separate email.

Thanks and cheers,
Kai

On 12/05/2017 10:59 PM, William Moore (Staff) wrote:
Hi Kai,

 That looks like it’s working up to the point you took the screenshot.
Does it then fail to show the ‘position’ icon that you clicked on?
Or does it ignore the selected position when you subsequently click “Add”?

  Cheers,

   Will.

On 5 Dec 2017, at 16:37, Kai Schleicher <kai.schleicher at unibas.ch<mailto:kai.schleicher at unibas.ch>> wrote:

Thanks Will!

I have followed these steps but I have to admit that this is quickly getting over my head :/

please find my screenshot attached - I did not find anything out of the ordinary there.

Have a nice evening and cheers,
Kai

On 12/05/2017 03:57 PM, William Moore (Staff) wrote:
Sorry - here’s the screenshot…

<Screen Shot 2017-12-05 at 14.45.25.png>

On 5 Dec 2017, at 13:56, Kai Schleicher <kai.schleicher at unibas.ch<mailto:kai.schleicher at unibas.ch>> wrote:

Hi Will,

please find my answers in-line:

 You could try to Right-click > Inspect Element in each browser on the exact spot where you’re clicking
on the drop-down menu, particularly in the case where the click is having no effect.
as far as I can tell the same DOM (?) element is selected in both cases (see attached screenshot from the problematic machine)

Also, is there any difference in touch-screen functionality between those 2 machines?
no, both machines don't support touch-screen.

Is it the "Add Labels” form that is being unresponsive?
Or is it the editing of individual labels under “Edit Labels” that’s not working (or both)?
both

Thanks for your help and cheers,
Kai

On 12/05/2017 02:35 PM, William Moore (Staff) wrote:
Hi Kai,

 You could try to Right-click > Inspect Element in each browser on the exact spot where you’re clicking
on the drop-down menu, particularly in the case where the click is having no effect.

Try to see if there’s a different DOM element under the mouse pointer at that time.
Also, is there any difference in touch-screen functionality between those 2 machines?

Is it the "Add Labels” form that is being unresponsive?
Or is it the editing of individual labels under “Edit Labels” that’s not working (or both)?

 Cheers,

  Will.

On 5 Dec 2017, at 13:28, Kai Schleicher <kai.schleicher at unibas.ch<mailto:kai.schleicher at unibas.ch>> wrote:

HI Will,

thanks for the superfast reply!

I did what you suggested, but unfortunately the output in the console is exactly the same between the two machines, i.e. holds no clues.

It simply gives a warning saying "Empty string passed to getElementById()." in both cases, but no errors.

Is there another place where I can look for differences?

Thanks and cheers,
Kai

On 12/05/2017 02:00 PM, William Moore (Staff) wrote:
Hi Kai,

 I can’t think what the issue is so far.

Can you open the dev-tools on Firefox? Easiest is to right-click anywhere on the page and choose “Inspect Element”.
Then choose the Console tab in the dev-tools and see if you see any errors etc when you reproduce the bug.

Hopefully that might give some clues.
I’ll see if I can think of any better ideas what might be the problem…

 Cheers,

  Will.

On 5 Dec 2017, at 12:42, Kai Schleicher <kai.schleicher at unibas.ch<mailto:kai.schleicher at unibas.ch>> wrote:

Dear OME team,

I am experiencing an odd issue with OMERO.figure and am struggling to troubleshoot it properly, please see quote message below.

The Problem is that selections from the dropdown-menus in OMERO.figure are not accepted.
For example, we can add a label, but we can't change the size, position or colour from the default. The same thing applies to ROIs: they can be added, but not edited. All buttons exist in the drop down menu and can be selected, but they are not set/accepted.

Now whats peculiar about this:

I have two computers, both managed Win7 64bit machines part of the same active directory, both using the same version of Firefox portable (57.1).
On one machine I experience the above issue, but not on the other.

I am currently at a loss as to how I could debug this issue further.
If you have an idea and could you point me in the right direction to look it be very happy :)

As always, thanks for your help and cheers,
Kai

--
>>Please note my NEW PHONE NUMBERS: +41 61 207 57 31 (direct) +41 61 207 22 50 (central)<<
Kai Schleicher, PhD | Research Associate in Advanced Light Microscopy | Biozentrum, University of Basel | Klingelbergstrasse 50/70 | CH-4056 Basel |
Phone: +41 61 207 57 31 (direct) +41 61 207 22 50 (central) | kai.schleicher at unibas.ch<mailto:kai.schleicher at unibas.ch> | www.biozentrum.unibas.ch<http://www.biozentrum.unibas.ch/> | www.microscopynetwork.unibas.ch<http://www.microscopynetwork.unibas.ch/>

_______________________________________________
ome-users mailing list
ome-users at lists.openmicroscopy.org.uk<mailto:ome-users at lists.openmicroscopy.org.uk>
http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-users

The University of Dundee is a registered Scottish Charity, No: SC015096

_______________________________________________
ome-users mailing list
ome-users at lists.openmicroscopy.org.uk<mailto:ome-users at lists.openmicroscopy.org.uk>
http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-users

The University of Dundee is a registered Scottish Charity, No: SC015096

<Screenshot from 2017-12-05 14-54-05.png>

The University of Dundee is a registered Scottish Charity, No: SC015096

<Screenshot from 2017-12-05 17-33-06.png>

The University of Dundee is a registered Scottish Charity, No: SC015096

The University of Dundee is a registered Scottish Charity, No: SC015096
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openmicroscopy.org.uk/pipermail/ome-users/attachments/20180709/271726d6/attachment.html>