- Jul 5, 2019
- 245
- 126
As the title says. No, I haven't tried another browser because FF should be supported.
Is this bug being worked on? I saw a few other threads while searching that report the same ongoing issue for a while now.
@BassTrackerBoats -- I just edited this. I needed to open developer tools and the form had "display: none". This should be "display: block" or whatever attribute you guys normally use. I saw an xf_token related error and something to do with a cookie. Without look at BHW team's code I'm not sure and only spent a minute on it.
---
<form action="/posts/18659987/edit" method="post" class="block" data-xf-init="attachment-manager post-edit ajax-submit" style="display: none;">
should have:
<form action="/posts/18659987/edit" method="post" class="block" data-xf-init="attachment-manager post-edit ajax-submit" style="display: block;">
---
Another quick look and it's due to an adblocker, but that should not impact the functionality on the site. The way the GET request is being delivered has an incorrect attribute. Someone needs to add the SameSite attribute to the cookie set.
Reproducible by enabling uorigin, clicking edit, and you'll see what I'm talking about. Disable uorigin (or any efficient ad blocker) and you'll be able to edit. Check the console and network tab when clicking edit with uorigin enabled to troubleshoot.
---
Cause of problem (the infamous CORS / SameSite policy):
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://static.cloudflareinsights.com/beacon.min.js/vcd15cbe7772f49c399c6a5babf22c1241717689176015. (Reason: CORS request did not succeed). Status code: (null)
https://dotcomconsultancy.advertserve.com/js/libcode3.js
--
Blocked by uorigin and most blockers that utilize: https://pgl.yoyo.org/adservers/
Explicity deny which is used by BHW:
advertserve.com
---
Anyways.. shouldn't have required JS served after the ads since when it fails it breaks the later loads which are required.
Is this bug being worked on? I saw a few other threads while searching that report the same ongoing issue for a while now.
@BassTrackerBoats -- I just edited this. I needed to open developer tools and the form had "display: none". This should be "display: block" or whatever attribute you guys normally use. I saw an xf_token related error and something to do with a cookie. Without look at BHW team's code I'm not sure and only spent a minute on it.
---
<form action="/posts/18659987/edit" method="post" class="block" data-xf-init="attachment-manager post-edit ajax-submit" style="display: none;">
should have:
<form action="/posts/18659987/edit" method="post" class="block" data-xf-init="attachment-manager post-edit ajax-submit" style="display: block;">
---
Another quick look and it's due to an adblocker, but that should not impact the functionality on the site. The way the GET request is being delivered has an incorrect attribute. Someone needs to add the SameSite attribute to the cookie set.
Reproducible by enabling uorigin, clicking edit, and you'll see what I'm talking about. Disable uorigin (or any efficient ad blocker) and you'll be able to edit. Check the console and network tab when clicking edit with uorigin enabled to troubleshoot.
---
Cause of problem (the infamous CORS / SameSite policy):
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://static.cloudflareinsights.com/beacon.min.js/vcd15cbe7772f49c399c6a5babf22c1241717689176015. (Reason: CORS request did not succeed). Status code: (null)
https://dotcomconsultancy.advertserve.com/js/libcode3.js
--
Blocked by uorigin and most blockers that utilize: https://pgl.yoyo.org/adservers/
Explicity deny which is used by BHW:
advertserve.com
---
Anyways.. shouldn't have required JS served after the ads since when it fails it breaks the later loads which are required.
Last edited:
