Person Pages Broken ?
This morning I discovered that all the Person Pages I try to view have stopped working, resulting in "Oops, something went wrong. Please refresh the page." I've tried new ones, old ones, saved links, and they all produce the same result. Can somebody else please try so I can try so I can work out if it's just me.
P.s. I can view Tree Pages, and so far everything else I've tried, but not Person Pages.
p.p.s It seems that merging is also broken because the indvidual person records are inaccessible. E.g. having constructed the URL https://www.familysearch.org/tree/person/merge/verify/M9MF-LY8/GGH4-2Q1
It fails with the same message "Oops, something went wrong. Please refresh the page."
Further: It seems that the entire structure is broken below and including https://www.familysearch.org/tree/person
The "Lite" version still allows access to a person page, to edit some details e.g. https://www.familysearch.org/tree/lite/person/M9MF-LY8
Answers
-
They're working fine for me.
Have you done the usual song-and-dance (try a different browser, clear cache & cookies, update browser)? No, it doesn't make much sense that stored files would break the entire /tree/person section and only that section, but the ways of the web are unfathomable.
1 -
Thanks @Julia Szent-Györgyi It's good to know it's working for somebody. I've tried the song-and-dance, but I have only one browser that will work with FamilySearch and that's Chrome. I haven't changed anything since yesterday and I've tried clearing the cookies/cache etc. and logging in through different methods to see if it makes any difference. So far no luck. The workaround through "Lite" is a temporary way forward to edit some details but I can't merge.
0 -
I usually use Firefox for my Family Tree work but just noticed I'd signed in via Chrome today! Again, all is working okay for me. Hopefully, just a temporary issue for you. Always annoying when you appear to be the only person having a particular problem - it has certainly happened to me occasionally.
1 -
Sounds strange that you can only use Chrome to access Family Search. I almost always use Safari, occasionally use Firefox, and only use Chrome to test appearance or something. That brings up the very first step in trouble shooting. What type of device are you using, what model, and what production year? What operating system and version? What browser and version?
Since the page isn't broken for three of us, it may be that your setup is the problem. As I understand it, the Lite version is deliberately designed to be as simple as possible and use as primitive programming as possible to allow access by even the most obsolete set up.
3 -
I've accessed assorted pages this morning in both Chrome and Firefox, Windows 10, all updated to the newest iteration, without issue. I often have 2 windows open to FS - one in Chrome and one in Firefox. If I'm working in Beta, I usually do that in Edge. No issues in any today.
2 -
Thanks for all your comments. Re: Browers. I'm using Chrome on a MacBook Pro with El Capitan, and the only browser that I can run and get to work with FS is Chrome 85. There are too many 'modern' facilities in the current version of FS to work with any of the other browsers that will actually load and run on El Cap. I'm not likely to go out and buy another computer so I will persevere to try and isolate the issue.
0 -
El Capitan is macOS 10.11 and was last updated July 9, 2018. The current version is Sonoma 14.1.1.
The current version of Chrome for a Mac is 119.
I hope you can get things working again, but it sounds like the latest version of the person page, the one with the new fonts, was the last straw.
3 -
@Gordon Collett Thanks, yes I know it's an old machine and OS, but it's a 17inch screen and resilient. Newer models suffered with graphics chip failure and the newer operating systems and applications look like they were designed in the kindergarten. I prefer progress and improvement rather than change.
I was not aware of the font changes that you mention. Could it be that these new fonts are loaded from a third party ? Normally the OS or browser would use the closest substitute font, but it won't be able to do so if the font is loaded via a script which fails due to 3rd party access restrictions. I can't load any of the pages in the /tree/person/ branch, so I am unable to view the source of the completed page to verify this hypothesis.
I think I will have to build an entirely fresh system on an external drive with nothing but Chrome and then disable all security (i.e. 'allow all') to see if the person pages load. If they do, then I'll have to erase it and start again, with normal levels of security and gradually remove the security restrictions until it works.
Update: The issue might be due to the failed interaction with the third party sentry.io. The pages that won't load properly have the variable SERVER_DATA.sentryDSN set to a value, and the pages that will load have the same variable set to a null string. One of the privacy lists used by adBlock has two entries: ?sentry_key= and ?sentry_version= which might be blocking the call to https://o57980.ingest.sentry.io that contains these elements. I can ping the target domain successfully, but can't load the associated page via Chrome. Adblock loads these privacy lists on every restart and at intervals, so If these two elements were added two days ago, it would have been invisible to me, and could have led to the mysterious failure. It's also possible that these restrictions were always present, but that the sentryDSN variable was nul until a recent update in the FS pages to set it to a value, and that has led to the call failing and a promise chain not being completed. Need somebody in technical to review the changes to the page to clarify whether the variable SERVER_DATA.sentryDSN was altered on 16th/17th November.
0 -
OK, I've turned off all privacy lists, and the call to https://o57980.ingest.sentry.io is now not shown as blocked in the network waterfall plot. The person page load still shows the 'something went wrong' message , and any attempt to load the https://o57980.ingest.sentry.io/api/4274450/envelope/... content directly in the browser fails. Presumably something else is causing the blockage.
Further digging reveals that the code in https://edge.fscdn.org/assets/static/js/77376.cbf28107c3bb9af2.js contains a whole mess of functions in tree-person-r9/node_modules/@fs. Can someone let me know if these are recent additions or changes ?
0 -
Hello,
have exactly the same problem. Started two days ago, everything else works but can't open any individual pages.
I use Chrome, and have done without issue for years.
And yes, I have an old computer (Mac 10.1), but it's not been an issue till now. What's changed in the last 2 days?
And just to say, since the refurbishment of the site some months ago, it's all been very glitchy, either gets really (really) slow at peak usage times to the point where I give up trying to do anything ; or pages start to refresh endlessly all by themselves (sometimes I can stop that by refreshing a page myself, but not always).
Frustrating.
But for now no idea what to do about this problem ... will this right itself, or does something need to be done ?
0 -
@Udo Fischer Wow, I'm not alone. Can you disclose whether you use an ad blocker and if so, is it set to use privacy lists that automatically stay updated ?
@Gordon Collett I have re-discovered why I stopped using Safari. Every new tab effectively starts a new instance of the browser and creates separate caches. FS pages have a huge payload so after half a dozen tabs are opened the mac memory pressure goes off the scale and the machine grinds to a halt.
Further: It's not ad blocker dependent. I've now got exactly the same result as with Chrome, but using a new install of Opera version 76. The network waterfall shows the failure to load https://o57980.ingest.sentry.io/api/4274450/envelope/?sentry_key blah blah. Since I can ping this domain, it's not the machine or it's settings. The browser has no ad blocking so I'm left thinking that the issue is buried somewhere in the gunk served up with the page. I haven't yet finished building a clean external system disc to try the 'allow all' browser experiment to discover if I can get a build that will work. Fatigue level now at 80%.
Further further: While waiting for the external disc to finish building, I've managed to get a person page to load using Opera 89 on the existing El Cap build. The network waterfall shows that the sentry.io call failed, but the page loaded. I now need to record Chrome and Opera 89 and compare side-by-side.
Further further further: Noticed that Opera 89 uses a VPN tunnel by default. Will try to find out if that's the reason for success.
0 -
I have the same issue with failing person pages on a Chromebook with Chrome Version 91.0.4472.167 (Official Build) (64-bit). All other pages seem to work fine with the exception of the rootstech registration page. The person pages work fine in FF.
0 -
Still working on it ...
I have disabled all ad-blocking and privacy tools on Chrome to no effect. I have replicated the settings that Opera is using on Chrome but still not been able to make it work. Opera is not set up up as "Allow All", it is set to only allow javascript from specific domains and the same for cookies. This matches the settings on Chrome. In short, Opera works and Chrome doesn't and yet it did until the 17th November.
Comparing the network waterfall diagrams: The timings are different between Chrome and Opera and there is a distinct difference between the page served to Chrome and the page served to Opera. The delivery system must be using browser credentials like the user agent string to modify the content.
One obvious difference is that the page that is served to Chrome includes a dynatrace script that's embedded in a script delivered from edge.fscdn.org. This script calls a Ruxit agent via dynatrace. The same page served to Opera contains a different script served directly from js-cdn.dynatrace.com. These scripts are not vital to the function of the page, so they *should not* cause it to fail.
Then there's the sequence in which the elements load. On Chrome by the time the 77376.cbf28107c3bb9af2.js script has loaded 1.2 seconds has expired, whereas on Opera it's only 325ms.
After that it gets wierd. The font k00.woff2 loads on Chrome and is the only font loaded, whereas on Opera all the fonts p00.woff2, k00.woff2, k01.woff2, k27.woff2, and 1300.woff2 are shown as stalled and are not visible in the preview. This might be because the Chrome page has been flagged as timed out and the only font loaded is to display the error message. The opera page is not timed out, so it proceeds and disregards the missing fonts because they can be substituted. Hypothesis.
My next step is to install a tool to change the User Agent string to see if I can get Chrome to load the same page as Opera gets served.
Update: I can't load a User Agent switcher onto Chrome because the Chromwebstore refuses to identify the browser as Chrome so all extensions are "unavailable". If this is because the webstore doesn't recognise the user agent string then it effectively scuppers any further investigation at my end. I can't even read the current user agent string to try it with Opera to see if that causes it to break. The only thing I have been able to ascertain is that the working browser, Opera 89, is at the same development state as Chrome 103, whereas the latest version of Chrome for El Capitan is 85.
0 -
Further update: The webkit used in the working version of Opera and the failing version of Chrome is the same, 537.36, so in theory the two browsers should behave the same way. This could add some merit to the hypothesis that the difference between the served pages is the cause of the problem. It would be a lot easier to analyse if there wasn't so much bloat.
0 -
@LDS Search Test You might want to post in the New Person Page group where the developers are still active.
1 -
It's fascinating to read your analysis even though I don't understand ninety percent of it. Your comments certainly make it clear why a feature requested by users can take months to show up. I'm a bit curious about your reference to bloat. Is this non-functional code that should not be there at all or design features that you view as unnecessary or background routines that are performing what you view to be unnecessary functions?
2 -
Looks like older Chrome versions don't support some of the newer functions. I tested in Chrome version 119 and I had no issues. In Chrome version 91 I see this error a couple of times on failing pages.
instrument.ts:145 TypeError: Object.hasOwn is not a function
I guess that the font changes deployed on 16 November broke things.
0 -
Here are few nuggets of info to see if they help.
sentry.io has been on the site for more than a year. The New Person page had it from the beginning. Less likely the cause.
The new Noto Sans Font is being pulled from https://foundry.familysearch.org/Foundry/ it is set up to only download the sections of the font you need to display the page.
1 -
I have the engineers looking into this. However, as mentioned above, it does seem to be with older browsers which are technically outside the scope of what FamilySearch supports. https://www.familysearch.org/en/help/helpcenter/article/which-internet-browsers-are-compatible
From what I can tell some of the more recent versions are:
Safari 17 (on iOS 17)
Chrome 119
Firefox 119
1 -
@Áine Ní Donnghaile Thanks for the pointer: I was unaware that there was such a group.
@lyleblunttoronto1 Agreed, sentry.io does not cause the fault. Re: font, it should not be possible for a font to cause the fault, my assumption was that the font might be loaded by a script which was failing or taking too long.
@Gordon Collett Re: Bloat. My definition is anything that is not associated with the purpose of the page. I understand that there is a need for assistive functions to help with error detection and correction. But when it expands to the point that it becomes difficult to analyse a problem because the of the sheer magnitude of additional code, often involving 3rd party content and servers, then it fits my definition of bloat. The actual necessity of such content is easy to discover. While trying to find the cause of the original issue, I configured my computer and the working browser to only allow the absolute minimum of content to see if I could locate which part was the cause. I found that the page worked on Opera without all of the additional content. By re-enabling all this extra code, one might expect that it would flag the cause of the issue, but it doesn't, so it's not fulfilling it's purpose. From this very simplified point of view, it's just unnecessary.
@ketherin - c Can you ask whether the browser-dependent content selection criteria was changed between the old and new versions of the page. It might be the case that the older browser is cabaple of working, but the wrong content has been selected due to the failure to correctly identify the browser.
0
