Styles not loading

aMerkuri

aMerkuri

Posts: 71   +24
Styles are not loading when navigation back from article to homepage. Happens only when I am authenticated (Elite).
  • Same behavior under incognito.
  • No extensions loaded.
  • Tried different networks (home, work, wifi, vpn)
  • No console errors
  • No network errors

Google Chrome 87.0.4280.66 (doesn't work)
Microsoft Edge 87.0.664.47 (doesn't work)
Android Chrome 86 (doesn't work)
Firefox Developer Edition 84.0b6 (64-bit) (works)

Page source has only contents of <body>. Partial HTML was only delivered.
 

Attachments

  • ts.PNG
    ts.PNG
    805 KB · Views: 7
  • ts2.PNG
    ts2.PNG
    690.8 KB · Views: 6
  • ts3.PNG
    ts3.PNG
    91.7 KB · Views: 6
Nothing changed for me. Is it possible to authenticate as my user?
Not sure what else I can provide for debug.

Safari 14.0 is OK.
AFAIK It didn't behaviour like that before when I wasn't Elite subscriber, it may be a coincidence though.

Edit:
Created new user (@Merkuri), same problem for me when logged in.
The only difference when page renders correctly (on the right) has content-length header.

1606825338682.png
 
Last edited:
This url is okay.
I connected through VPN:
North America, South America, Asia works.
Europe doesn't work.
 
@Julio Franco
There is no such element #js_eu_consent
setting isEuropeanUnionCountry to false doesn't trigger jQuery error and navigating back is no longer broken.

Did you test in European region?

Edit.
Looks that code part was used with older consent you had previously and forgotten to be cleaned up. Interesting that this small error breaks entire site, I haven't seen anything like this before 😂

I still don't understand why it only happens when I am logged in.
 

Attachments

  • ts4.png
    ts4.png
    256 KB · Views: 3
Last edited:
aMerkuri said:
@Julio Franco
There is no such element #js_eu_consent
setting isEuropeanUnionCountry to false doesn't trigger jQuery error and navigating back is no longer broken.

Did you test in European region?
Click to expand...

:dizzy:

You got us there. Indeed, we introduced a bug (and failed to clean up our JS) when we modified our latest EU consent. I was able to replicate and fix the error when I tried to navigate the site from Europe using a VPN. We did test before, and it doesn't seem to affect everyone, which is weird. But anyway...

It's now fixed, and yea, I owe you a beer! 🍻
 
  • Like
Reactions: aMerkuri
I am having a similar problem, but not because of a bug of website. It seems that loading of CSS depends on the loading of quantcast.mgr.consensu.org. Since consensu.org is an advertising company/organization, they get blocked by pfBlockerNG in the ADs category:

DNSBL-HTTPS,Dec 14 19:20:38,quantcast.mgr.consensu.org,192.168.32.10,Unknown,DNSBL,DNSBL_ADs,quantcast.mgr.consensu.org,Adaway,-

Obviously, such breakage due to DNS blocking applies to all browsers. I've tested Edge and Firefox, and the behavior is same. If I turn off pfBlockerNG everything loads just fine.

If we can make loading CSS not dependent on consensu.org, that would nicely resolve the problem, though I wouldn't argue you have to since that started from me blocking ads. Just posting it here in case others run into same.
 
Thanks for the feedback @wujj123456. In this instance, it's not really up to us, but the blocker that is targeting the script. As much as we hate to, we are obliged by law to use some form of GDPR consent form -- in this case the aforementioned quantcast.mgr.consensu.org.

As far as I can tell, the consent script is not at all tied to the CSS file, but blockers act in mysterious ways, so who knows how it's making that connection.

On the upside, you're an Elite member, so the Quantcast script shouldn't load at all for you. Or is it?
 
  • Like
Reactions: wujj123456
Julio Franco said:
On the upside, you're an Elite member, so the Quantcast script shouldn't load at all for you. Or is it?
Click to expand...
Right, once I logged in I don't see Quantcast getting blocked or exists in source, but the style is still broken. I must be wrong then and it can't be Quantcast.

The only thing that's still getting blocked each time I force a reload are chartbeat and googletagmanager. Those two things are universally disliked by all blockers it seems. They show up in uBlock Origin and uMatrix too. However, only blocking DNS breaks the style. Otherwise, the site still loads just fine with error messages in console saying the specific scripts failed to load. Looks like the behavior of DNS blocking the domain is different from addon blocking the script, but I am not a web developer to know why.

Anyway, unless you believe those two shouldn't even load after I logged in, it's not worth your time fighting my blockers. Appreciated your previous reply. :)
 
  • Like
Reactions: Julio Franco
You must log in or register to reply here.

Similar threads

T
TechSpot site loading slowly when logged in?
Replies
0
Views
1K
Theinsanegamer
T
midian182
Card game creator says it paid an AI artist $1,500 per hour to create its images, stating "no one is on his level"
Replies
17
Views
253
Puiu
Puiu
Daniel Sims
Star Citizen developer showcases impressive technological progress in new trailer
2
Replies
27
Views
840
m3tavision
m3tavision

Latest posts

Back