I’ve updated the timeline! 
Now, when you click the progress bar, a dedicated modal opens with the topic timeline container (aka the mobile timeline). This makes it much easier to use on mobile too.
Sorry, but I’m not able to reproduce this. 
2 likes
I whacked the update on a test site https://forum.escooterworld.com/ and it happens on there, not sure why. Am on holiday till Tuesday so can’t really test further as to whats going on
1 like
Can you send me your component so I can take a look at it?
1 like
Sent, does the same though with that component turned off and has only started happening since last update
1 like
Try testing in the Duck Duck Go browser 
I’ve updated the swipe hint message: DEV: Add more control over swipe hint message - Pull Request #11 - VaperinaDEV/discourse-topic-preview-modal - GitHub
It contains two new settings:
-
always_show_dismiss_hint:
By default the mobile dismiss-gesture hint (“Swipe up/down or use
the back gesture/button to close”) is shown once ever per browser,
the first time the preview modal opens. Enable this to show it every
time instead. Only applies when modal_dismiss_gesture is “gesture”. -
dismiss_hint_duration_ms:
How long (in milliseconds) the dismiss-gesture hint stays on screen
before fading out. Consider lowering this if you’ve enabled
always_show_dismiss_hint, since a 10-second hint on every open can
get repetitive. Set to -1 to disable the auto-dismiss entirely - the
hint then stays until the modal itself is closed.
The topic_preview.back_gesture_hint is now htmlSafe.
4 likes
Hi, I really appreciate this theme component; it works perfectly for me.
Today I noticed that in the (nested reply view) theme, clicking the “one other reply” button in the comments section shows the error: “Error: The requested URL or resource was not found.”
1 like
Thanks for reporting this! I tested the nested reply view, but I wasn’t able to reproduce the issue. The reply loads correctly for me.
Could you check whether the same reply opens correctly on the regular nested topic page? If it doesn’t, it may be an issue with that particular post/topic.
If you see the issue again, please also send me the topic URL so I can investigate it further.
Hello,
When I click “
2 replies” in the “Nested Replies” view,
I get the error message: “Error: The requested URL or resource was not found.”
I tested this in preview mode, on desktop Google Chrome, and on mobile Google Chrome, and the same error appears in all cases.
1 like
Hi,
Sorry! I think I didn’t make myself clear.
What I meant to say is that when using the “topic-preview-modal” component, if you click on a topic in the “nested mode” view on the homepage to preview it, and then click the “more replies” button, the following error appears.
1 like
Ah, got it, thanks! Here is the fix: FIX: Nested view lost topic identity on pagination + dead "Continue t… · VaperinaDEV/discourse-topic-preview-modal@fa90848 · GitHub
2 likes
Thank you so much! I just tested it and there are no issues!
Thanks for your work on this theme component! 
1 like
Hello,
Wow, this component looks great and offers excellent usability, especially on smartphones!
I’ve run into a blocking bug:
On a topic using the “Post Voting plugin”, the modal doesn’t load.
This issue occurs on both smartphones and PCs.
It happens with the latest versions.
If needed, I can reactivate the component on my forum and send you a link to the bug via PM.
Thanks.
2 likes
Thank you @Stephane_Roy! Here is the fix: FIX: post-voting topics crashing the topic preview modal · VaperinaDEV/discourse-topic-preview-modal@0be328e · GitHub
2 likes
Hello 
I’ve refactored the theme component:
The large topic-preview-modal component has been split into focused delegate classes for nested topics, composer interactions, post actions, progress navigation, overlay watching, and back gesture state.
The existing component API and external contracts remain unchanged, while topic-preview-modal.gjs has been reduced from 1836 to 873 lines.
No functional changes intended.
4 likes
Maybe the functionality exists and I couldn’t find how to set it:
It would be possible to avoid the modal in specific categories (aka Discourse Category Docs), where the modal can be counterproductive when the sidebar is intended to be shown?
2 likes
There was a request for this earlier. I’m just trying to figure out the best implementation. It doesn’t seem straightforward, as it could confuse users if some topics on /latest open in a modal while others don’t. On the other hand, if we restrict it strictly to categories, how should topics on /latest behave?
2 likes
Oh, gran Don. I’m sorry, I didn’t see the previous request. I’m very glad that you’re analyzing it and taking it into account!
In our specific case, the categories in which we would disable the modals are specifically glossary, wiki, and an online course set up on Discourse.
It occurs to me that a switch to test the use of modals in those same categories, and that they appear listed as latest topics, would be positive for truly evaluating their impact from the users’ perspective, in a real-world scenario.
In case that’s not possible, at least for us, it would be better not to enable the modals even in the latest topics view for those scoped categories. Because the course is set up to show the sidebar, just like our wikis and the glossary.
We intend for our people to actually research and read that particular information, and we are interested in providing them with direct links to it from the sidebar view.
We are fully comfortable with allowing the modal on the rest of our community. It works really well.
1 like
Would they not click open full topic?
1 like
You know, all we want is less friction. Should be a music track or something 
2 likes