Sp-dev-docs: SPFX Field Customizer Extension not loading

[veerasekarmeiyappan]

Category

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

Expected or Desired Behavior

On "Gulp serve" SPFX Field customizer should redirect to SP Site list view page and should render the field with prefix "Value:" in front of each field

Observed Behavior

On "Gulp serve" SPFX Field customizer redirected to SP Site list view as expected but didn't render the field with prefix "Value:" in front of each field. No errors or warnings found in page and VS code Terminal window

Steps to Reproduce

1. Created a new SPFX Field Extension as in Microsoft site
   https://docs.microsoft.com/en-us/sharepoint/dev/spfx/extensions/get-started/building-simple-field-customizer
2. Opened in VS code
3. Updated the PageURL in "serve.json". No extra code added.
4. Ran "Gulp serve" in cmd
5. Browser will open the SP Online site list view "allitems.aspx". Click "Load Debug Scripts" in the "Allow debug scripts" pop up window
6. The list view will load as in OOTB view but the expected prefix will not be available

Submission Guidelines

Sure this is not a big bug as it has worked earlier for many users, may be a regression bug.

Thanks for your contribution! Sharing is caring.

[msft-github-bot]

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

[Kristofferkirk]

Same issue here.

[andrewconnell]

In your post @veerasekarmeiyappan, you said:

Updated the PageURL in "serve.json". No extra code added.

But that's not enough... in debug, the way your custom field customizer is associated with a field is by specifying which field it should be tied to. In the section debug your field customzier, step 8 says to _" Update InternalFieldName attribute as Percent based on the field name, which we just created."_

Of you don't do that, it won't attach the field customizer to your field.

[veerasekarmeiyappan]

In your post @veerasekarmeiyappan, you said:

Updated the PageURL in "serve.json". No extra code added.

But that's not enough... in debug, the way your custom field customizer is associated with a field is by specifying which field it should be tied to. In the section debug your field customzier, step 8 says to " Update InternalFieldName attribute as Percent based on the field name, which we just created."
Of you don't do that, it won't attach the field customizer to your field.

Thanks Andrew for your quick response. Apologies, I have missed to specify that in my steps. Yes I did update my field name "Percent" in the "InternalFieldName".
Attached my serve.json image here.

[veerasekarmeiyappan]

Wanted to keep you informed. I have raised one more issue same loading issue for SPFX ListView Command Set as well.
https://github.com/SharePoint/sp-dev-docs/issues/4394

[andrewconnell]

Always helps if you can provide a link to a repo that contains the repro of this to help with testing... this goes for both your issues.

[RamPrasadMeenavalli]

I have the same issue.

[jackpoz]

I have the same issue, a FieldCustomizer that worked fine last month doesn't work anymore (I rarely use it so I don't know when it broke).
When using "gulp serve" and loading a test list, the js file is loaded, not errors appear in the console but still the customizer is not applied.

Request: '/temp/manifests.js'
Request: '/lib/extensions/branding/loc/en-us.js'
Request: '/lib/extensions/boldField/loc/en-us.js'
Request: '/dist/google-command-set.js'
Request: '/dist/branding-application-customizer.js'
Request: '/dist/bold-field-field-customizer.js' <--- this is the Field customizer

If I set a breakpoint in onInit()/onRenderCell()/onDisposeCell(), the breakpoints are never hit.
I have a webpart and an ApplicationCustomizer in the solution too and these 2 work (so the solution is loaded and the workbench connection works too).

Is there any trace log that I could enable to ensure SPO is loading the FieldCustomizer ?

[Kristofferkirk]

@andrewconnell I took the liberty of creating a repo here, hope this helps!

https://github.com/Kristofferkirk/field-customizer-extension-example-issue

[jackpoz]

I was able to workaround the issue by replacing "&loadSPFX=true" in the url opened by "gulp serve" with "&loadSpfx=true" (notice how spfx is written in a different casing).

Longer explaination:

• The javascript file that is supposed to load customizations from the workbench checks for query string parameters "loadSpfx", "customActions" and "fieldCustomizers"
  https://spoprod-a.akamaihd.net/files/odsp-next-prod_2019-07-19-sts_20190725.002/splistitemsscope-is-mini-455d2d6b.js

, m = p.getQueryParameter("loadSpfx")
, f = p.getQueryParameter("customActions")
, h = p.getQueryParameter("fieldCustomizers")
, g = m && (f || h);

