You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
However, recently this has stopped working in our development environment.
Current Behaviour
When we paste the debug query string into the SharePoint page URL, the page loads normally but the debug manifests are not recognised or loaded.
The “Allow debug scripts” warning banner does not appear on the page as expected.
Even after clicking “Load debug scripts”, the browser still does not load the debug manifests.
The browser does not attempt to loadhttps://localhost:4321/temp/build/manifests.js.
Because of this, our local debug build is not injected into the page, making it impossible to debug the solution.
Additional Observations
There are no console errors at the moment.
The issue occurs across multiple machines (Windows and Mac).
Tested on multiple browsers:
Microsoft Edge
Google Chrome
Safari
The SPFx solution itself has no issues and previously worked correctly with the same debugging method.
Troubleshooting Already Attempted
We followed the recommended steps, including:
Allowing the browser permission to access local network devices
Running gulp trust-dev-cert
Verifying the debug query string format
Confirming the manifest path: https://localhost:4321/temp/build/manifests.js
Checking browser console logs
Testing with CSP parameters
Allowed to run custom scripts in the site from the SharePoint Admin centre.
None of these resolved the issue.
Microsoft Support Response
We also contacted SharePoint Technical Support through the Microsoft Service Hub, and the response we received was that this behaviour is now "by design" and that serving debug manifests through the debug query string is no longer supported.
The workaround suggested by Microsoft Support was to package the solution and deploy it to test changes instead of using the debug query string.
Potential Impact
If this change is indeed by design, it could have a significant impact on development workflows for organisations building SPFx solutions.
The ability to load debug manifests from localhost is a core part of the SPFx development and debugging process. Without it, developers would need to package and deploy the solution for every small change, which would introduce a considerable amount of additional time, effort, and overhead during development and testing.
Questions
Has anyone else recently experienced this issue with SPFx local debugging?
Has the debugManifestsFile query string approach been deprecated or restricted in SharePoint Online?
If so, what is the recommended approach for debugging SPFx solutions locally now?
Any insight from the community would be greatly appreciated.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Hi everyone,
We are currently facing an issue with debugging an SPFx solution in SharePoint Online.
Previously, we were able to debug our solution using the standard debug query string:
?debug=true&noredir=true&debugManifestsFile=https://localhost:4321/temp/build/manifests.jsHowever, recently this has stopped working in our development environment.
Current Behaviour
https://localhost:4321/temp/build/manifests.js.Additional Observations
There are no console errors at the moment.
The issue occurs across multiple machines (Windows and Mac).
Tested on multiple browsers:
The SPFx solution itself has no issues and previously worked correctly with the same debugging method.
Troubleshooting Already Attempted
We followed the recommended steps, including:
gulp trust-dev-certhttps://localhost:4321/temp/build/manifests.jsNone of these resolved the issue.
Microsoft Support Response
We also contacted SharePoint Technical Support through the Microsoft Service Hub, and the response we received was that this behaviour is now "by design" and that serving debug manifests through the debug query string is no longer supported.
The workaround suggested by Microsoft Support was to package the solution and deploy it to test changes instead of using the debug query string.
Potential Impact
If this change is indeed by design, it could have a significant impact on development workflows for organisations building SPFx solutions.
The ability to load debug manifests from localhost is a core part of the SPFx development and debugging process. Without it, developers would need to package and deploy the solution for every small change, which would introduce a considerable amount of additional time, effort, and overhead during development and testing.
Questions
debugManifestsFilequery string approach been deprecated or restricted in SharePoint Online?Any insight from the community would be greatly appreciated.
Thanks.
All reactions