Item9815: Random IDs make twisties forgetful

Twisty state isn't remembered because we use random IDs now. Each subsequent page load has a different set of IDs for the twisties.

Set WaitingFor Michael in case he has any ideas

Probably we should avoid random IDs unless loading from AJAX. Or we compute a hash for the twisty content, or...

-- PaulHarvey - 09 Oct 2010

Added to KnownIssuesOfFoswiki01x01

-- PaulHarvey - 09 Oct 2010

This is an urgent issue that I thought we had fixed in 1.1.0

We need this fixed in 1.1.1. Changing to urgent

-- KennethLavrsen - 10 Oct 2010

This was partly fixed: only automatically assigned IDs are randomized (so when no ID is passed). SO if you set remember you better pass id as well.

-- ArthurClemens - 10 Oct 2010

We had a guest on IRC explaining the problem, who was surprised because it worked on 1.0.9.

-- PaulHarvey - 10 Oct 2010

We need a solution to do both (a) remember the state of the twisty and (b) be loadable via ajax. That is even when loaded via ajax the twisty remember feature must be functional.

-- MichaelDaum - 15 Oct 2010

While all other urgent bugs are being addressed this one seems to have no owner. I'd rather loose the twisty / rest feature than having twisties that do not work with respect to remembering state

So we either fix this or revert to static IDs

Who is taking ownership? I want 1.1.1 out within the next days because 1.1.0 is bad for our image and our users. I need a volunteer developer . It must be relatively easy to reimplement static ID if an remember is enabled.

-- KennethLavrsen - 20 Oct 2010

I wished I knew how to fix this, because I have a couple of wiki apps that rely on twisties being initialized correctly when loaded async'ly.

-- MichaelDaum - 21 Oct 2010

For the record: twisty states are remembered on a normal page when id is set. But not with AJAX when no ids are set.

-- ArthurClemens - 21 Oct 2010

Okay so:

Everything works fine if you use and explicit id parameter.

Without but with a remember=on parameter, IDs are assigned automatically. As they are random, their previous state can't be retrieved.

As a consequence whenever remember is switched on we need a stable non-random ID. Either it is specified explicitly by the user, or a non-random one is generated.

How do we generate a non-random ID while still preventing async'ly loaded content from reusing IDs?

If there is no (easy) answer to this question, we have to switch off random IDs and go back to enumerating them strictly, but only when remember is switched on and there's no explicit id parameter.

It follows that you will only get the remember feature in ajaxed content if you also provide an id. Non-ajaxed twisties' remember feature works fine even without an explicit id parameter. Does that make sense?

-- MichaelDaum - 21 Oct 2010

Is there a way to create a consistent id when calling from AJAX, based on web/topic/ajax caller id?

-- ArthurClemens - 21 Oct 2010

Hm, there's no such thing as an ajax caller id.

What I think is that wiki devs should be aware of the problem (docu) and simply have to add an id param for ajaxed content that they want the remember feature for. Imho, that's acceptable...

-- MichaelDaum - 21 Oct 2010

What we need fixed for 1.1.1 is that a plain normal twisty added by a plain normal user with remember enables is remembered.

I will remove randomness and add docu. Please review docu and improve if needed.

-- KennethLavrsen - 24 Oct 2010

Just a silly id, but can't we generate a not-so-random-but-still-unique ID for twisties with remember ON? Something based on, I don't know, a dedicated counter for remember'ed anonymous (no ID) twisties? Would love a use-case to figure it out.

-- OlivierRaginel - 24 Oct 2010

That is what was done in previous version. If no ID was given an ID was provided given by web and topic name + a simple counter. Applying this again. Simple

-- KennethLavrsen - 24 Oct 2010

So fixed.

Twisties are again remembered for the normal user case where someone puts a twisty on a topic and do not specify an ID. Like it always did.

Added documentation the best I could.

If the documentation is not good enough, improve it and check it in as documentation update.

One less release blocker.

-- KennethLavrsen - 24 Oct 2010

For the records: this change sux as it reintroduces an older issue again.

-- MichaelDaum - 24 Oct 2010

Why didn't you fix it yourself then?

It has been waiting for you since 09 Oct 2010 and you know it is urgent to get 1.1.1 out as 1.1.0 sucks.

-- KennethLavrsen - 24 Oct 2010

For the record, and peace on Earth, I fixed it like we agreed. I even went a bit further and appended a random (or not, if remember is set) value every time, to restore 1.0 behavior. As Arthur pointed out: theoretically you could have multiple attachment blocks for instance, so an id set in a TMPL may not be sufficiently unique

Feel free to amend if I missed some use-case.

-- OlivierRaginel - 24 Oct 2010

Reopening so Olivier can check in code fix.

-- KennethLavrsen - 24 Oct 2010

Thanks, Oliver.

-- MichaelDaum - 24 Oct 2010

Commenting is disabled while not logged in