rafaelgomesxyz / esgst

An extension that enhances SteamGifts / SteamTrades.
MIT License
147 stars 23 forks source link

Background page shows nothing on Group/Wishlist/Follow/All page. #1715

Open Eiion opened 3 years ago

Eiion commented 3 years ago

Description Opening the background page it shows nothing/no traffic at all (as in only a blank page) when loading the Group page.

Steps to Reproduce

  1. Go to "https://www.steamgifts.com/giveaways/search?type=group"
  2. Open Background page
  3. See nothing
Eiion commented 3 years ago

I had to change the topic as it turns out the background page shows nothing for any of the pages. I just wanted to see if your update (https://github.com/rafaelgomesxyz/esgst/issues/1710#issuecomment-822882525) had an effect and - again, like yesterday - I got nothing for the Group page. So I went ahead trying any of the other pages but still nothing. The background page just stays empty with apparently no traffic going on (while the pages actually load).

rafaelgomesxyz commented 3 years ago

If you don't click on the Network tab, you can't see any of the traffic. If the pages are actually loading normally, then this is not an issue.

Eiion commented 3 years ago

I am on the network tab by default.

The pages have always been loading "normally" (my normal) - the difference being if that happens faster or slower (as shown in the screenshots to the other issue)

For two Entered pages I just got only two requests... one for 3 and another one for 2 games. That's all for 100 giveaways. Also, have you remoced the disc cache infor being displayed from the background page because that's 95 lines missing right there (considering all of them fetched data from cache). Though, that certainly wouldn't explain the no data for about 20 ALL pages - where there's daily plenty of new giveaways or giveaways for games with outdated (in cache) data.

Also, the console shows this:

DevTools failed to load SourceMap: Could not load content for chrome-extension://ibedmjbicclcdfmghnkfldnplocgihna/lib/browser-polyfill.min.js.map: HTTP error: status code 404, net::ERR_UNKNOWN_URL_SCHEME

Is that related to the issue of the traffic tab showing nothing? I mean it is related to ESGST extension ID.

rafaelgomesxyz commented 3 years ago

It could just be that it's retrieving the information from the cache, so it doesn't need to make any requests. I'm a little confused. Are you saying that the information is not being displayed at all and no requests are being made?

Logs related to SourceMap are always irrelevant, they're just for better error tracking and are only used in development.

Eiion commented 3 years ago

But before the update the background page showed those cases where information was retrieved from the cache (see screenshots posted in other issue) - since 8.8.8 not anymore. So yes, that's what I'm saying. Throughout loading any of the pages (with certainly new giveaways without any cached data) the page stays empty like that: image

EDIT: I just checked and unfortunately the other screenshots do not not display retrieving cached information - I had cut those parts off since I didn't want to clutter the comments with full screen screenshots when only part of wat is shown is relevant. And since I copy pasted the screenshot sections directly from the screenshot tool I don't have saves of the originals. But I guess you know what reports I mean when I say data was shown as retrieved from disc cache (or however it's actually called when the data comes from local storage instead of your server or Steam).

Eiion commented 3 years ago

Ok, I tried again, now that it's 15 minutes later... and all of a sudden, without me changing anything at all the background page (still talking about the Network tab) is displaying data again as expected.

But I've noticed something that seems odd to me: There's three IDs of which requests basically fill the whole page with what to me appears like identical repeated requests after data already has been sucessfully retrieved. I'm sure there's more like these I could find when scrolling through the long list of entries after loading three pages (Followed, Group, All). So here's another screenshot (also showing the before mentioned disc cache entries) - I've color coded requests to the same app IDs: image

rafaelgomesxyz commented 3 years ago

I'm not talking about the Network page, but the SG page itself. Do the categories not appear there, despite the Network page being empty?

I think you're confusing local cache with request disk cache. Information retrieved from the local cache should never appear in the background page. If ESGST is retrieving data from the local cache, it will not make any requests, as expected, because the whole point of having a local cache is to reduce server load. A request disk cache, however, is when ESGST does make a request, but the response from the request hasn't changed since the last time.

The local cache is handled by ESGST, while the request disk cache is handled by the browser. They're completely separate. I hope that clears things up.

And yes, those repeated requests are exactly the issue that I brought up in #1710 when I said that there's something weird happening.

Eiion commented 3 years ago

Oh, ok. I was talking about the Network page only. Sure, the SG page shows up - but the Network page didn't document anything at all of how the SG page got its data. The reason I was checking the background page in the first place was because you've asked me to let you know if I see a difference in request times after the update and the problem was that for about a day I saw nothing on the background page at all (as can be seen in the screenshot in https://github.com/rafaelgomesxyz/esgst/issues/1715#issuecomment-823538465). Hence the report.

Yes, that clears things up. Though my understanding was indeed that these disc cache 1 ms requests were those of the, well, disc cache - locally stored data that doesn't need to be retrieved online. Which to me explained why it's only 1 ms instead of 250 ms to 500 ms or even longer. I mean with a ping of usually around 25-34 ms to servers relatively local to where I am, how can there be 1 ms requests to servers (e.g. yours) which should take a multiple of those "optimal" pings? 1 ms didn't make much sense to me other than in, as it says in the literal sense, cases where information retrieved from "disc cache".

Ok. Well, I'll keep an eye on it to see if those minute long requests keep happening again or if your update fixed that issue.