When in the RPT area with Guest/Admin access, everytime the user request some data if the user change the window focus going to a public channel or other contact and then gets back to the RPT window where it asked for the data, the spinning fetch green wheel appears again and it seems that it broke the request.
When in the RPT area with Guest/Admin access, everytime the user request some data all the other data request became greyd out (normal if the code does not handle serialized/queued requests. like in the "Load All" I think).
🚦 Current Behavior
the request is stopped when the focus shift.
all the data requests are greyed out, while the last one finishes
🎯 Expected Behavior
The request should be a background job that populates the RPT request data window while the user navigates to other areas.
The request should be serialized / queued (and add some smal time gap to free some AirTime from the RPT), so the user can queue the needed data requests from the RPT while he does other things.
📋 Steps to Reproduce
click any RPT data request and change focus to another contact or channel or any other area not on that RPT contact.
Connected directly to the radio, or through an intermediary? Directly
Transport: Serial (USB)
💻 Environment Information
OS: Windows 11 x64
Browser / Version: MS Edge Version 150.0.4078.48 (Official build) (64-bit)
RemoteTerm Version: v3.16.2·f8f6842 "wrapped" HA add-on/app
📸 Screenshots / Debug Logs
## 📝 Problem Description
1. When in the RPT area with Guest/Admin access, everytime the user request some data if the user change the window focus going to a public channel or other contact and then gets back to the RPT window where it asked for the data, the spinning fetch green wheel appears again and it seems that it broke the request.
2. When in the RPT area with Guest/Admin access, everytime the user request some data all the other data request became greyd out (normal if the code does not handle serialized/queued requests. like in the "Load All" I think).
## 🚦 Current Behavior
1. the request is stopped when the focus shift.
2. all the data requests are greyed out, while the last one finishes
## 🎯 Expected Behavior
1. The request should be a background job that populates the RPT request data window while the user navigates to other areas.
2. The request should be serialized / queued (and add some smal time gap to free some AirTime from the RPT), so the user can queue the needed data requests from the RPT while he does other things.
## 📋 Steps to Reproduce
1. click any RPT data request and change focus to another contact or channel or any other area not on that RPT contact.
## 📡 Radio Node
- **Firmware version:** Meshcore-Dev 06-Jun-2026/v1.16.0-07a3ca9
- **Hardware / board type:** Xiao S3 WIO
## 🔌 Connection to the Radio
- **Connected directly to the radio, or through an intermediary?** Directly
- **Transport:** Serial (USB)
## 💻 Environment Information
- **OS:** Windows 11 x64
- **Browser / Version:** MS Edge Version 150.0.4078.48 (Official build) (64-bit)
- **RemoteTerm Version:** v3.16.2·f8f6842 "wrapped" HA add-on/app
## 📸 Screenshots / Debug Logs
<img width="1247" height="209" alt="Image" src="https://github.com/user-attachments/assets/a958db43-509f-4f62-a5a0-3b8daa192abb" />
<!-- github-sync-id:4861146936 -->
Yeah, this is an unfortunate architecture limitation. Navigating away just serializes the page data for later restore. I don't think this is something I'm going to action in the immediate term, but it's a legitimate limitation and I get the pain, so I'm going to keep this open as a feature for future implementation.
Yeah, this is an unfortunate architecture limitation. Navigating away just serializes the page data for later restore. I don't think this is something I'm going to action in the immediate term, but it's a legitimate limitation and I get the pain, so I'm going to keep this open as a feature for future implementation.
<!-- github-comment-id:5037039726 -->
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
📝 Problem Description
🚦 Current Behavior
🎯 Expected Behavior
📋 Steps to Reproduce
📡 Radio Node
🔌 Connection to the Radio
💻 Environment Information
📸 Screenshots / Debug Logs
Yeah, this is an unfortunate architecture limitation. Navigating away just serializes the page data for later restore. I don't think this is something I'm going to action in the immediate term, but it's a legitimate limitation and I get the pain, so I'm going to keep this open as a feature for future implementation.