(closes#5847)
- removed the stopPropagation from the combobox keydown handler
to make sure that the raw_tag_editor keydown handler will run
- increased timeout from 1ms to 10ms for Firefox
This is related to Firefox's newish time budgeting approach that they
started using around Firefox 55. As a result, very fast timers (<4ms?)
may run synchronously instead of yielding and running asynchronously
https://blog.wanderview.com/blog/2017/03/13/firefox-52-settimeout-changes/
(note similar code in ui/fields/combo.js to delay focus changes and
redraws 10ms after the tag changes and other events have completed)
(closes#5840)
This didn't always trigger a crash, but it can. It attempted to remove the
row containing the key/value input fields, however this ilne is unnecessary
because the change event will trigger a redraw and d3 will handle the removing
milliseconds later.
Also
- use field inheritance to simplify presets
- rename multipurpose to "Golf Cartpath / Service Road"
(I think users would understand this better)
- add `maxspeed` to "Golf Cartpath / Service Road"
(closes#5872)
This commit also hardens the 'key=value' splitting behavior to actually
check the split result length and avoid overwriting a readonly key
(re: #5024)
I've converted the improveOSM errors to use this new generic QA error
structure which should allow for more general code to be used in
behaviour and UI.
Sidebar preview is currently broken, but will be fixed shortly.
Javascript is not my usual domain so still getting used to how scope
works and working with callbacks. Believe this code is now written as
intended.
As a bonus a response status to the error update request which isn't the
expected 200 now returns before visibly removing the error and adding it
to the closed cache.
Potential for multiple missing turn restrictions on one node and I've
also seen a case of missing one-way along the same stretch of road in
opposite directions!
Missing geometry is tile based so can't really be coincident, but
doesn't hurt to check in case they happen to land on a one-way or turn
restriction.
The direction of travel in the description was misleading as the way
segment wasn't necessary linear and so the direction could change as you
travel along the way. This is more explicit as it specifies the detected
start/end nodes (also useful to show that it's not the whole way that
might be one-way).
The position is now taken as the central node in the `feature.points`
list (or the average of the central two when there are an even number of
points).
Bryan Housel