-
Notifications
You must be signed in to change notification settings - Fork 66
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Offer better protections against solution overwriting #372
Conversation
380596f
to
f5c4abd
Compare
@erikmd Can you take a look at this MR? |
Hi @yurug, thanks for implementing this!
Sure! I'll have a look ASAP |
Hi @yurug, sorry for the delay! but I should have more time this week, to be able to tackle this 🤞 :-) |
@erikmd Any news related to this PR? |
Hi @yurug, not yet, sorry; I've been swamped by several exams… but it's still in my backlog! |
@erikmd Will you have time to review this PR in a close future? |
4bd1544
to
4ddafce
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @yurug, belated thanks for this PR! (which addresses a very important usability issue)
I rebased the PR on latest master, eveything compiles cleanly with OCaml 4.12.
Then I tested the app on learn-ocaml's demo-repository
with firefox-esr on Linux.
The three mechanisms you proposed nicely fit together, and I have one or two remarks/suggestions for each of them:
Mechanism 1
We disable the automatic and implicit saving of the student answer when the browser tab is closed. Instead, we ask the user to confirm that she wants to leave the page.
Minor issue: when the tab is already synchronized, I think the confirmation dialog This page is asking you to confirm that you want to leave - data you have entered may not be saved.
should not appear, while it appears unconditionally(?)
Mechanism 2
When an answer has not been modified for 3 minutes, we check if a more recent solution exists on the server. In that case, we ask the user if she wants to download the most recent version.
Nice enhancement! I noticed that the dialog:
only shows up when the current tab is already synchronized (i.e., no unsaved code)(ignore this, it was a false conjecture :)- only proposes two choices (
OK / Cancel
), basically "Keep editing" or Fetch and overwrite";
and the dialog is the same whatever is the status of the code editor (synchronized or with unsaved changes).
I believe we could extend the logic and ask:
if the tab is already synchronized:
(Fetch from server | Ignore & keep editing | Do nothing
?)
→ using a dedicated dialog with 3 choicesif the tab contains unsaved code:
(Ignore & keep editing | Sync & keep editing | Fetch from server & overwrite | Do nothing
?)
→ using a dedicated dialog with 4 choices, and making sure that if the user clicks on anything butDo nothing
, the dialog won't appear again at the next keystroke.
Would you agree with these two suggestions?
Edit: See also my later comment, #372 (comment):
We could then refactor these dialogs, relying e.g. on the snippet I suggested here:
- if the tab is already synchronized:
(Fetch from server | Ignore & keep editing
) - if the tab contains unsaved code:
(Ignore & keep editing | Fetch from server & overwrite
)
Mechanism 3
To avoid to overload the server with many synchronization requests, we disable the synchronization button when the answer is synchronized, and reactive it only when a modification is made on the answer.
Good idea! this actually solves "at the root (frontend)" this issue I had raised some time ago.
But small nitpick: I believe the Sync
button should be greyed at the beginning (when the exercise has just been opened), as there's no new changes to sync at that point… but this is not the case currently.
4ddafce
to
f8bb160
Compare
Signed-off-by: Yann Regis-Gianas <yann@regis-gianas.org>
f8bb160
to
0d25f20
Compare
Just FYI @yurug, I added some |
I turn this one in a follow-up issue (#467) : I cannot find a way to have firefox stop asking for confirmation. |
Signed-off-by: Yann Regis-Gianas <yann@regis-gianas.org>
Signed-off-by: Yann Regis-Gianas <yann@regis-gianas.org>
…e spec * Beforehand: assuming the user was continuously editing the exercise, it was checking the server version every 3 minutes. * Henceforth, as specified in the .ml comment: assuming the user has made no change to the answer since 3 minutes, it checks the server version only in that situation.
Hi, thanks @yurug ! I tested the latest version and committed several minor enhancements. Before squash-merging:
|
This hack is needed to address <#467> because [Dom.handler] <https://ocsigen.org/js_of_ocaml/latest/api/js_of_ocaml/Js_of_ocaml/Dom/index.html#val-handler> appears to be incompatible with "onbeforeunload" and Firefox. * Namely, the semantics of [Dom.handler] requires to "return true" to tell [Dom.handler] that we want to unload normally, * but with some browsers such as Firefox we should actually "return undefined" (better than "return null" BTW), * but then, "undefined" is seen as "false", implying [Dom.handler] will call "preventDefault", * end_of_the_story. Credits: the working code from this commit reuses a patch by @leunam217, pfitaxel@15780b5 See also: https://developer.mozilla.org/en-US/docs/Web/API/WindowEventHandlers/onbeforeunload#example
The fix b9960f7 has been tested successfully with:
|
Good news: the latest version of the PR seems very fine with (Firefox, Chromium, Safari). |
…#372) This fixes "bugs 1, 2" of issue ocaml-sf#505.
…-sf#372 This button triggers a "Fetch_save" and makes a menu appear, allowing end users to reuse their latest graded code, their latest saved code, or the initial template code. This button only shows up when a non-static backend is detected. Update the French translation as well. This fixes "bug 3" of issue ocaml-sf#505.
…-sf#372 This button triggers a "Fetch_save" and makes a menu appear, allowing end users to reuse their latest graded code, their latest saved code, or the initial template code. This button only shows up when a non-static backend is detected. Update the French translation as well. This fixes "bug 3" of issue ocaml-sf#505. Close ocaml-sf#493 Close ocaml-sf#505
…-sf#372 This button triggers a "Fetch_save" and makes a menu appear, allowing end users to reuse their latest graded code, their latest saved code, or the initial template code. This button only shows up when a non-static backend is detected. Update the French translation as well. This fixes "bug 3" of issue ocaml-sf#505. Close ocaml-sf#493 Close ocaml-sf#505
…-sf#372 This button triggers a "Fetch_save" and makes a menu appear, allowing end users to reuse their latest graded code, their latest saved code, or the initial template code. This button only shows up when a non-static backend is detected. Update the French translation as well. This fixes "bug 3" of issue ocaml-sf#505. Close ocaml-sf#493 Close ocaml-sf#505
Remove Mechanism-2 (#372), Add a 3-fold on-demand Reload button, Fix extra minor bugs
Context
This PR introduces three mechanisms to avoid several synchronization issues when two clients are opened on an exercise solution.
Mechanism 1
We disable the automatic and implicit saving of the student answer when the browser tab is closed. Instead, we ask the user to confirm that she wants to leave the page.
Mechanism 2
When an answer has not been modified for 3 minutes, we check if a more recent solution exists on the server. In that case, we ask the user if she wants to download the most recent version.
Mechanism 3
To avoid to overload the server with many synchronization requests, we disable the synchronization button when the answer is synchronized, and reactive it only when a modification is made on the answer.
Fixes: #316