• g is evaluated as "loadSpfx && (customActions || fieldCustomizers)" .
• Checking the return value of "p.getQueryParameter("loadSpfx")" in the console, it returns null. This looked strange as the url that "gulp serve" opens contains loadSPFX=true
• Trying to call instead "p.getQueryParameter("loadSpfx")" in the console, it returned "true"
• Trying to open the same url but this time replacing "&loadSPFX=true" with "&loadSpfx=true" loaded both a FieldCustomizer and a ListViewCommandSet that weren't loaded before.

I hope this will allow people to continue working while the bug is fixed either on SPO side or at "gulp serve" side

[JonathanJourdan]

I was able to workaround the issue by replacing "&loadSPFX=true" in the url opened by "gulp serve" with "&loadSpfx=true" (notice how spfx is written in a different casing).

Longer explaination:

• The javascript file that is supposed to load customizations from the workbench checks for query string parameters "loadSpfx", "customActions" and "fieldCustomizers"
  https://spoprod-a.akamaihd.net/files/odsp-next-prod_2019-07-19-sts_20190725.002/splistitemsscope-is-mini-455d2d6b.js

, m = p.getQueryParameter("loadSpfx")
, f = p.getQueryParameter("customActions")
, h = p.getQueryParameter("fieldCustomizers")
, g = m && (f || h);

• g is evaluated as "loadSpfx && (customActions || fieldCustomizers)" .
• Checking the return value of "p.getQueryParameter("loadSpfx")" in the console, it returns null. This looked strange as the url that "gulp serve" opens contains loadSPFX=true
• Trying to call instead "p.getQueryParameter("loadSpfx")" in the console, it returned "true"
• Trying to open the same url but this time replacing "&loadSPFX=true" with "&loadSpfx=true" loaded both a FieldCustomizer and a ListViewCommandSet that weren't loaded before.

I hope this will allow people to continue working while the bug is fixed either on SPO side or at "gulp serve" side

Thanks a lot !!! Your workaround works !! Replacing "&loadSPFX=true" by "&loadSpfx=true" work for me ! Thanks

[veerasekarmeiyappan]

I have the same issue, a FieldCustomizer that worked fine last month doesn't work anymore (I rarely use it so I don't know when it broke).
When using "gulp serve" and loading a test list, the js file is loaded, not errors appear in the console but still the customizer is not applied.

Request: '/temp/manifests.js'
Request: '/lib/extensions/branding/loc/en-us.js'
Request: '/lib/extensions/boldField/loc/en-us.js'
Request: '/dist/google-command-set.js'
Request: '/dist/branding-application-customizer.js'
Request: '/dist/bold-field-field-customizer.js' <--- this is the Field customizer

If I set a breakpoint in onInit()/onRenderCell()/onDisposeCell(), the breakpoints are never hit.
I have a webpart and an ApplicationCustomizer in the solution too and these 2 work (so the solution is loaded and the workbench connection works too).
Is there any trace log that I could enable to ensure SPO is loading the FieldCustomizer ?

@jackpoz , Fab. The workaround worked for me. You are a star. Thanks.

[patmill]

@jackpoz - you are a wonderful person. I've forwarded the information, and it will help get a fix out. Can't thank you enough.

[VesaJuvonen]

Needed code changes have been now completed and we are currently internally validating situation. Fix will be rolling out to production in upcoming days/week. Until that happens, please use the workaround provided by @jackpoz. Thanks for sharing it! Sharing is caring!

[veerasekarmeiyappan]

Needed code changes have been now completed and we are currently internally validating situation. Fix will be rolling out to production in upcoming days/week. Until that happens, please use the workaround provided by @jackpoz. Thanks for sharing it! Sharing is caring!

Sounds great.Thanks for making this Vesa

[VesaJuvonen]

Fix for this one is currently being rolled out and first tenants should have already received it. Full worldwide roll out takes roughly 1 more week, so please be patience.

[VesaJuvonen]

Fix should be fully deployed worldwide by Monday 19th of August. It's currently rolling out and some tenants are already fixed as they start using latest client side bits from our cloud. By next Monday, ALL tenants in SharePoint Online are fixed given the current estimates unless there's any additional surprises.

We are definitely internally having a root cause analyses discussions on how to avoid these kind of issues. Thanks everyone for being active on troubleshooting and also for providing temporary workaround. Sorry for the inconvenience this has caused.

