-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Moving too quickly between pages on the popped-out "speaker notes" window resets to non-notes view #2004
Comments
Thanks for logging this! The speaker notes system is quite rudimentary and it could benefit from someone with better JavaScript skills than me giving it an overhaul. |
I've found that navigating at all in the speaker notes immediately breaks the connection between the speaker notes and the main window. I'm assuming this is the same issue that @fw-immunant ran into here. |
I've seen that as well. |
I can also reproduce this reliably by clicking into the notes and go to the right. The speaker notes view is now turning into the regular slide view". Interesting behavior: moving left or right has a different effect |
I found the issue with the "next" navigation and created a pull request. There is an additional issue causing the break: comprehensive-rust/theme/speaker-notes.js Lines 119 to 123 in c05f0b6
This triggers on any unload (e.g. access next slide) of the (speaker notes) page - which means prev+next navigation events. There is a workaround that tries to avoid acting on this, but depending on the the sequence and timing of events this still might break comprehensive-rust/theme/speaker-notes.js Lines 209 to 226 in c05f0b6
|
Change this selector to use the ~= selector to test if a white space separated word "prev" or "next" is contained Fixes a speaker notes bug that did not allow going to the next slide in the speaker notes. The reason for that is that the "rel" attribute contained "prev" respective "next prefetch". See: https://developer.mozilla.org/en-US/docs/Web/CSS/Attribute_selectors#attrvalue_2 This fixes part of #2004 when going to the right (containing "prefetch").
To add some thoughts on this: We need some mechanism for the slides to discover that the speaker notes are closed. Currently this is done by signaling back to the slides when the speaker notes close (with the Options that might be viable and need some discussion:
|
I think that |
Yes it is, but it is destroyed on navigation attempts like switching to a different slide as far as I understand. I also thought about using that to figure out if popout.closed is true |
Fixes bug #2004. Refactored the communication between the speaker notes window and the regular window by using a Broadcast channel - this is now self-recovering(!) even if speaker notes are closed and manually re-opened! For better readability and maintainability refactored some string-based states into enum style code and refactored detection of the type of windows (print, speaker note, regular window) Manually tested the new code and the speaker notes window does not disconnect from the regular window anymore. This now works way more reliable, even if there are (still) some UI glitches that have been there before already.
This should now be fixed with the latest PR. I wanted to avoid all the described race conditions and used the ping-pong style mechanism described above. Getting hold of the popout window in any way was not feasible because a navigation event (next slide, etc.) is destroying these window proxy objects. With the new approach the notes can even recover itself when the connection was lost. Once a new window/tab with speaker notes is reopened, the broadcast channel is discovering the new window and notes are synced again. |
To reproduce, tap left and right a couple times while the speaker notes window is focused after popping it out into its own window. It will revert to showing a second copy of the course material, as if the speaker notes window had been closed.
The text was updated successfully, but these errors were encountered: