Testing SPFx on SharePoint Tenant (From Tutorials) does not work in Edge Browser

[McThrustin]

Thank you for reporting an issue or suggesting an enhancement. We appreciate your feedback - to help the team to understand your needs, please complete the below template to ensure we have the necessary details to assist you.

Category

• Question
• Typo
• Bug
• Enhancement / Suggestion
• Additional article idea

Expected Behavior

I am following the article for the new SPFx tutorials called "Connect to SharePoint" at the part where it asks to test my web part in my SharePoint tenancy. I was able to get it to work with Chrome (after searching some articles here), but cannot get it to work with the Edge Browser whatsoever.

Observed Behavior

Despite troubleshooting (including deleting the .gcb-serve-data folder and re-running the trust-cert command in gulp), Edge will not display anything in my SharePoint Tenancy except a warning: "***Your web part will not appear in the toolbox. Please make sure "gulp serve" is running in a web part project. Please refresh the page once "gulp serve" is running.". Gulp is running and local workbench works just fine. I am running Windows 10 Pro 1607 v. 14393.693 and Edge browser v. 38.14393.0.0.

Steps to Reproduce

I followed the steps in the first two "Get Started" tutorials exactly, except for using a React.js template instead of the plain JavaScript one. Once I tried the step: "Now, navigate to the SharePoint Workbench hosted in SharePoint. The full URL is https://your-sharepoint-site-url/_layouts/workbench.aspx. Notice that in the SharePoint Online side, you'll need to refresh the page to see the changes.", it works in Chrome, but not Edge.

[patmill]

If you open the edge debugger, are you seeing and 404's or other issues?

[McThrustin]

Here's a dump of the errors in Edge generated by the trying to load the SPFx Web Part onto the Developer Tenancy:

Address not found for module name: https://prod.msocdn.com/16.00.1641.007/en-US/JSC/CoreMinShellG2BundleA.js. Using it as absolute URL.
sp-loader_en-us_e10f93aa29d8eff41e6d241bc285557f.js (61,1689)

Address not found for module name: http://localhost:4321/temp/manifests.js. Using it as absolute URL.
sp-loader_en-us_e10f93aa29d8eff41e6d241bc285557f.js (61,1689)

SEC7111: HTTPS security is compromised by http://localhost:4321/temp/manifests.js
workbench.aspx

SEC7111: HTTPS security is compromised by http://localhost:4321/temp/manifests.js
workbench.aspx

Failed to load debug manifests: Error: Error loading debug manifest script. (Error) 

Ensure loading unsafe scripts is allowed.
sp-webpart-workbench_en-us_0df347f9e773e8d4170e5cbe479835cf.js (47,1280)

CSP14304: Unknown source ''nonce-TB/+6x6Qi4PG9lKbXsVPu4AqX2mgA1VQ74VsTGVO4lA='' for directive 'script-src' in Content-Security-Policy - source will be ignored
```.

[patmill]

OK - repro'd this on my machine. I'll avoid mentioning how terrible the Edge developer network tab is. Edge seems to be completely blocking all the requests to localhost, https or http. Thanks for the heads up. We'll look into it.

In the meantime, IE, Chrome or FireFox will work.

[McThrustin]

Thanks for the quick follow up. Will I be notified if/when Edge support is fixed? Or do I need to follow the release notes?

[patmill]

We'll mark the issue resolved here (or provide a workaround).

[MarcoSimon]

In the meantime, IE, Chrome or FireFox will work.

Sorry to dig out this old issue, and I'm not sure to open a new issue. But on my machine I'm receiving a similar issue in Firefox (57), running on Windows 10 Pro:

Error: ***Failed to load URL 'https://localhost:4321/lib/webparts/myWebpart/loc/en-us.js' for resource 'myWebpartStrings' in component 'd4a6620d-613f-4866-81c7-69461228f112' (MyWebpartWebPart). There was a network problem.
Make sure that you are running 'gulp serve' and you have run 'gulp trust-dev-cert'.

Error: ***Failed to load URL 'https://localhost:4321/lib/webparts/myWebpart/loc/en-us.js' for resource 'myWebpartStrings' in component 'd4a6620d-613f-4866-81c7-69461228f112' (MyWebpartWebPart). There was a network problem.
Make sure that you are running 'gulp serve' and you have run 'gulp trust-dev-cert'.

Error: ***Failed to load URL 'https://localhost:4321/lib/webparts/myWebpart/loc/en-us.js' for resource 'myWebpartStrings' in component 'd4a6620d-613f-4866-81c7-69461228f112' (MyWebpartWebPart). There was a network problem.
Make sure that you are running 'gulp serve' and you have run 'gulp trust-dev-cert'.

Error: ***Failed to load component "d4a6620d-613f-4866-81c7-69461228f112" (MyWebpartWebPart).
Original error: ***Failed to load URL 'https://localhost:4321/lib/webparts/myWebpart/loc/en-us.js' for resource 'myWebpartStrings' in component 'd4a6620d-613f-4866-81c7-69461228f112' (MyWebpartWebPart). There was a network problem.
Make sure that you are running 'gulp serve' and you have run 'gulp trust-dev-cert'.

This error persists even after repeated deletion and reinstallation of the certificate.
Anyway it works in IE (11), Edge (41) and Chrome (63) whithout any errors or warnings…

[iclanton]

@McThrustin - are you still seeing this issue in Edge?

@MarcoSimon - it looks like Firefox changed the way certificates are managed in version 57. You should see a prompt to add exceptions for two hosts (https://localhost:5432 and https://localhost:4321). Can you try adding exceptions?

[iclanton]

I'm going to close this issue. Please re-open or open a new issue if you're still seeing this.

[darkriderdesign]

This is still an issue in FireFox. I added the exceptions manually. The page runs fine when looking at published content in FireFox. its just the workbench? This was working FireFox before the last update?

I actually do my development in FireFox as my first option and Chrome as my second...

Thanks in advance for any thoughts on this.

[btastic]

I just found this issue via github while having the same problems. However, after adding the exception for localhost it was running just fine.

[lafe]

@iclanton Do you know how and when this issue was fixed? I am currently seeing the same behavior with Edge and SharePoint 2019. As SharePoint 2019 was forked somewhere at the start of 2018 and still uses SPFx 1.4, I think, it might not be fixed in this version.

[msft-github-bot]

Issues that have been closed & had no follow-up activity for at least 7 days are automatically locked. Please refer to our wiki for more details, including how to remediate this action if you feel this was done prematurely or in error: Issue List: Our approach to locked issues