Can't promise that these kind of human mistakes would not happen in future, but we are further working on minimizing possibility of it to happen and are making sure that internally this is being acknowledged and discussed.

Will close the issue latest on next Monday after getting confirmations that the issue is truly resolved.

[andrewconnell]

@VesaJuvonen said

Can't promise that these kind of human mistakes would not happen in future

_Maybe if robots started doing the dev, there wouldn't be any human mistakes..._

[TackJordy]

Is this fixed? Upgraded to 1.9.1 and still have this problem.

[VesaJuvonen]

@TackJordy - this is not fixed in 1.9.1 client side bits as it's a fix which is done to CDN side and is rolling out gradually. It should be now fixed at least in 50% level of the world. Curious on test results.

[TackJordy]

Thanks it's working now :)

[timdw]

I ran into this issue yesterday after scaffolding a new ListView Command Set extension. It wasn't working at all yesterday until I found this thread and changed the loadSPFX parameter to loadSpfx. The good news is that today after clearing caches it's working in Firefox, IE and Chrome without any changes. However, Edge still doesn't work: it gives the popup with:

Error loading debug script. Ensure the server is running and the "debugManifestsFile" parameter URL is correct.
Error: Script error for "https://localhost:4321/temp/manifests.js" http://requirejs.org/docs/errors.html#scripterror

Looking through the network tab on the developer tools the manifest.js request shows as from cache even though I have cleared the cache repeatedly. No request shows in the gulp serve log either. I can open https://localhost:4321/temp/manifests.js in another tab without any problem. Not sure what else to try, I think maybe this is an unrelated issue with Edge ...

[veerasekarmeiyappan]

@VesaJuvonen Thanks its fixed. Works in chrome as expected without changing the debug URL. But in Edge I get this error message.

Error loading debug script. Ensure the server is running and the "debugManifestsFile" parameter URL is correct.
Error: Script error for "https://localhost:4321/temp/manifests.js" http://requirejs.org/docs/errors.html#scripterror

[veerasekarmeiyappan]

Want to add more details to the error message. My default browser is chrome, so when I do gulp serve it opens in Chrome. I copied the URL from chrome and enter it in Edge browser which gives the above said error. Is that because the debugger has not triggered the browser window so get this message, may be if try changing my default browser to Edge and try and let you know.

[Gennady-G]

Maybe I do something wrong but I can't deploy field customizer now (I was able two days ago). It successfully works if I "gulp serve" local, but if I drop files to cdn I don't see anything, looks like it is not loaded. I have error in chrome console (other customizers like Application Customizer and Command Set work as before):

splistitemsscope-is-mini-38dcd6ad.js:40 Uncaught Error: There is no operation handler registered for '{"operation_4":["getItems_16","detailsListItem_552"]}'.
at t.n (spofiles-mini-f2c230f8.js:270)
at new t (splistitemsscope-is-mini-38dcd6ad.js:22)
at splistitemsscope-is-mini-38dcd6ad.js:22
at splistitemsscope-is-mini-38dcd6ad.js:6
at splistitemsscope-is-mini-38dcd6ad.js:10
at splistitemsscope-is-mini-38dcd6ad.js:14
at dispatch (splistitemsscope-is-mini-38dcd6ad.js:5)
at Object. (splistitemsscope-is-mini-38dcd6ad.js:21)
at listviewdataprefetch-mini-e48b7aa0.js:18
at Object.next (listviewdataprefetch-mini-e48b7aa0.js:18)

Can somebody reproduce?..

[andrewconnell]

The root cause of the OP's issue was identified, a workaround was found & confirmed to work, and a fix was rolled out to SPO. I'm not dismissing other issues, but there are two 2-3 different threads going that are making it impossible to track in one issue, so we'll close this one as resolved, since the OP is resolved.

In an effort to streamline this, as this issue is starting to fragment, if you are still having issues, please create a new issue and provide as much detail as possible.

[p333ter]

I have the same issue. New project Field Customizer and all others get me these errors. And debug handler cant fire.

[VesaJuvonen]

@p333ter - as this issue is already closed and the root cause for this one has been solved... and verified, please do submit a new issue if there are any new findings. This will ensure that we are able to track the incoming issues as we can't track multiple different topics in single issue.

All of submitted issues are replicated to our internal engineering system. Any comments on already closed issues are basically ignored as we can't track them, so please do submit a new issue if you run to any unexpected situations. Thx.

[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