Interestingly I get a different error when using Google Chrome. (The above example was from Firefox).
We’re not getting the same error from one of our other shotgun accounts, and the one I’m trying it from does have some strict firewalls applied to it so I’m wondering if it could be related to that.
Both errors seems to point to the same issue, with different wording. Both seems to complain about accessing something that is undefined where it should not.
I had a similar issue where I was actively doing things that corrupted the external command cache. My fix around that was to remove the cache completely. You might want to try to remove it (while keeping a backup of it so we can look at it) so you can know if it’s caused by a corrupted cache.
I had tried removing the entire Shotgun folder in %AppData% which I would presume would remove any caches or potentially corrupted files. However I still get the results seen above after having cleaned things out and started fresh…so I’m not sure that’s what’s causing this.
Are you getting any errors in the chrome/firefox javascript console?
If you are please could you post them, feel free to send a support ticket in for that if you’d prefer not to post it publically.
I’ve tried signing in and out, and even deleted the entire Shotgun folder in %AppData% and I still get this result. Is there anywhere else that Sg might be storing authentication information other than in %AppData%?
Let me know if there’s anything you understand from this that we can troubleshoot. Unfortunately I’m not really able to fully understand how to troubleshoot these messages.
Thanks
In the chrome output, I’m seeing You are not authorized to make browser.....
Are you logged in as the same user in both the browser and SG Desktop?
Looking at the code, I think it would be good to get a copy of your tk-desktop.log with debug enabled. Please could you pop a support ticket in with that?
I’m sorry your’ having issues with this!
… well this is embarrassing . It would appear that turning the machine off and on again seems to have solved the issue!
I did also change my SG password to make sure that there were no “residual” credentials being stashed somewhere, so that might have been part of it too.
Either way it would appear that the issue has resolved itself!
Not at all, this is of interest. I’ve heard of similar issues before, they also have seemingly gone away as well, which has meant we’ve not got to the bottom of it. I’m not sure what triggers this.
True I suppose. It is frustrating how many tech issues (in all area’s not just Shotgun!) can be solved with the “Have you tried turning it off and on again” approach!
I’m seeing this exact problem, down to the differing error messages depending on whether I’m using chrome or firefox.
All my apps/frameworks are up to date.
I’ve noticed that the menu loads normally if I click through to the detail page from a list page i.e. Shots. However if I refresh the page or load it by copy-pasting the link to a new tab, the action menu errors as Tom experienced.
Also, this only seems to happen on custom pages. It always loads fine when using the default Overview page.
I spent yesterday doing a deep dive into the Shotgun javascript using firefox dev tools. I believe I’ve found the issue.
base.js:fetch_actions() is called multiple times during page load, but every call returns the error “this._actionsCache is undefined”. This is because this._actionsCache is defined by this.client._clearActionItemsCache() which only seems to execute once the page has finished loading. The reason the actions menu works on some pages and not others is that some widgets (i.e. SG.Widget.StreamDetail, used for the default Overview entity page) sets an on_click handler that calls fetch_actions() every time the action menu is opened. As this call happens after the page has finished loading, this._actionsCache is now an empty Object and the call succeeds. Pages that do not implement this handler (i.e. SG.Widget.Canvas.Page) rely on the calls to fetch_actions that occur during page load which as we’ve established cannot succeed.
I believe the fix is to ensure this._actionsCache is defined when the page widget is first instantiated.
This is fantastic detective work David. Autodesk, Philip, any chance you’ll implement a solution?
Same here: we’ve got the same error message in the same situation as others on this thread. Deleting the cache and reinstalling both SG create and SG desktop didn’t solve the problem.