Store website broken due to faulty telemetry use
Since the recent store GUI update, about 1/3rd of the store is broken do to an incorrect use of a javascript method. It is somewhat understandable that valve might want to measure performance of their client (in which the necessary flag is enabled by default), but it should never be required in user's standalone browser.

Currently, the search/nav bar, all events pages (such as the nextfest one), and the basket (making it impossible to buy games) are broken. Possibly more. Funnily, on some pages, the method is put inside a try...catch and the search bar on those pages (eg. on the whishlist page) works.

In the file ~/public/javascript/applications/store/main.js the method PerformanceObserver is incorrectly (and unnecessarily) used. It lacks a try...catch statement, and the function crashes if dom.enable_performance_observer flag is disabled in the browser. Please, add the correct try...catch statement to keep the websites working without this flag, or remove the method altogether (even if only for non-steam client user-agents).

Yes, the issue can be mitigated by enabling the mentioned flag, but, while one might trust valve not to abuse this javascript functionality, enabling it in a standalone browser means enabling it for all websites.

.edit:
this is the faulty snippet:
new PerformanceObserver((e=>{ const t=e.getEntriesByType("navigation")[0]; if(t && "responseEnd" in t && typeof t.responseEnd === "number" && t.responseEnd && (0,oo.D)()) { const e = al - t.responseEnd; (0,oo.D)().IncrementStat("storeReactStartup", e), performance.measure("storeReactStartup", { start: t.responseEnd, duration: e }); } })).observe({ type: "navigation", buffered: !0 });
Last edited by WoJo ©; 15 Oct @ 10:48pm
< >
Showing 1-15 of 20 comments
you will get better attention for this in the beta forums

https://gtm.steamproxy.vip/groups/SteamClientBeta/discussions/

it is where they track all of this kind of thing

even if it is in the released version
WoJo © 15 Oct @ 3:34pm 
This issue does not concern the steam client (let alone beta) but their website. Plus, the incompetent support, who tried to blame my ISP (wtf...) despite the fact that I pointed them to the exact javascript line that has an error plus gave them a ready fix, told me to post here.

I have no hope they will fix this bug anytime soon, because the main reason why they moved to CEF was because they don't have competent devs anymore, so I don't really care enough to re-post. If they don't want people to buy from them because they can't bother to fix a single line of code, there are other stores that actually care about money.
Support is outsourced and totally incapable of helping with errors in the Steam app or website. This board is an official dumping ground for tickets they close but Valve employees NEVER post here.

Yes, that first sentence is a little weird, I find it quite strange that hitting the Help button within the Steam client CAN NEVER EVER IN ANY CONTEXT direct you to a person who works at Valve in a capacity to respond to errors encountered within the Steam client. It is totally baffling to me but I suppose I simply have talent and standards.
Originally posted by WoJo ©:
This issue does not concern the steam client

https://gtm.steamproxy.vip/discussions/forum/10/135507548120407092/

What this section is for, and what it is not
If you have come here to propose a suggestion for the Steam client, whether it be a new feature or an improvement of an existing one, or the Steam ecosystem, regarding policies, the store or the community features, you have come to the right place. Please consider searching before posting, as your suggestion may have already been brought up before.
/
The first reply was correct of you having better luck in the beta forum.
WoJo © 15 Oct @ 8:48pm 
Originally posted by William Shakesman:
Support is outsourced and totally incapable of helping with errors in the Steam app or website. This board is an official dumping ground for tickets they close but Valve employees NEVER post here.

Yes, that first sentence is a little weird, I find it quite strange that hitting the Help button within the Steam client CAN NEVER EVER IN ANY CONTEXT direct you to a person who works at Valve in a capacity to respond to errors encountered within the Steam client. It is totally baffling to me but I suppose I simply have talent and standards.
I didn't expect support to fix the issue right away, but I expected them to pass a message to the dev team as a form of a bug report. Instead, I got a "can't help with your network config, go and whine to your ISP" kind of response, which is absurd.


Originally posted by The Living Tribunal:

https://gtm.steamproxy.vip/discussions/forum/10/135507548120407092/

What this section is for, and what it is not
If you have come here to propose a suggestion for the Steam client, whether it be a new feature or an improvement of an existing one, or the Steam ecosystem, regarding policies, the store or the community features, you have come to the right place. Please consider searching before posting, as your suggestion may have already been brought up before.
That sounds to me like this is actually the best way place to put this thread. It concerns a store feature improvement.
Last edited by WoJo ©; 15 Oct @ 10:34pm
Originally posted by WoJo ©:
Originally posted by William Shakesman:
Support is outsourced and totally incapable of helping with errors in the Steam app or website. This board is an official dumping ground for tickets they close but Valve employees NEVER post here.

Yes, that first sentence is a little weird, I find it quite strange that hitting the Help button within the Steam client CAN NEVER EVER IN ANY CONTEXT direct you to a person who works at Valve in a capacity to respond to errors encountered within the Steam client. It is totally baffling to me but I suppose I simply have talent and standards.
I didn't expect support to fix the issue right away, but I expected them to pass a message to the dev team as a form of a bug report. Instead, I got a "can't help with your network config, go and whine to your ISP" kind of response, which is absurd.

