"Multiple Tabs" error while using single tab, other issue with inconsistent state
Description
Attachments
- 04 Nov 2014, 04:04 PM
- 03 Nov 2014, 12:51 PM
- 03 Nov 2014, 12:51 PM
- 03 Nov 2014, 12:51 PM
is related to
relates to
Activity
John Ansorge July 15, 2015 at 3:04 PM
Hi Paul. I opened a new Jira (https://sakaiproject.atlassian.net/browse/SAK-29189#icft=SAK-29189) to track the issue of users losing data when they try to post that you're able to reproduce. Sadly, it's still open.
Paul Lukasewych July 15, 2015 at 2:02 PM
I was just testing a local backport of this code and was able to replicate John's data loss example.
Hudson CI Server March 20, 2015 at 9:18 PM
SUCCESS: Integrated in sakai-10-java-1.7 #182 (See http://builds.sakaiproject.org:8080/job/sakai-10-java-1.7/182/)
https://sakaiproject.atlassian.net/browse/SAK-27998#icft=SAK-27998 - Merging PR 193 and 220 - Multiple tab error while using single tab (matthew@longsight.com: rev 318090)
Derek Ramsey March 20, 2015 at 12:20 PM
Using the testing instructions provided in the testing tab, the students response on tab B was linked to the proper conversation in the original message.
John Ansorge February 27, 2015 at 1:06 PM
After a little more digging it seems that what is happening is that sometimes the "currentTopicId" parameter in the HTML is wrong when the Forums tool gets confused. When "currentTopicId" doesn't match the TopicId of the message being replied to, it fails to the home screen.
That's good in the sense that it's preventing parameter tampering, but obviously it's bad because the state information supplied to the client should never be initialized to values that are wrong (e.g. the currentTopicId doesn't match the currentMessageId). This is what seems to be happening.
When a user clicks "Reply" would it be possible to look up "currentTopicId" and "currentForumId" from the message being replied to rather than trusting the Forums tool's server-side state? In other words, if the user replies to messageID 43, Sakai looks up the topic and forum that messageID 43 belongs to and populates the HTML values from that.
Additionally, when the 3 state parameters don't match, could it fail to a page that lets the end-user recover what they wrote? Kinda like the page they got when the "multiple tabs" error got triggered? That way if something does go wrong, it doesn't irrevocably destroy what may have been a lot of work.
Some of our users are being warned by Sakai that they are using multiple tabs despite restarting their browsers multiple times, without ever loading a second tab (let alone a Sakai tab).
Not only that, the inconsistent state problem in forums still exists despite the "prevention" of multiple tabs. If one were to (unlikely set of steps, but regardless):
1. Open two tabs for forums, say A and B
2. Click reply to any message on A, do the same on B
3. Click cancel on A, then click reply to a message other than the one you are replying to in B
4. Type a response on B, click submit
5. Notice the response is submitted as a reply to the message from A, not B. If multiple tabs are not allowed, this response should not have submitted.
Thus, there are cases where multiple tabs are incorrectly allowed, and cases where a single tab is incorrectly prohibited from the tool.
Is there any way we can use hidden fields to store information about messages being viewed, posted, or replied to as opposed to relying on state? This would remove both issues.