Open Bug 1897563 Opened 4 months ago Updated 4 days ago

Bugs on homedepot.com in all FF versions since 124.0.2

Categories

(Web Compatibility :: Site Reports, defect, P1)

Product:
Web Compatibility
Component:
Site Reports
Version:
Firefox 126
Type:
defect

Tracking

(Not tracked)

People

(Reporter: randy, Unassigned)

References

(Depends on 1 open bug,
URL
)

Details

(Keywords: webcompat:site-report, webcompat:site-wait)

User Story

platform:windows,mac,linux
impact:site-broken
configuration:general
affects:all
branch:release

Attachments

(3 files)

run.py
1.11 KB, text/x-python
Details
about:support
41.11 KB, text/plain
Details
video demonstration.webm
6.92 MB, video/webm
Details
Attached file run.py —

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:126.0) Gecko/20100101 Firefox/126.0

Steps to reproduce:

Browse to any product page on the homedepot.com website and the main product information will flash and then go gray instead of loading properly.

Additionally, attempting to login results in an error message after submitting an email address on the login form:

We're sorry. There was a temporary technical issue. Please try again later.

I've confirmed this behavior on my primary system with my normal user account as well as in a live boot-from-USB system booting Ubuntu 22.04. I've confirmed it from different networks.

I've tested all the way back to version 120 with each version set to use its own new profile. Versions since 124.0.2 demonstrate the bugs. My primary browser is:

Mozilla/5.0 (X11; Linux x86_64; rv:126.0) Gecko/20100101 Firefox/126.0

Chrome does not demonstrate this behavior.

I've attached the Python script I used to download and run previous FF versions. URL of the page I've been using on the homedepot site is that script.

Actual results:

Product photos and primary descriptions on product pages do not load. The login form does not work.

For the product pages, the correct content flashes and then disappears.

Expected results:

The pages should work and I should be able to login.

Hello, thank you for the bug report!
Unfortunately I could not reproduce your issue. I had no trouble signing in and the product pages were rendered well. Would you be so kind as to answer a few questions so we can investigate this further?

Moving the Product to ‘Core’ and Component to ‘Graphics’. Please change if there’s a better fit, thank you.

Component: Untriaged → Graphics
Flags: needinfo?(randy)
Product: Firefox → Core

So...for most of the past week the product pages worked fine and I was able to log in. But today both malfunctions were back. I did some additional testing including what was requested:

  • v126 from Mozilla apt (my default browser)
    • Troubleshooting mode: bugs present
    • Clear all site data: bugs present
    • New profile: bugs present
  • Booted to live Ubuntu 22.04 version, refreshed snap to latest (126.0.2 I believe): no bugs
  • Nightly
    • New profile: no bugs
    • Existing profile previously used by FF 126.0 that showed the bugs: no bugs
  • Chrome: bugs present
    • Version 125.0.6422.60 (Official Build) snap (64-bit)

I've troubleshooted a lot of bugs in my time. I've never seen anything like this. Very open to additional suggestions on how to help find the root cause of this.

Flags: needinfo?(randy)

Another interesting data point: I just installed the snap version of Firefox and used it to browse the HD website. I tried it with a fresh profile and a copy of my existing default profile. No bugs.

FWIW: I started to use the HD site this morning without problems. A short time later the bugs are back. Insane. :O/

The severity field is not set for this bug.
:bhood, could you have a look please?

For more information, please visit BugBot documentation.

Flags: needinfo?(bhood)

Today I discovered a 100% way to replicate the issue... at least today considering how almost random this issue is. We'll see if it persists, but I figured I should document my findings, and even possibly record a video if this continues to be reproducable in the coming days & weeks

  1. Boot the live ISO of Linux Mint 21.3 Cinnamon (non-edge, though maybe edge will do it too?)

  2. Set your desktop resolution to one of the following (not an exhaustive list＊):

  • 800x600
  • 1360x760 with 125% user interface scaling
  • 1920x1080 with 200% user interface scaling

  1. Open the synaptic package manager, refresh the packages, and update the firefox package to 126.0.1

  2. Launch your newly updated Firefox, making sure it's a maximized program window

  3. In Firefox, navigate directly to: https://www.homedepot.com/p/TRICKLESTAR-1-Outlet-Power-Switch-TS2101/304023001

