Author: TomH
[Added to the original trac issue at 1.20pm, Tuesday, 5th November 2013]

I'm afraid this is something where we just can't win - for every person that doesn't want the state of a particular layer preserved there's another one that that does.

Author: aseerel4c26
[Added to the original trac issue at 1.29pm, Tuesday, 5th November 2013]

TomH, yes, but my request is not about the preservation in general. It is only about that the preserved state is changed via (clicked) links. If the notes layer is switched on manually it is fine (IMHO) that it is saved to the cookie.

Well, anyway, if we want to promote "notes" the current worm-like behaviour is good. ;-)

Author: TomH
[Added to the original trac issue at 1.33pm, Tuesday, 5th November 2013]

There's no real difference though - a layeradd event will be triggered regardless of the reason for the later being turned on and that will cause an update to the cookie state.

Author: aseerel4c26
[Added to the original trac issue at 1.42pm, Tuesday, 5th November 2013]

Yes, currently it is no difference. This is wrong, which is what this report is about. This wrong behaviour could be changed by some JS coding.

I just guess this also applies to the other layer states.

Author: TomH
[Added to the original trac issue at 1.47pm, Tuesday, 5th November 2013]

Short of global state there is simply no way to do what you want, and global state is bad.

Author: aseerel4c26
[Added to the original trac issue at 2.00pm, Tuesday, 5th November 2013]

?!?

... and permanently changing user's settings if he clicks a link ... is good?

Seems you do not want help here...

Author: TomH
[Added to the original trac issue at 2.02pm, Tuesday, 5th November 2013]

It's not a setting, it's a (sticky) state which the user can correct simply by turning the layer off again.

But seriously, if you know a way to fix this then let's see your code, because I don't see any way to do it that wouldn't have serious impact on the maintainability of the code, and I don't see this as a serious enough problem to pay that price.

Author: aseerel4c26
[Added to the original trac issue at 2.11pm, Tuesday, 5th November 2013]

What is the difference to a setting? It is stored 10 years (if I see correctly). Also the average user does not even know that there is a hidden tick somewhere (even if he opens the layers menu by chance it still may be scrolled outside the viewport).

Code? Probably that would involve something what you call "global state" and which "is bad". So, likely all possible code ideas are "bad". So, right, there is no possible code.

Author: aseerel4c26
[Added to the original trac issue at 2.18pm, Tuesday, 5th November 2013]

I understand that the website software is "as is" and bugs are willingly accepted and not collected to be fixed at some time in the future. Good, I can save that my time and my annoyance in the future. Consequently I will tell that people asking in the help centre. Sorry, TomH, this situation is not how I think it should be.

Author: TomH
[Added to the original trac issue at 2.22pm, Tuesday, 5th November 2013]

No, bugs are not "willingly accepted" at all. But all software involves tradeoffs and sometimes you have to decide that the cost of a particular fix is not something that you want to pay because of the other effects it has.

Yes, we could just leave the bug open forever in the hope that somebody comes up with a clever way of fixing it, but that would really just be giving false hope - we have hundreds of open bugs many of which have been open for years and we don't have hordes of people magically coming along and fixing them.

If it makes you happy, and stops you denigrating the developers on the help site, then I will happily reopen this bug.

Author: aseerel4c26
[Added to the original trac issue at 2.36pm, Tuesday, 5th November 2013]

Yes, fine, thanks. I really would not like to recommend other people to report bugs here otherwise. I hope you can understand that a bit.

The devs' work is good in general, just things like the bugreporting and the decision making processes for new features and default settings are not.

Author: scai
[Added to the original trac issue at 12.44pm, Wednesday, 13th November 2013]

Just for the record, there are actually [https://help.openstreetmap.org/questions/28035/where-do-these-ugly-signs-come-from users complaining about this issue]. And yes I do know that this doesn't make the problem easier to solve :).

Author: aseerel4c26
[Added to the original trac issue at 5.44pm, Monday, 10th February 2014]

maybe it is helpful for someone else too: [https://wiki.openstreetmap.org/wiki/User:Aseerel4c26/osm.org_UI_fixes_by_JS For myself I have removed the notes and data layer state saving into the cookie completely] (the first part only) as a workaround.