"noReset" toggle is not working in published version

[dhalbert]

@mikeysklar @makermelissa

(Found while helping a user in discord: see https://discord.com/channels/327254708534116352/537365702651150357/1306827591407239248 and preceding)

#297 by @mikeysklar added a toggle to suppress trying to send a reset, for use with passthrough updaters like on PyPortal. But it is not working in the published version.

I tested the tip of main locally, which includes #297, and it works fine. If the toggle is on, I see:

ESP Web Flasher loaded.
Connecting...
Connected successfully.
Try hard reset.
No reset requested; skipping hard reset.
...

But the published version at https://adafruit.github.io/Adafruit_WebSerial_ESPTool/ does not work. It has the toggle, but it does not print No reset requested; skipping hard reset. This makes me think that the code checking the status of the checkbox is not working for some reason in the published version. Maybe the document.getElementById() is not working?? I'm not sure how to test this locally.

    // Check for noReset toggle
    const noResetCheckbox = document.getElementById("noReset");
    const noResetEnabled = noResetCheckbox
      ? (noResetCheckbox as HTMLInputElement).checked
      : false;

    if (noResetEnabled) {
      this.logger.log("No reset requested; skipping hard reset.");
      return; // Skip reset if noReset is enabled
    }

[mikeysklar]

Thanks @dhalbert ... I'll work on this on Friday.

[mikeysklar]

Wired up a PyPortal and reproduced @dhalbert results.

• local version runs
• published version ignores "Turn on for passthrough updates" and tries to reset

I'll try observing the browser interaction and maybe setting up a matchy matchy web server on my own host (not just using localhost) to see if I can reproduce the production code behavior.

[mikeysklar]

I did some F12 browser debugging and see an issue with my code from the last PR.

js/script.js

/**
 * @name clickNoReset
 * Change handler for ESP32 co-processor boards
 */
async function clickNoReset() {
  saveSetting("noReset", noReset.checked);
  if (espStub) {
    try {
      // Assuming espStub has a setNoReset method, similar to setBaudrate
      await espStub.setNoReset(noReset.checked);
    } catch (error) {
      console.error("Failed to set noReset:", error);
    }
  }
}

The espStub does not have a setNoReset. I'm not sure how the code was working locally without it. A setNoReset needs to be in the src/espload.ts.

[mikeysklar]

Well the PR #304 seemed promising, but with the on-line version still ignoring the added hardreset() checkbox logic I'll need to create a working dev server.

I think I can enable github.io to work on my fork of the code so we don't need to be messing with the production version.

[tyeth]

I just had to turn on GitHub pages (set it to use Actions instead of a branch) then ran the pages deploy action. You may need to update the jsdelivr link line 42 in index.html

…

On Fri, 15 Nov 2024, 23:45 Mikey Sklar, ***@***.***> wrote: Well the PR seemed promising, but with the on-line version still ignoring hardreset() I'll need to create a working dev server. I think I can enable github.io to work on my fork of the code so we don't need to be messing with the production version. — Reply to this email directly, view it on GitHub <#303 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABTBZ4ZGY72EWVGAG2SDQPL2A2BRLAVCNFSM6AAAAABR2KD2NSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOBQGE2DMNBRG4> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[mikeysklar]

@tyeth - Thank you so much for pointing these two items out.

I see the jsdeliver link is pointing at an earlier release that did not support passthrough.

https://cdn.jsdelivr.net/gh/adafruit/Adafruit_WebSerial_ESPTool@1.2.0/dist/web/index.js

I just made a change to point it at the 1.3.0 current release with passthrough.

[dhalbert]

It's working now, in the deployed version! Thank you @tyeth @mikeysklar.

This seems like a bit of a catch-22. The version link needs to be updated in advance of doing the actual release. So ideally there would be a 1.3.1 release with #304 included, but we also need another PR that points to 1.3.1.

[mikeysklar]

Confirmed, also works for me. Really needed to @tyeth to point out that hardcoded version number.

Dan,

I can submit another update that uses something like @latest, @main or even @master.

const scriptUrl = "https://cdn.jsdelivr.net/gh/adafruit/Adafruit_WebSerial_ESPTool@latest/dist/web/index.js";

What do you think?

[dhalbert]

const scriptUrl = "https://cdn.jsdelivr.net/gh/adafruit/Adafruit_WebSerial_ESPTool@latest/dist/web/index.js";

That is great. I did not realize that would work -- I thought it had to be a release. That is much better than choosing a release number, making a PR, and then having to make a release immediately.

[mikeysklar]

Do you have a preference between:

1. @latest
2. @main
3. @master

[dhalbert]

There is no @master. I think @latest makes sense, but I think it's the same as @main, since @main is the main branch.

[mikeysklar]

kk...PR #306 with @latest is in

[mikeysklar]

@thx. Test on Feather V2 and PyPortal web release looks good.

[tyeth]

I found using latest was problematic for immediately needing it updated in the CDN, but it does update eventually. I can't remember the delay after a tag or release push, maybe it was quite good, but not if you're after it immediately and super impatient after the umpteenth push deploy cycle.

…

On Sat, 16 Nov 2024, 02:29 Mikey Sklar, ***@***.***> wrote: kk...PR #306 <#306> with @latest <https://github.com/latest> is in — Reply to this email directly, view it on GitHub <#303 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABTBZ45XGLG5HE6UVE5BGED2A2UW3AVCNFSM6AAAAABR2KD2NSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOBQGMZTMMRZG4> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[dhalbert]

Note that @thx, @latest, @main, @master are all tagging usernames on GitHub. 🙂

[tyeth]

I think I was expecting it to pickup branch commits immediately, maybe that was my confusion, and switching to tags solved it

…

On Sat, 16 Nov 2024, 02:40 Tyeth, ***@***.***> wrote: I found using latest was problematic for immediately needing it updated in the CDN, but it does update eventually. I can't remember the delay after a tag or release push, maybe it was quite good, but not if you're after it immediately and super impatient after the umpteenth push deploy cycle. On Sat, 16 Nov 2024, 02:29 Mikey Sklar, ***@***.***> wrote: > kk...PR #306 > <#306> with > @latest <https://github.com/latest> is in > > — > Reply to this email directly, view it on GitHub > <#303 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ABTBZ45XGLG5HE6UVE5BGED2A2UW3AVCNFSM6AAAAABR2KD2NSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOBQGMZTMMRZG4> > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> >

[dhalbert]

Fixed by #304, #305, #306.

[dhalbert]

@tyeth so do you use a version number, and make sure to do a release at the same time?

[tyeth]

I think in another repo I was trying to avoid having to release each change, and tags was enough for it to pickup quickly using branch name or latest, but only a new tag in cdn URL was quick enough to get me immediate updates (due to not being cached yet by jsdelivr)

[tyeth]

@dhalbert see above, sorry I'm bad at pinging, and here was the script I was using. Effectively I had vscode open and was rapidly saving, toggling to terminal and updating with this script then toggling to chrome to test (when local was done with and wanted to fix my jsdelivr version which behaved differently than local) https://github.com/tyeth/serialfruit-connect-bookmarklet/blob/main/update_refs.py#L69-L77

[dhalbert]

No need to ping me -- I am subscribed to the issue (I get email for all adafruit repos, and I look at it).

I think if there's a short delay in general that's fine. When I merged the PR yesterday it showed up on the CDN almost immediately.