Opened 5 years ago

Last modified 5 years ago

#5027 reopened defect

the user's "notes" layer state should not be changed permanently (by saving into his _osm_location cookie) when he opens a link with layers=N

Reported by: aseerel4c26 Owned by: rails-dev@…
Priority: minor Milestone:
Component: website Version:
Keywords: slippymap Cc:

Description

Currently, the user's state of the "notes" layer seems to be saved in the _osm_location cookie (an N added at the end: 8.67995023727417%7C50.016743371076984%7C15%7CMN instead of 8.679993152618408%7C50.01693640159293%7C15%7CM) which is valid for 10 years per default.

Since the state of the notes layer is (silently) changed if you open a layers=N link and it is saved in a long-time cookie you can infect (somehow) people with the notes layer. It will spread if those people send themselves links created with the share tool. Yeay, a semi-manual worm! ;-) "Notes" will rule the world soon.

Change History (14)

comment:1 Changed 5 years ago by aseerel4c26

  • Summary changed from the user's "notes" layer state should not be saved into his _osm_location cookie when he opens a link with layers=N to the user's "notes" layer state should not be changed permanently (by saving into his _osm_location cookie) when he opens a link with layers=N

comment:2 Changed 5 years ago by TomH

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.

comment:3 Changed 5 years ago by aseerel4c26

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. ;-)

comment:4 Changed 5 years ago by TomH

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.

comment:5 Changed 5 years ago by aseerel4c26

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.

comment:6 Changed 5 years ago by TomH

  • Resolution set to wontfix
  • Status changed from new to closed

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

comment:7 Changed 5 years ago by aseerel4c26

?!?

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

Seems you do not want help here...

comment:8 Changed 5 years ago by TomH

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.

comment:9 Changed 5 years ago by aseerel4c26

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.

comment:10 Changed 5 years ago by aseerel4c26

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.

comment:11 Changed 5 years ago by TomH

  • Resolution wontfix deleted
  • Status changed from closed to reopened

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.

comment:12 Changed 5 years ago by aseerel4c26

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.

comment:13 Changed 5 years ago by scai

Just for the record, there are actually users complaining about this issue. And yes I do know that this doesn't make the problem easier to solve :).

comment:14 Changed 5 years ago by aseerel4c26

maybe it is helpful for someone else too: For myself I have removed the notes and data layer state saving into the cookie completely (the first part only) – as a workaround.

Note: See TracTickets for help on using tickets.