xsbug unable to open source files on a different Windows drive letter

[cmidgley]

Build environment: Windows for xsbug and Linux for building firmware
Target device: esp32/heltec_lora-32

Description
When using xsbug on Windows, upon a breakpoint, the locate pane appears to find the source file. Browsing to the source on a different (non-C:) drive letter results in an invalid path (a:a:/path/to/file) with the drive letter duplicated. If the xsbug registry is hand-edited to remove the extra a:, the file correctly loads.

Steps to Reproduce

1. Clear xsbug from registry so all mappings are removed
2. Map a drive letter to a network path that has source files (my use case is a:)
3. Run any Moddable project and set a breakpoint
4. Click on locate, and select the source file from the network drive letter and path
5. The file does not load, and in the source pane window the path shows a:a:/path...
6. Close xsbug and edit the registry and edit the .../xsbug/preferences/main registry key's value to have just one a:/path
7. Run the firmware again, and the file loads correctly.

[andycarle]

Thank you for the report!

This is not the first I've heard of unexpected behaviors when working with network mounts on Windows. I'll take a look next week and see if there's a straightforward fix.

[cmidgley]

Also just discovered I can no longer open Preferences. With the source set to A:, the preferences window title is a:preferences, which then fails to load the preferences pane (instead I get the File not found! and Locate... screen).

Clearing the xsbug regkey let's preferences open again.

[cmidgley]

Additional information:

1. I've noticed that sometimes after failing to open the source, if I then click a link (such as in the console on a log item with a filename) it then loads the file correctly.
2. If I edit my source file back on my linux host, the xsbug source does not refresh, and I see no refresh option - so the source and the code are out of sync.

Summary of issues / conditions:

1. Opening a network drive on Windows results in a:a:/path.... which is invalid
2. After mapping a: (and having it fail), clicking a link then correctly loads and maps files
3. Once a: has been mapped (with or without fixing the a:a:), the preferences page can no longer be accessed
4. Source code edited on the host does not update on xsbug, and no refresh option appears to be available.

[cmidgley]

One more...

• Breakpoints are not working when placed on Moddable JS files, but do work in project files.

Summary of issues / conditions:

1. Opening a network drive on Windows results in a:a:/path.... which is invalid
2. After mapping a: (and having it fail), clicking a link then correctly loads and maps files
3. Once a: has been mapped (with or without fixing the a:a:), the preferences page can no longer be accessed
4. Source code edited on the host does not update on xsbug, and no refresh option appears to be available.
5. Breakpoints not working on Moddable JS files, but do work on project source files.

[cmidgley]

Checking in to see if there is a way to move this forward? It's really painful not having source (or, if I do, not being able to access the preferences page which is the only way I know of to flip on/off the exceptions settings). If it's not high on the priority queue, I can put some hours into this but would appreciate any pointers to avoid crawling the source from scratch.

[cmidgley]

One thing I've found is the preferences stored in the Windows registry for xsbug under preferences, after mapping to a: (and manually fixing in the registry the a:a: issue) is the preferences file can be fixed by changing:

"mappings": [
		{
			"alien": true,
			"locale": "A:",
			"remote": ""
		}
	],

to

"mappings": [
		{
			"alien": true,
			"locale": "A:/",
			"remote": "/"
		}
	],

(Note adding of '/' to the locale and remote)

[phoddie]

FYI – we'll have a tentative fix posted for this later today. The root cause isn't related to Windows or the drive letter, but to when the remapping extends to the root of the path. From what we can test, it is better. But, your set-up may have different paths. If the problem persists in some form, what would help the most is to have the unmapped and mapped paths.

[phoddie]

@cmidgley, did you have a chance to try this?

[cmidgley]

No, sorry. My xsbug is modified (#909) and I haven't yet attempted a merge (likely trivial, seeing as GitHub says no conflicts). I'll try to get to it in the coming days. Thx.