Walmart.com continues to redirect to a Walmart sign-in page.
Brave Version 1.56.20 Chromium: 115.0.5790.171 (Official Build) (64-bit)
Brave Ad Block Resources Library - Version: 1.0.56
Status - Component already up to date
operating system: Debian GNU/Linux 11 bullseye (x86-64)
linux kernel: 5.10.0-22-amd64
As a temp solution, add walmart.com##+js(acs, document.documentElement.lang) into brave://adblock custom rule. Report if it breaks anything. Still investigating.
@fanboynz This partially works. But it breaks part of the site and it still has some restrictions.
Two differences are:
On Brave: If I went to add anything to cart, it would immediately bring me to the Sign in or create your account page.
On Chrome: If I add something to the cart, it would put it to the cart and show how many items were there and the estimated total
The navigation menu
Brave:
Chrome:
But if I did it on Chrome, then adding items to cart would show it added. Then I could review the cart with no issues. It wasn’t until I hit the Continue to checkout button that it would bring me to the Sing in or create your account page.
CORRECTION
Just messed with it a bit more. The navigation menu is just broken like 50-70% of the time. If I clicked on the How do you want your items? area it would show something went wrong and I could refresh it. Doing so might load it properly to where it’s the same as Chrome.
So I guess just would require people to refresh if it doesn’t load. And at least the one line gets us past the initial block. But if they wanted to add multiple things to cart and get idea for pricing, they’d be highly restricted.
Other thing is on that How do you want your items? If you go to pickup and then try to change the store, Brave will redirect to the sign in or create your account page, but Chrome will show you complete list of stores and let you pick them.
Does that filter prevent purchasing or searching for items @Saoiray ? If we rolled out the fix, is it better to leave as is or try for this fix?
@fanboynz You mean walmart.com##+js(acs, document.documentElement.lang)?
In a nutshell this bypassed the original redirect, however difference is:
It still redirects if you add something to cart. This doesn’t happen on Chrome and Edge.
You can’t change stores, but you can change stores on Chrome and Edge.
The navigation bars on the landing page sometimes doesn’t load, but it always loads on Chrome and Edge.
Using that is better than nothing, but ideally would want full functionality on the site and that particular filter doesn’t do that. So if it’s possible to figure out how to get full functionality, would be great.
Btw, if it would ever be any help for me to hop on a screenshare or something with you so you can see what I am (assuming you’re not replicating) or just to kind of explain in Brave Talk, I’m always more than willing to try to do so. That holds true for this or anything else I ever speak up on.
This isn’t necessarily an issue. Walmart seems to force people to create an account or log in once it’s time to pay. So we’re all stuck on that when purchasing. Largest issue here is just when it’s forcing people to get to that screen. It’s hitting Brave way earlier and harder for some reason.
I’m unsure that it’s helpful for me to chime in: after adding
walmart.com##+js(acs, document.documentElement.lang)
in “Create custom filters”.
Brave Version 1.56.20 Chromium: 115.0.5790.171 (Official Build) (64-bit)
Brave Ad Block Resources Library - Version: 1.0.56
When I visit the Walmart site using Brave, behavior continues - unaltered - to be: after a few moments I’m redirected to a page that requests either my email address or that I sign in.
Extensions: I temporarily disabled uBlock Origin, NoScript, and Malwarebytes. No joy.
I do appreciate that this is receiving attention; the problem remains unresolved.
This rule was never meant to be a final solution.
What it does it only stops the first redirect, and that’s it.
That means people can browse most of Walmart without having to log in, but it is not a permanent solution.
You can’t change store, you can’t add things to cart, you can’t click too many things and sometimes I had to clear Walmart Cache, in order to make it work or allow cookies.
The thing is, since you are not logging in, you don’t need to add things to the cart, if not, it means you have an account and you don’t have problems to log in.
Eventually this will be addressed, but for now, at least you can search and see the prices of things, if not, you will have to log in and forget about this.
At least the rule won’t break Walmart, so you can log in and use it fine, and still have access to it until the problem is addressed/fixed.
It is just a temporary measure.
The only way you can fix this, manually, is to install a HTTP header modifier extension, and just remove Request header Sec-Gpc and done, whatever Walmart though of doing when they detected that flag is obviously not too privacy like, since it is forcing people to actually get an account and log in to Walmart to use it.
Nobody is going to do this, but it is what will fix the issue since now Brave has to add a setting to disable GPC, only because of Walmart, and that takes a while.
Thanks for your efforts; however: no joy.
I was a few days late installing Brave’s 15Aug2023 update; it’s now installed:
Version 1.57.47 Chromium: 116.0.5845.96 (Official Build) (64-bit)
Brave Ad-Block Updater appears to be current:
Brave Ad Block Updater - Version: 1.0.567
And I added the custom filter you suggested:
walmart.com/##+js(acs,%20document.documentElement.lang)
When I visit Walmart.com, after a few moments I’m still redirected to a page requesting an email address or that I sign in.
Contrasting / comparing: using Firefox (v102.10.0esr) the Walmart.com page opens as expected - detecting my postal code and noting the nearest store. As before, I can search for specific products and the expected drop-down menus are available.
I’ve only tried to visit Walmart.com with Brave and Firefox. Considering that Firefox behaves as expected, this is no big deal for me.
I already explained the issue, read my comment.
It won’t be fixed because it is a HTTP header that gets read by Walmart and ask you to log in.
You either have to install an extension to remove that or wait for Brave to implement disabling it through flags, but that might take longer.
Again, the rule walmart.com##+js(acs, document.documentElement.lang) which I provided and FranboyNZ mentioned here, is only to avoid having the first redirection, which checks the language and then does a ‘locale’ and that’s when the redirection happens.
This obviously will not happen on any other browser because GPC is not supported by any of them, which stands for Global Privacy Control or something like that, some standard that someone made and Brave decided to implement it and walmart is kind of being weird about it.
If you set the HTTP request header to Sec-Gpc: 1 you will have the same problem in other browsers.
You can use many extensions, the most popular ones are modheader (ad suported, fremium), requestly (freemium and full of trackers in their ‘app’), and I use one called Inssman, which is free and open source, but it is manifestv3 which seems to be problematic for Brave at the moment, so you have to disable and re-enable the extension on every browser launch.
There are other small extensions that can do it, just a basic http header modifier will make it.
All it has to have is a way to remove the request header Sec-Gpc
Again, the adblocker can’t do anything to prevent this, because it is a HTTP header, but the custom rule will only stop the first redirection, to make it less annoying, since you can browse around a little more without being asked to log in.
Again, you can’t change store, add things to the cart or anything like that, even sometimes clicking on items might trigger the log in.
Also, you can’t turn the shields off, and Shields have to be in Aggressive for everything to work decently better.
But the rule is just a temporary measure since it is a HTTP header issue.
Thanks for your reply and additional explanation.
Installing one of the extensions you suggest: in other threads I’ve consistently noted the inherent risk extensions pose - especially in Chromium-based browsers like Brave - because they update without the user’s awareness. Good extensions do go bad. I currently have 7 extensions installed. Because I can obtain the functionality I’m looking for by using Firefox to visit Walmart.com, I’m loath to install an additional extension in Brave solely because of this one website.
My concern - mentioned in other comments in this thread - is that other merchants stroll down this same path initiated by Walmart; and I hope Brave’s devs achieve some sort of broad-brush response.
Firefox will have a similar issue when they enable Global Privacy Control
Test Walmart with privacy.globalprivacycontrol.enabled = true in about:config in Firefox
Thanks for the reply and the explanation.
Experimenting, in Firefox, I toggled
privacy.globalprivacycontrol.enabled
from ‘false’ to ‘true’. The Walmart site opened as before - with full functionality. But wait! There’s more! I then toggled
privacy.globalprivacycontrol.functionality.enabled
from ‘false’ to ‘true’. Attempting to visit the Walmart site, I was redirected to the all-too-familiar request for an email address or that I sign in to a Walmart account.
Important note for those who try this: when I reversed both these switches, I had to re-boot Firefox for the reversal to take effect.
As with so many things, I’d been oblivious to Global Privacy Control. I visited their website. It falls under the unfortunate heading: I knew less after visiting the website than before. Saying the same thing differently, Global Privacy Control appears to be “solving” a problem I didn’t have … by creating a problem.
Which leads to: using Brave to attempt to visit the Walmart site is my first encounter with Global Privacy Control. As just noted, for Walmart, with Global Privacy Control enabled, Brave is currently useless. In Firefox, there’s the option (at least for now) to toggle Global Privacy Control off. (Actually, that’s Firefox’s current default.) I hope Brave will offer similar flexibility.
This function is global, so disabling it would affect more than just walmart. So not an ideal situation. The better solution would be to disable sec-gpc on specific problem sites.
Okay for some testers with walmart issues;
@Chocoholic @Sunnybluff @redbike9 @hemel @re9321
Add the following into brave://adblock custom rules: (then save). The reload the main www.walmart.com webpage.
I am seeing similar behavior as walmart.com##+js(cookie-remover.js, sod)
walmart.com##+js(set-cookie, sod, 0)
As another check, test the Walmart login works
Putting the code on “Create custom filters” works for me. Walmart login and other basic features also seems working. Thank you for this. It does help me a lot since I was using two browsers just to use walmart. I really appreciate it.
Hope to see a official solution from Brave.
Brave version: 1.57.49 Chromium: 116.0.5845.96 (Official Build) (64-bit)
OS: Win-10 Pro 22H2 (Build: 19045.3324)
Can you login/logout without issue?
There is “Robot or Human” check occasionally but without that so far no issue. If I face any problem I will inform here.
https://github.com/brave/adblock-lists/pull/1279 give it 24hrs
Thanks all for your help here. The issue is basically that when the GPC (Global Privacy Control) header is set, walmart.com sets a cookie called sod which the client-side code then detects and redirects to the login page. We’re trying out a solution where we:
sod cookieThis seems to solve the redirect issue for us, but please let us know if the website breaks in other ways.