I was able to have this always result in the images failing to load.

＊to clarify, the Cinnamon desktop environment also has a "Text scaling factor" setting in the program "Font Selection" which can be sort of used as a way to achieve fractional scaling on large resolutions without the performance hit. In this case, with a resolution of 1920x1080, setting the font size to 1.8 and then, in Firefox, setting the about:config setting layout.css.devPixelsPerPx to 0.7 would also result in the issue occurring despite the effective resulting size being equivalent to a 1523x857 screen without any scaling.

  1. Open the synaptic package manager, refresh the packages, and update the firefox package to 126.0.1

Just to clarify: Since it's not super-obvious how to mark a package to be updated in Mint's version of Synaptic, the trick is to double-click on the name of a given package.

NM64...wow, thank you. Resolution dependent, never would have occurred to me.

I run Cinnamon DE and when I'm not plugged into external monitors, I run 2256x1504 at 150% scaling.

I tested tonight and the HD link you posted didn't load correctly initially. I then dropped my scaling to 100% and that fixed it. Bumped back up to 150% and it was still working correctly.

Testing at 800x600 with the stand-alone builds from Mozilla's FTP server using the same Mint 21.3 Cinnamon live ISO session, I found that 125.0.3 actually worked fine and the issue was introduced with 126.0(.0).

