Skip to content
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

Edit of ways tends to freeze 1.0.11 #168

Closed
jjiglesiasg opened this issue Sep 1, 2020 · 5 comments
Closed

Edit of ways tends to freeze 1.0.11 #168

jjiglesiasg opened this issue Sep 1, 2020 · 5 comments

Comments

@jjiglesiasg
Copy link

The selection of a line (edited of to be created), or node, tends to freeze quite often and only could be released chosing "save" and them "escape" to keep editing.

Also in the Comments box, currently do not display previous comments when hit the lower arrow.

In general Version 1.0.11 is quite slow in comparison with ID 2.18.4

BsRgds

JJ

@jjiglesiasg jjiglesiasg changed the title Edit of ways tend to freeze 1.0.11 Edit of ways tends to freeze 1.0.11 Sep 1, 2020
@Bonkles
Copy link
Contributor

Bonkles commented Sep 1, 2020

Hi there!

Would you mind posting:

  • a screenshot & URL of where you were performing edits when you encountered these issues
  • Whether the performance differences you see vs. iD 2.18.4 go away if you turn the RapiD layer off (Shift+R)?
  • What browser you're using
  • Any bugs or errors that you see in the console when you experience the 'selection of a line freezes' issue.

@bos
Copy link

bos commented Sep 10, 2020

I've run into this lockup issue too, after a minute or two of editing. It's independent of location. Doesn't matter whether RapiD is enabled or not.

It does seem to be correlated with a stack trace:

Uncaught TypeError: l.graph is not a function
    at operationDelete (iD.min.js:1)
    at e (iD.min.js:1)
    at iD.min.js:1
    at Array.forEach (<anonymous>)
    at f (iD.min.js:1)
    at iD.min.js:1
    at Set.forEach (<anonymous>)
    at g (iD.min.js:1)
    at Object.n.validate (iD.min.js:1)
    at Dispatch.call (iD.min.js:1)

@bhousel
Copy link
Contributor

bhousel commented Sep 11, 2020

Thanks for reporting @bos & @jjiglesiasg ..
Looks like there is a bug in our short_road and y_shaped_connection validators.

Apparently openstreetmap/iD@db9eed2 swapped the argument order for all the operations from:
fn([ids], context) to fn(context, [ids])

So we need to swap the argument order in our RapiD validation code as well:
https://github.com/facebookincubator/RapiD/blob/e4e1908efdd976386f79a5cde1f4db957b255a4a/modules/validations/y_shaped_connection.js#L54
https://github.com/facebookincubator/RapiD/blob/e4e1908efdd976386f79a5cde1f4db957b255a4a/modules/validations/short_road.js#L84

It only surfaces occasionally because it depends on whatever the validator finds.

@Bonkles
Copy link
Contributor

Bonkles commented Sep 11, 2020

I've run into this lockup issue too, after a minute or two of editing. It's independent of location. Doesn't matter whether RapiD is enabled or not.

It does seem to be correlated with a stack trace:

Uncaught TypeError: l.graph is not a function
    at operationDelete (iD.min.js:1)
    at e (iD.min.js:1)
    at iD.min.js:1
    at Array.forEach (<anonymous>)
    at f (iD.min.js:1)
    at iD.min.js:1
    at Set.forEach (<anonymous>)
    at g (iD.min.js:1)
    at Object.n.validate (iD.min.js:1)
    at Dispatch.call (iD.min.js:1)

Thank you so incredibly much for the stack trace- these are incredibly helpful for rooting out the bugs. I'll turn the release crank and get these fixes in today.

@Bonkles
Copy link
Contributor

Bonkles commented Sep 11, 2020

Release 1.0.12 just went out with these fixes. Please give Rapid another try!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants