Kinetic screen comes up blank in browser - troubleshooting guide

I think it’s time to consolidate the collective knowledge into one guide. I’ll need help with this.

Problem

You open a screen/app in the browser and get a blank error, or the window itself is completely blank

Pic of blank error (click arrow to expand)

Pic of blank screen (click arrow to expand)

Here, the user was trying to print the PO; the blank slider panel is what appears when clicking the Print button

Things to try

(You don’t need to do all of them, but I suggest doing it in this order.)

  1. Open the form in App Studio (base and custom layers); do not change or save them. (Thanks @dcamlin)
  2. Try to clear the server cache of the one screen (Thanks @utaylor)
  3. Delete Kinetic (and classic?) personalizations for the user. (Use @hmwillett 's tool)
  4. For the first 3 points: be advised that a slideout panel may be an app-open to a different app, so you will need to try these steps on the other app also. (For example, POEntry print button slides out the POForm app, rather than an embedded slider.)
    a. Also not a bad idea to have the user log out and back in after any of these.
  5. Republish the layer being used (if applicable).
    a. Also, click that link for advice on testing a base layer.
  6. Open the form in private-browsing mode (Edge calls it InPrivate; Chrome calls it Incognito)
  7. If that works, you might clear the browser cache so that they can use the non-private mode again.
  8. Hard browser reset (@josephp)
  9. Multiple layers can cause a conflict. (@aosemwengie1)
  10. As a last resort, run conversion 191 in Conversion Workbench. This is not a great thing to do during the workday, as it will create as many problems as it solves. But it does seem to work.

Personally, I try desperately to avoid the last option (conversion 191).

7 Likes

Point is, I’d like to whittle this down to the least-impactful sequence of invents.

Unless there is a way to fix it for everyone, but I’m not seeing that.

Personally, I was running conversion 191 nightly to try to stay ahead of things, but I don’t think I did any more good than just rolling the dice.

I also wonder if I would have had more success if I forcibly kicked off all (inactive) users nightly and then ran the conversion.

I’m still leaning toward the kick-off-the-users plan but I’ve stopped running 191.

1 Like

Are you 100% sure youve removed the personalisation from xxxdef table. Is the slideout a built in slideout or is it calling an application

Good clarification. I’ll add that… somewhere. Maybe a footnote.

When it comes to Kinetic you’ll have to start having arm, toe, ear notes as you run of space quickly with the bugs…

And

image

I did add it - it’s #4 - until I rearrange again.

image

I have a new one, it comes up blank when two layers are attached on the same form in 2024, even though either layer alone works fine.

Eek.

I have to admit, I am terrified of having multiple layers, 100% due to my own ignorance on how that would (intentionally) work. I’m sure there is a great explanation of why this is a genius design philosophy, but it’s better for me to keep it simple. I have enough issues at the moment.

So, I’m not sure how to phrase this advice.

If your plan was to want multiple layers that take advantage of the possibilities, I guess you’re hosed?

On the other hand, if v2 is just an improved version of v1, and you just forgot to disable v1 when you published v2, then the solution is simple: only have one layer in use at a time.

EDIT: Added at (current) # 8

I remember a few of my forms having errors in the onset of testing 2024.1.1… but I never noticed any correlation between a form with multiple customized layers vs a form with only one… or even a form with zero customized layers.

Not saying its NOT related… I just never caught on to a correlation there. I do know in 2023 it could even happen to a form without customization. So, maybe that’s why I never thought about it being related to the number of layers.

But, I do agree with @aosemwengie1 that some forms in 2024.1 initial testing had to be “refreshed”. But in the cases that I witnessed, it actually supplied an error (not just a blank screen). Something along the lines that it couldn’t load the TransView dataview, or something similar. So, I’m not sure if it was the same problem or not.

But yes, in those cases, the “App Studio Refresh” worked to correct them.

1 Like

This is so funny as we literally run any number of these solutions… it is indictive of the need for some real Quality Checks (QOL for end-users) with regard to the browser. We have MULTIPLE custom layers now and figuring out the work-arounds to minimizing errors has been it’s own education. Personalizations are still a real-problem for custom screens - the new update puts some fallbacks in for this, but it’s not ready for true prime-time yet IMHO.

Our Developer @r0lovic could write a book on nightmare scenarios over the last year. Each update, with regard to layers, makes us anxious with regard to what layer is not going to work, but we have a very good handle on all of this now. A lot of it is informing the end-users of how and what, and setting expectations from the go in training(s).

That being said, we run conversion 191 a lot, especially as we are continuing to add customizations… Rule of thumb, if you get any kind of “Business Layer Exception” error, run 191, as it resets the new published framework and your browser’s cache is certainly going to be wrong… this fixes 90%+ of these errors for us.

We also have a couple of chrome extensions with regard to clearing the browsers cache. That makes it easier for our development team users. We are not quite to production/live yet, but very close.

Hard Browser Reset hasn’t been mentioned but it works in many instances - Ctrl+R or Command+R.

We are now working to make sure that all of the various context menus, menus, collaborate, enterprise search, and “actions” are pointing to our layouts as the browsers get confused with it’s cache when somebody stumbles into an original page layout vs. our custom layout. Redirecting all of this is this week’s project -we have a good handle on doing this now…

Also, sometimes logging out and logging back in fixes things - but this is usually related to the browser cache.

Thanks for putting this together, and I hope to see some new tricks as it evolves.

My best to you all.

2 Likes

One use case - some customizations apply to both the entry and tracker screens, and some are only for one. This can be done in one layer with data rules but its easier to just have two layers.

3 Likes

Yes, my boss pointed that one out. It did seem to help us also, but at the same time, I am never sure if THAT was The Thing that fixed it that day, or just coincidence.

Added this at (current) # 7. Honest question - should it be higher in the sequence?

This might be different than what I am thinking of, which is deleting some local file on the machine (need to check my notes).

Good point. Added that in also at (currently) 4a.

Found a new-ish solution today: Republishing the layer that is in use.

I tried steps 1 and 2. This does work some days, but not today. (AR Invoice Entry is just evil.)

I opened the app without a layer - I did this by deleting that portion of the URL (highlighted below). It opened fine. This tells me that the layer is the issue.

So then I opened App Studio to the layer and republished it, and that worked. No log-out needed.

With layer

Without layer

1 Like

Nice. Add it to the list, i guess, haha. These occurrences at least SEEM to be decreasing on my instances.

Ditto. They are fairly rare here. And usually fast to remedy.

Mentally, yes. Literally, no, I can’t edit the OP - it’s too old. I’d have to beg an admin to do it.

1 Like

Want me to make it a wiki, or add something?

1 Like

Wiki makes sense. I’m not exactly the authority on this, just a compiler of others’ wisdom.

Thank you in advance.

1 Like

Done

2 Likes

Thank you. OP is edited.

2 Likes