It is quite silly but outsourced support means OUTSOURCED TOTALLY, sadly.


Originally posted by WoJo ©:
Originally posted by The Living Tribunal:

https://gtm.steamproxy.vip/discussions/forum/10/135507548120407092/
That sounds to me like this is actually the best way to put this thread. It concerns a store feature improvement.
I will never understand the habit on this forum people have of posting quotes that they do not read for comprehension, but it explains why I so often have to correct them on questions of Valve's stated policies.

Nevertheless, what IS true is that the "Steam Beta Client" forum actually sees Valve employees respond sometimes, the sorts of people who can address specific errors such as these, while this forum will never see them. It may be an idiotic state of affairs but it is the truth here.
Last edited by William Shakesman; 15 Oct @ 9:50pm
Which standalone browser are you using? I am not having the issue with Vivaldi.
Originally posted by William Shakesman:
but it explains why I so often have to correct them on questions of Valve's stated policies.

Odd comment seeing as how you told the OP of the refund warning thread to ignore it despite them posting the actual message from Steam Support.

https://gtm.steamproxy.vip/discussions/forum/10/4751949102179888843/#c4751949102180999647
Last edited by Nx Machina; 15 Oct @ 9:19pm
You intentionally broke a part of the standard JavaScript API all major browsers use, and then were surprised that doing so broke JavaScript on a website.

https://developer.mozilla.org/en-US/docs/Web/API/PerformanceObserver

Mozilla documents this API as being available in all major browsers in the past half-decade.

If you break things, things will be broken. That's just basic cause and effect.
WoJo © 15 Oct @ 10:10pm 
Originally posted by Nx Machina:
Which standalone browser are you using? I am not having the issue with Vivaldi.
Doesn't really matter. The flag is set to true in most common browsers by default.
Originally posted by Ben Lubar:
You intentionally broke a part of the standard JavaScript API all major browsers use, and then were surprised that doing so broke JavaScript on a website.

https://developer.mozilla.org/en-US/docs/Web/API/PerformanceObserver

Mozilla documents this API as being available in all major browsers in the past half-decade.

If you break things, things will be broken. That's just basic cause and effect.
Disabling an optional flag is not "breaking" anything. PerformanceObserver is a telemetry tool that gathers information about how well/bad the application (it's mostly meant for web apps, not websites) performs. Disabling it should not break anything; at best, it should log an error and move on, at worst, it should tell the user to enable the flag (if the method was actually necessary, which it isn't). It is absolutely unnecessary to crash the entire set of functions it the flag is disabled... which is evident due to how the method is actually in a try...catch statement on some pages (eg. wishlist) and those pages work. It's bad coding.
Nx Machina 15 Oct @ 10:12pm 
Originally posted by WoJo ©:
Doesn't really matter. The flag is set to true in most common browsers by default.

It matters because i do not have the issue you are describing on Vivaldi.
WoJo © 15 Oct @ 10:32pm 
Originally posted by Nx Machina:
Originally posted by WoJo ©:
Doesn't really matter. The flag is set to true in most common browsers by default.

It matters because i do not have the issue you are describing on Vivaldi.
That's because you have the flag set to true by default.


Anyway, since they are probably not going to fix it anytime soon, if anybody else has this issue, here's a quick script to fix it client-side:

(function() { 'use strict'; if (typeof window.PerformanceObserver === 'undefined') { window.PerformanceObserver = function() { return { observe: () => {}, disconnect: () => {}, takeRecords: () => [] }; }; } })();
.edit: removed logging for clarity.
Last edited by WoJo ©; 15 Oct @ 10:50pm
Nx Machina 15 Oct @ 10:40pm 
Originally posted by WoJo ©:
That's because you have the flag set to true by default.

I did not mess with the settings causing the issue you have and blaming it on bad coding.
WoJo © 15 Oct @ 10:44pm 
Originally posted by Nx Machina:
Originally posted by WoJo ©:
That's because you have the flag set to true by default.

I did not mess with the settings causing the issue you have and blaming it on bad coding.
It's not even worth responding to that... I don't understand why are you even here if you neither have this issue nor comprehend it.
Nx Machina 15 Oct @ 11:04pm 
Originally posted by WoJo ©:
It's not even worth responding to that... I don't understand why are you even here if you neither have this issue nor comprehend it.

Because it is a discussion forum and when the thread title reads: Store website broken due to faulty telemetry use i pointed out i do not have this issue whereas you deem the issue was relevant to everyone.

You even wrote:

Originally posted by WoJo ©:
Disabling an optional flag is not "breaking" anything. PerformanceObserver is a telemetry tool that gathers information about how well/bad the application (it's mostly meant for web apps, not websites) performs. Disabling it should not break anything; at best, it should log an error and move on, at worst, it should tell the user to enable the flag (if the method was actually necessary, which it isn't). It is absolutely unnecessary to crash the entire set of functions it the flag is disabled... which is evident due to how the method is actually in a try...catch statement on some pages (eg. wishlist) and those pages work. It's bad coding.

I did not change any setting causing it to break.
< >
Showing 1-15 of 20 comments
Per page: 1530 50