New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Diagram in read-only state after restoring a saved state #1267

ZainabAlShowely opened this Issue May 17, 2018 · 4 comments


None yet
2 participants

ZainabAlShowely commented May 17, 2018

The classes' boxes can sometimes not be moved by dragging them after restoring a saved state, similarly to a read-only state.
The issue persists after modifying the code or selecting another example, but the diagram updates.

To reproduce:

  1. Open any UmpleOnline example and quit the page
  2. Reopen UmpleOnline to restore the saved state

The text simply gets selected instead of the box being dragged. The issue does not seem to occur on Google Chrome. On Firefox, it can be fixed by clearing browser information (cache, etc) from the browser.

@ZainabAlShowely ZainabAlShowely changed the title from Unable to move classes in diagram after restoring a saved state to Diagram in read-only state after restoring a saved state May 19, 2018


This comment has been minimized.


ZainabAlShowely commented Jun 6, 2018

The issue seems to consistently occur after Umpleonline is quit and the saved state is recovered after a longer period of time (seems to be at least 5-6 hours, perhaps more, will test further on it). The cookie is currently set to expire a full month after it was created however.

Seeing as it affects code written after recovering from the saved state, there might be a read-only setting affecting the diagram that gets loaded... However, the read only setting seems to be partially applied, as it does not affect the text editor.

Another issue I've found is that when restoring code with the "Photo Ready" option checked, a similar read-only state occurs (the boxes are normally be able to be moved around in that state), and when unchecking the Photo Ready option, the diagram can still not be edited. Restoring from a saved state after unchecking the Photo Ready option solves the issue. It occurs consistently on Chrome, Safari and Firefox. Should it be put in a separate issue?


This comment has been minimized.


TimLethbridge commented Jun 6, 2018

I think the photo ready problem is part of this issue and likely should be solved together with it.

Possible causes of the 5-6 hours issue: a) There could be a cache expiry of some kind. b) Not all needed variables might be set or restored in the saved state, or not all might be being consistently set/restored (for example it might be that a variable is supposed to be true or false, but is sometimes null either in the default case).

TimLethbridge added a commit that referenced this issue Jun 9, 2018

Merge pull request #1295 from umple/Issue_1267
Progress on #1267 Fix non-draggable classes using photo ready option in UO

This comment has been minimized.


ZainabAlShowely commented Jun 25, 2018

Reloading from a saved state after a longer period of time yields behavior that isn't very consistent, and as far as I can see, Chrome, Safari and Firefox can have similar results, but not at the same frequency (I have not seen Safari restore a saved state correctly after some time so far, but I haven't been testing it for long enough to be certain it never loads the saved state correctly). Chrome almost always loads the model correctly. Part of the issue likely lies in the way the model file is saved (doesn't seem permanent enough for some browsers). Three possible states can occur when a saved state is restored:

  1. The model loads successfully, without the unnecessary 'PhotoReady' option checked
  2. The model loads, but with the 'PhotoReady' option
  3. The model doesn't load and Error 500 is thrown (from the PHP)

There is possibly more than one cause. It's somewhat hard to test for the issue, especially since it doesn't occur on a local version of UmpleOnline.


This comment has been minimized.


TimLethbridge commented Aug 17, 2018

This bug seems to be happening very irregularly and infrequently and the load saved state may not be being used much anyway, so downgrading priority

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment