closes#10634
This happens for example when the tooltip are rendered for the map controlls (right or left edge of the screen depending on user locale): If the anchor is close to the bottom of the screen, the tooltip would be placed not ideally in the corner and hard to read. It is solved by falling back to left/right tooltips with a potentially offset arrow in these cases
closes#10624
The misalignment happens because the origin offset is not properly accounted for boxes around map coordinates, when the map surface is itself offset from the top-left corner of the map. This can happen with customized installations of iD, e.g. the version built into the HOT tasking manager.
fixes bug: if there were extra rendering surfaces loaded, e.g. the one of the turn restriction editor, the walkthrough tooltips and the curresponding masks were inadvertently rendered to that secondary surface, which can be even offscreen
for certain vertex features, only look at matching parent ways when determining where to draw direction cones:
* highway related points (e.g. highway=stop/yield/etc., traffic calming, cycleway=asl, traffic signs, barriers): only look at parent ways with highway=*
* railway related points (e.g. railway=milestone): only look at parent ways with railway=*
* waterway related points (e.g. waterway=milestone): only look at parent ways with waterway=*
see also #5634
* Pass the reference explicitly to the function to ensure the correct context is available.
* refactor: handle blur() in a closure to separate UI logic from addMembership
* spacing
* Fixed typo
---------
Co-authored-by: Deeptanshu Sankhwar <deeptanshu@walletsocket.com>
Co-authored-by: Minh Nguyễn <mxn@1ec5.org>
* iD#8707 Show ref in the name of route relations
* Avoid combining PTv2-formatted name with ref
* Pair name with other tags when labeling routes
---------
Co-authored-by: Kyle Hensel <k.y.l.e@outlook.co.nz>
I am a 1Password user (and employee).
Whenever I am editing a local business's details in iD,
I am frustrated that the 1Password browser extension offers
to fill out my personal address
instead of the business's address.
I don't work on our browser extension,
I could not tell you why every password manager
has their own custom data attribute
when autocomplete=off exists.
But, for fairness,
I am including other major password managers'
custom data attributes to stop them as well
from autofilling address fields.
I was very pleased to find out that
there was already
a well-used utility function
to disable autocomplete/autocorrect/autocapitalize.
Fixes#10507
and use fully quoted strings for cases which have characters that need to be encoded
old: tag=foo\"bar\" -> new: tag=foo"bar" or tag="foo\"bar\""
old: tag=foo\nbar -> new: tag="foo\nbar"
falls back to raw tag values if a quoted string cannot be parsed
