Item9815: Random IDs make twisties forgetful
Priority: Urgent
Current State: Closed
Released In: 1.1.1
Target Release: patch
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