Sp-dev-docs: SPO Hosted Workbench.aspx fails to load gulp-serve'd code

[AJIXuMuK]

Category

• [ ] Question
• [ ] Typo
• [x] Bug
• [ ] Additional article idea

Expected or Desired Behavior

Workbench.aspx loads manifests.js using HTTPS

Observed Behavior

Steps to Reproduce

1. Create new web part (I'm using SPFx 1.9.0)
2. gulp serve --nobrowser
3. open layouts/15/workbench.aspx

[msft-github-bot]

Thank you for reporting this issue. We will be triaging your incoming issue as soon as possible.

[AJIXuMuK]

More details:
It looks like it tries to load the file twice.
First time using https and it is actually loaded.
But there there is some error and second request with http.

[AJIXuMuK]

Setting "https": false in serve.json doesn't help.

[martinlingstuyl]

Same here... I'm back to re-installing 1.8.2 on my project

[mmohamedbasith]

i am facing the same issue . @VesaJuvonen can you help to resolve this issue?

[FAT77]

Same problem. Since upgrade to 1.9.0 hosted workbench stopped working.

[jcosta33]

Same problem with extensions (on 1.9.0)...

[patmill]

Weird - I can't seem to repro this - but it is clearly affecting you. The double fetch has normally been there (legacy from V1.0).

If someone has this failing on a test tenant, and doesn't mind creating / sharing credentials with me, I can take a closer look. Otherwise I'll need to check with others. patmill at microsoft.com is my email.

Alternately, could someone post a screen shot of the network tab showing the calls?

[patmill]

Also - what does the command prompt look like when gulp is running? What files are being requested, etc.

And does your project do anything with webpack plug ins, etc? Does a plain hello world , no framework project work?

[mmohamedbasith]

@patmill i can confirm that I tried with react hello world project (without adding any addition code). The issue occurred. i dont have screenshot now any as i have reverted my SPFX back to 1.8.2 again after a long day of struggle with 1.9.0 version

[patmill]

OK, I have found a tenant where this repros, and the same project, same code, succeeds in another tenant. They are both running the same production code as well. So on the plus side, at first glance this looks like a problem on our servers, not with the npm bits. Stay tuned.

[JordanBerger]

@patmill Yes, the issue occurs with a plain, no-framework project.

[patmill]

Yeah, so the errors in manifests.js are a red herring. The problem is that ultimately the parsing/js loading of manifests.js doesn't happen in the error case, because the script element doesn't wind up in the DOM. Digging in further.

[patmill]

OK - so we have found the problem, and have a solution. We need to figure out the best way to publish it. There was a change in how the local manifests.js file is built, and it caused an issue on the hosted workbench.

Unfortunately, our release process winds up using a codepath that bypassed this error. We've updated the steps to ensure this doesn't happen again. Will post here when we have next steps.

[olemp]

Experiencing the same issues. Both with http and https.

[andrewconnell]

Appears the temp "fix" was to pull v1.9.0... so for now, this is "fixed" as there were known issues with 1.9.0 & hosted workbench. Ref #4371

[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