(I also tested 127.0(.0) from the FTP server and found a variation of the issue—images won't render in unless you scroll down. We'll see in the near-future once that version is available through the package manager if this behavior persists, at which point I'll do my gamut of tests with various resolutions and scaling settins)

It's worth noting that this issue seems to have some "stickiness" in that, once the issue occurs, it seems to persist even with configurations that previously would have worked fine—perhaps it has something to do with the browser cache? This is why I made sure to test with a live ISO and I rebooted when testing a different version.

I'm still getting the exact same behavior with 127.0(.0) when updated though Mint's package manager (though, admittedly, I only just quickly tested via the "800x600 desktop resolution" method)

Unfortunately I could not reproduce your issue. I had no trouble signing in and the product pages were rendered well. Would you be so kind as to answer a few questions so we can investigate this further?

Now that I've verified that my method for causing the bug was not a fluke and continues to cause the bug, the real question is: does this still qualify for "NeedInfo"?

I just discovered that my trick of using a desktop resolution of 800x600 only occurs on Linux—doing this on Windows will have the web page's product images still render correctly.

I'm now on 127.0.2. Today the bug is back on HD's site. Product content appears briefly and then disappears. But, this time, changing my display settings didn't resolve the problem right away. I tried different scaling settings and resolutions all the way down to 800x600 and still the product info remained blank.

I then did two things in combination that seems to have fixed it, not sure which one or both are necessary. I hit 1600x1200 resolution and I opened a private window and then a tab to a HD product page. That page loaded correctly and then I went back to the main (non-private) window I had been using previously for testing, refreshed the page, and the product info was now displaying accurately.

Is "needinfo" still accurate for this bug?

And I can similarly say that simply doing my trick of running a desktop resolution 800x600 on a live ISO also confirms that nothing has changed and the issue still exists within the Linux version of 127.0.2.

It may be worth mentioning that another software developer theorized that it could be due to mathematical rounding differences or something in terms of why it'd happen on Linux but not Windows.

Randy and NM64, thank you so much for the detailed steps and information you both provided!

I managed to reproduce the rendering issue on both Firefox 128.0b9 and Firefox 127.0.2 on Ubuntu 22. However, it’s worth noting that on Firefox 128.0b9 the issue is intermittent(compared to 127.0.2 where it reproduces 100% of times). Firefox Nightly 129.0a1 seems to be unaffected whilst using the same resolution settings.

Preconditions:

  • VPN set to US;
  • Have your OS resolution set to 1368x768;
  • Fractional Scaling Enabled and set at 125%;

Reduced STR:

  1. Launch Firefox.
  2. Navigate to https://www.homedepot.com/p/TRICKLESTAR-1-Outlet-Power-Switch-TS2101/304023001

  • Expected results: Main product content is rendered correctly.

  • Actual results: Product page flashes and main product content is not rendered.

Setting as NEW so the developing team can have a look.

Status: UNCONFIRMED → NEW
Ever confirmed: true

Do you know if the results were different when using 800x600 compared to 1368x768 with 125% fractional scaling? I only ask because there is a Firefox fork that has the same issue but only 100% of the time at 800x600.

I can reproduce this on my Ubuntu laptop using 127.0.2. Glenn, can you please evaluate the Severity on this?

Severity: -- → S3
Webcompat Priority: --- → ?
Component: Graphics → Graphics: WebRender
Flags: needinfo?(bhood) → needinfo?(gwatson)
Priority: -- → P2

Could you please go to about:support, click "copy text to clipboard" and paste it as an attachment to this bug?

Flags: needinfo?(randy)
Attached file about:support —
Flags: needinfo?(randy)
Flags: needinfo?(gwatson)

I'm experiencing the same behavior on Firefox Version: 128.0+build2-0ubuntu0.20.04.1

  • OS Distribution: Xubuntu xfce4
  • Description: Xubuntu 20.04.6 LTS
  • Linux system 5.15.0-113-generic #123~20.04.1-Ubuntu SMP Wed Jun 12 17:33:13 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux 128.0 (64-bit)

The bug occurs on any homedepot.com individual-product-specific page I've tried. It does not occur on pages that are not specific to viewing/ordering a specific product. It occurs independent of display resolution setting mentioned in previous comments. I've captured video of the behavior and have a debug console log of errors occuring on the offending page but it looks like I'm not allowed to attach them here so I'll paste the debug log for lack of an attachment option.

The debug console log has entries related to preload of images being ignored and WebGL failures which seem like they'd be related to this bug.

The pasted debug console log is for url https://www.homedepot.com/p/65-Watt-Equivalent-BR30-Flood-Light-Dimmable-CEC-Title-20-Contractor-Pro-Pack-LED-Light-Bulb-Soft-White-2700K-48-Pack-FG-04357/325510353:

Firefox Debug Console Log

Some cookies are misusing the recommended “SameSite“ attribute 2
Some cookies are misusing the recommended “SameSite“ attribute 161
Cookie “THD_NR” has been rejected for invalid domain. 325510353:85:58
This page uses the non standard property “zoom”. Consider using calc() in the relevant property values, or using “transform” along with “transform-origin: 0 0”. 325510353
Failed to create WebGL context: WebGL creation failed:

  • WebglAllowWindowsNativeGl:false restricts context creation on this system. ()
  • Exhausted GL driver options. (FEATURE_FAILURE_WEBGL_EXHAUSTED_DRIVERS) sync.js:2:89416
    Failed to create WebGL context: WebGL creation failed:
  • WebglAllowWindowsNativeGl:false restricts context creation on this system. ()
  • Exhausted GL driver options. (FEATURE_FAILURE_WEBGL_EXHAUSTED_DRIVERS) sync.js:2:89439
    Preload of https://images.thdstatic.com/productImages/86f83e75-c78a-4654-9d85-cbef0090017e/svn/led-light-bulbs-fg-04357-64_600.jpg was ignored due to unknown “as” or “type” values, or non-matching “media” attribute. 325510353
    Preload of https://images.thdstatic.com/productImages/03d0d8c7-e10a-4d70-90d1-0cb1170c181b/svn/led-light-bulbs-fg-04357-e1_600.jpg was ignored due to unknown “as” or “type” values, or non-matching “media” attribute. 325510353
    unreachable code after return statement hRgcB:1:217171
    Use of the orientation sensor is deprecated. 325510353:97:15770
    Use of the motion sensor is deprecated. 325510353:97:15770
    InstallTrigger is deprecated and will be removed in the future. hRgcB:1:73347
    Request to access cookie or storage on “https://dpm.demdex.net/id?d_visid_ver=4.4.0&d_fieldgroup=MC&d_rtbd=json&d_ver=2&d_orgid=F6421253512D2C100A490D45%40AdobeOrg&d_nsid=0&ts=1720888259251” was blocked because it came from a tracker and content blocking is enabled.
    Ignoring unsupported entryTypes: longtask. vendors.e2b455e629a5999903d0.js:1:235534
    No valid entryTypes; aborting registration. vendors.e2b455e629a5999903d0.js:1:235534
    The script from “https://www.homedepot.com/StoreSearchServices/v2/storesearch?address=95050&radius=50&callback=loc1720893266813” was loaded even though its MIME type (“application/json”) is not a valid JavaScript MIME type. 325510353
    Failed to create WebGL context: WebGL creation failed:
  • WebglAllowWindowsNativeGl:false restricts context creation on this system. ()
  • Exhausted GL driver options. (FEATURE_FAILURE_WEBGL_EXHAUSTED_DRIVERS) hRgcB:1:120162
    onmozfullscreenchange is deprecated. main.min.js:3:19042
    onmozfullscreenerror is deprecated. main.min.js:3:19042
    Cookie “forterToken” has been rejected for invalid domain. 3p.js:2:623597
    Cookie “forterToken” has been rejected for invalid domain. 3p.js:2:623701
    X-Content-Type-Options header warning: value was “no-sniff”; did you mean to send “nosniff”?
    Cookie “forterToken” has been rejected for invalid domain. 3p.js:2:623597
    Cookie “forterToken” has been rejected for invalid domain. 3p.js:2:623701
    Cookie “forterToken” has been rejected for invalid domain. script.js:1:111127
    Cookie “forterToken” has been rejected for invalid domain. script.js:1:111255
    Failed to create WebGL context: WebGL creation failed:
  • WebglAllowWindowsNativeGl:false restricts context creation on this system. ()
  • Exhausted GL driver options. (FEATURE_FAILURE_WEBGL_EXHAUSTED_DRIVERS) 2 script.js:1:57155
    Ignoring unsupported entryTypes: layout-shift. quantum-homedepot.js:312:341
    Failed to create WebGL context: WebGL creation failed:
  • WebglAllowWindowsNativeGl:false restricts context creation on this system. ()
  • Exhausted GL driver options. (FEATURE_FAILURE_WEBGL_EXHAUSTED_DRIVERS) 888381b9-9f79-4667-a88b-ecca496b9b5d:1:6441
    Failed to create WebGL context: WebGL creation failed:
  • WebglAllowWindowsNativeGl:false restricts context creation on this system. ()
  • Exhausted GL driver options. (FEATURE_FAILURE_WEBGL_EXHAUSTED_DRIVERS) main.min.js:4:2188
    Failed to create WebGL context: WebGL creation failed:
  • WebglAllowWindowsNativeGl:false restricts context creation on this system. ()
  • Exhausted GL driver options. (FEATURE_FAILURE_WEBGL_EXHAUSTED_DRIVERS) main.min.js:4:2211
    Warning: attempting to write 6470 bytes to preference browser.topsites.contile.cachedTiles. This is bad for general performance and memory usage. Such an amount of data should rather be written to an external file.

Can those who can reproduce this try getting a regression window using mozregression?

Uh oh, something changed. When doing my basic method of just running a desktop resolution of 800x600, even the old Firefox 121 bundled with Linux Mint 21.3 is exhibiting the issue.

This very much was not happening before!

OK yeah something definitely changed, and it should now be quite easy for anybody and their dog to reproduce the issue.

In the live ISO of Mint 21.3 (either Cinnamon or Xfce), with a desktop resolution set to either 1024x768 or 1280x800 and all scaling/zooming options left at their default of 100%, the included Firefox 121.0 is exhibiting the issue in question.

Worse still, even the Windows "PortableApps" version of Firefox 128 is now exhibiting the issue when tested on Hiren's BootCD PE v1.0.8, also with a desktop resolution of 1024x768 (1280x800 was unavailable from the list of resolutions).

It may be worth noting that the issue still isn't 100% widespread however as it still doesn't impact the Firefox 115 ESR Windows versions (what is included in Hiren's BootCD PE for example) nor does it impact the old Firefox 95 included with Mint 20.3 even at 800x600, and I'm always making sure to do all my tests with live ISOs to avoid the "stickiness" issue I previously mentioned (i.e., once the issue occurs, even configurations that used to work would start having the issue possibly due to shared cache and/or profiles).

(In reply to Jeff Muizelaar [:jrmuizel] from comment #20)

Can those who can reproduce this try getting a regression window using mozregression?

Unfortunately the builds provided via the regression tester pretty much always have the issue occur whether Linux or Windows, even on Firefox versions that the issue doesn't occur on otherwise like the Firefox 95 that comes bundled on the live ISO of Linux Mint 20.3.

However, the regression tester doesn't want to launch on Mint 20.3 (trying to launch it in the terminal revealed some errors), forcing me to use Mint 21.x which actually made it difficult to test the older versions of Firefox since the older versions from like the first half of 2020 wouldn't even load a webpage on Mint 21.x.

...well this is a bit maddening.

On Linux Mint 20.3 live ISO, downloading the tar.bz2 archives from the ftp server directly via wget in the terminal to avoid launching the stock included version of Firefox, only version 95 works for some reason—versions from before (e.g. 93, 94) or after (e.g. 96, 97) do not work.

Yet on Linux Mint 21.3 live ISO, doing the exact same process reveals that version 95 also does not work. The same goes for using the Windows versions of 94, 95, and 96 (at least the PortableApps versions) which all exhibit the issue when running at 1024x768 on Hiren's BootCD PE.

Interestingly, these older non-working versions seem to actually successfully render in the images if you scroll down the page a bit. However, the newer version 121 included in Mint 21.3 nor the latest version 128 doesn't render in the images even if you scroll down the page.

As a reminder, I do all of my testing with the following URL, and I previously stated that using 800x600 on Linux was an absolute fool-proof way of making the issue occur (though it now seems to occur at larger resolutions as well as on Windows?):

NM64, is this still happening for you? I was able to reproduce the issue on my Gentoo box a few days ago, but now it's working for me on the same setup. (Raul also can't reproduce it now in bug 1906111).

(In reply to Thomas Wisniewski [:twisniewski] from comment #25)

NM64, is this still happening for you? I was able to reproduce the issue on my Gentoo box a few days ago, but now it's working for me on the same setup.

I just booted the Linux Mint 22 beta live ISO and, right out of the box, directly navigating to the same Tricklestar outlet power switch product page exhibits the issue; the issue also still occurs if I first update the included built-in Firefox via the package manager and then subsequently navigate to the aforementioned product page.

I'm about ready to make a screen video recording since I almost can't believe people aren't able to reproduce it as I'm able to not experience it, and I just confirmed that it's occurring even in a maximized window with a desktop resolution of 2560x1600 and 100% scaling.

The only thing I can think of is that people aren't testing with fully clean environments such as what is found in a live ISO—I say this because of the issues I've previously ran into where the likes of existing cache data and/or profiles can actually change the result.

This bug has spontaneously resolved for me without any changes or updates on my end. I'm going to guess it was a bug on the homedepot.com side they found and fixed.

Running FF v128.0 and the bug is still very much present for me.

Resolution: 2256 x 1504 (3:2)
Monitor scale: 150%

NM64, I believe you, and I hope I can reproduce it once I find whatever I'm missing between our configs. When I have some time, I'll try a beta Mint VM next. I only wish the cause had been more evident when I was able to reproduce it on my Gentoo box a few days ago, but it's good to rule out that it's not related to some kind of stale old version of the page in a cache, at least.

Heh I made an amusing typo: I meant to say "I'm not able to not experience it".

Anyway, it's not that I feel like you don't believe me, rather it's more that I can't even figure out how you're ending up with situations that actually function correctly since, as I depict in video attachment I've made, I don't even do anything—it just straight-up fails right out of the box

video demonstration of the issue via the live ISO of Linux Mint 22 beta (Cinnamon)

Right, to me this has the hallmarks of some kind of scripting race condition, which are often hard to track down as even having the debugger open can cause them to go away. But it's hard to tell, because it was reproducing for me in much older versions of Firefox when I tried to use mozregression, which only further makes me suspect it's not necessarily a change to Firefox which might be causing this.

One thing interesting is that, in Firefox 127.0.1 (bundled with the Mint 22 beta ISO), if you scroll down the page considerably (such as pressing the "page down" key once when in a maximized window at a 1024x768 desktop resolution) and then then scroll back up, the images will in fact load.

But if you first update Firefox to version 128 in the exact same way I show in the video, then you similarly get the same exact result my video shows whereby the images continue to not load.

Curiously, now in the Firefox 95 bundled with the Mint 20.3 ISO that used to "just work", the product images on there now will never load despite the suggested products below it loading without issue.

If it's a race condition then it's going to be difficult to reproduce on a more than intermittent basis. It may even be dependent on what route there is between client and server if this is the case as it would introduce different amounts of latency. So I think :twisniewski is right, and it may be an issue with the site code itself causing a race condition loading and executing on-site scripting, not necessarily an issue in the browser. This used to be a lot simpler to troubleshoot but with all this modular loading and unloading everyone is so in love with, this'll be a lot harder to pinpoint.

Perhaps narrow down when this started happening and reach out to the site owner to see what changes were made on their end at that time?

URL: https://www.homedepot.com/
Severity: S3 → S2
User Story: (updated)
Component: Graphics: WebRender → Site Reports
Depends on: 1903597
Keywords: webcompat:needs-diagnosis, webcompat:site-report, webcompat:site-wait
Priority: P2 → P1
Product: Core → Web Compatibility
Webcompat Priority: ? → ---
Duplicate of this bug: 1908038

NM64, can you try reproducing this and checking in the network panel of dev tools to see if you're getting 403 errors?

Flags: needinfo?(NM64+bugzilla.mozilla.org)

Huh, it seems that Home Depot once again changed something except now the change is in our favor and everything now "just works".

I say this because even the stock Firefox 127 included with Linux Mint 22(.0) works without issue, even at 800x600 which previously was the go-to way to cause the problem.

Of course, this also means that Firefox itself hasn't changed anything and, just like before, things could change again in another month's time...

Flags: needinfo?(NM64+bugzilla.mozilla.org)

Let's drop needs-diagnoses for now under the assumption that this is just the Akamai issue.

Keywords: webcompat:needs-diagnosis

While navigating the website seems fine now, turns out that the login is still completely broken.

This is super-easy to test and you don't even need an actual account—just type in any old jibberish of an email, e.g. name@mail.com and you'll run straight into the borked login issue:
https://www.homedepot.com/auth/view/signin

(In reply to NM64 from comment #39)

While navigating the website seems fine now, turns out that the login is still completely broken.

This is super-easy to test and you don't even need an actual account—just type in any old jibberish of an email, e.g. name@mail.com and you'll run straight into the borked login issue:
https://www.homedepot.com/auth/view/signin

Can you check if you're getting 403 errors?

Flags: needinfo?(NM64+bugzilla.mozilla.org)

While there were a few errors in the "network" tab of the developer tools, none of them were 403 errors. As usual, I'm testing with the Linux Mint 22(.0) live ISO.

I would not be surprised if this login issue is actually completely unrelated to the previous image-loading issue and it just happens that they're both occurring on homedepot.com

Oh, and I made a minor mistake in my previous-to-last message—since the non-beta version of the Linux Mint 22(.0) live ISO comes with Firefox 128 by default, that's what the stock version actually was, and I similarly tried with Firefox updated to version 129 in the package manager.

Flags: needinfo?(NM64+bugzilla.mozilla.org)

Just a heads up, it looks Home Depot is once again undergoing some site change(s) introduced all of an hour or so ago whereby the login screen seemed to possibly work due to now showing a new screen even though it did the same old "not working" issue around 2 hours ago. However, it either broke again before I was able to fully log in or there's a later part of the login that actually is still broken.

Here are two quick & dirty videos (will be automatically deleted in around a year) showing the "before" behavior and the "after" behavior, both of which were recorded within an hour of each other (I'm intentionally not posting these as attachments as the videos do not show the "full complete process" and because the situation is currently in flux):

before: https://0x0.st/Xwbr.webm

after (but not current?): https://0x0.st/Xwbs.webm

But now as I'm typing this, it seems completely broken (site maintenance?) even in Chrome of all things (well, I tested in Thorium since they provide AppImages which makes it very easy to test in a VM since I don't need to download and install it every single time)

What made me think to look is that, for the last few months, any of the changes we've been reporting with the behavior of Home Depot's website seems to have always occurred at the beginning of the month almost as if this is a regular schedule or something for them.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: