1839053 - Unable to load product categories on FS.com

Status: RESOLVED WORKSFORME

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

Description

[Blake]

Steps to reproduce:

1. Visit FS.com
2. Click on a selection to view products.

For example, hover over "Networking", then, within the "Wireless" section, click on "Indoor Access Points".

Actual results:

Click on a product loads the homepage.

Expected results:

Clicking a product should show a selection of those products.

Comment 1

[Blake]

This works in chrome and edge.

Mozregression:
Last known good build: 2016-08-25
First know bad build: 2016-08-26

app_name: firefox
build_date: 2016-08-26
build_file: C:\Users%username%.mozilla\mozregression\persist\2016-08-26--mozilla-central--firefox-51.0a1.en-US.win64.zip
build_type: nightly
build_url: https://archive.mozilla.org/pub/firefox/nightly/2016/08/2016-08-26-03-02-26-mozilla-central/firefox-51.0a1.en-US.win64.zip
changeset: a551f534773cf2d6933f78ce7d82a7a33a99643e
pushlog_url: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=01748a2b1a463f24efd9cd8abad9ccfd76b037b8&tochange=a551f534773cf2d6933f78ce7d82a7a33a99643e
repo_name: mozilla-central
repo_url: https://hg.mozilla.org/mozilla-central

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::DOM: File' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 3

[Alice0775 White]

Regression window:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=181336fdda6625d8ffa5e5764b817cc3da1f9659&tochange=dbf7b0e7dc669ced676d1bb05ba374665093f58e

Before bug 1263355, a syntax error reported in console
SyntaxError: missing = in const declarationapp~d939e436.256e199.js:1:25824
The code is for(const e in t) ....

So, I think Bug 1263355 is not root cause.

Comment 4

[Tooru Fujisawa [:arai]]

I observe the same problem that jumps to homepage also on:

• Safari 16.5 (18615.2.9.11.4)
• Safari Technology Preview Release 172 (Safari 17.0, WebKit 18616.1.17.3)

And I observe that the website behaves differently between Chromium vs Safari/Firefox.
on Safari and Firefox, the <A> element with "Indoor Access Points" text has "click" event handler,
but not on Chromium. (this was wrong. the event handler is there also on Chromium)

If I remove the event handler, the link works correctly.
So it looks like the event handler is doing something wrong.
I'll continue investigating, but it's most likely framework or some layer's compat issue.

Comment 5

[Tooru Fujisawa [:arai]]

Things I observed so far:

The click event handler eventually calls the following function:

https://fs-resource.fs.com/fs-platform/client/211.06a7053.js

toLink: function(t) {
  this.$router.push(this.$handleLink(t).url)
},

where this.$handleLink(t).url returns /c/wireless-solution-2959, while the link is https://www.fs.com/c/indoor-access-points-3086, and somehow calling the this.$router.push with that URL at certain timing causes the wrong navigation.

Also, the issue seems to be intermittent.
I sometimes observe the correct behavior both on Firefox and Safari.

When the issue happens, I do see the network access to https://www.fs.com/c/indoor-access-points-3086 in DevTools Network tab, but it and some others get aborted and then navigation to homepage starts.

Also, if I add query string to the page, the navigation also includes the query string, so this should be a reload. And indeed there are 2 window.location.reload callsites, and both are executed when the issue happens:

https://fs-resource.fs.com/fs-platform/client/app~73475f63.7740fcc.js

return regeneratorRuntime.wrap((function(e) {
  for (;;)
    switch (e.prev = e.next) {
...
      case 7:
        throw e.prev = 7,
              e.t0 = e.catch(1),
              e.t0 && "ChunkLoadError" === e.t0.name &&
              "undefined" != typeof window && window.sessionStorage &&
              (p = Date.now(),
               (!(m = parseInt(window.sessionStorage.getItem("nuxt-reload"))) ||
                m + 6e4 < p) &&
                 (window.sessionStorage.setItem("nuxt-reload", p),
                  window.location.reload(!0))),
               e.t0;

https://fs-resource.fs.com/fs-platform/client/app~f69643ec.041813f.js

return regeneratorRuntime.wrap((function(e) {
  for (;;)
    switch (e.prev = e.next) {
...
      case 13:
        return window.location.reload(!0),
               e.abrupt("return");

When I comment out both reload, the issue stops.

Then, when the issue happens, the e.t0 in both callsites contains the following error:

ChunkLoadError: Loading chunk 243 failed.
(error: https://fs-resource.fs.com/fs-platform/client/243.e030fb2.js)

and indeed the request for the URL is aborted.

So, the website is monitoring the request for certain resource, and if it fails, it reloads the page regardless of whether it's navigating away,
and the toLink above is somehow aborting the network request.

Comment 6

[Tooru Fujisawa [:arai]]

The following feature seems to be related:

https://nuxt.com/blog/v3-3#error-handling

Error handling
We now handle chunk errors by default (#19086), meaning if your site updates with a redeploy, we automatically handle reloading it on navigation.

https://github.com/nuxt/nuxt/pull/19086

So, the error handling seems to be detecting false positive and it reloads the website...?

Comment 7

[Tooru Fujisawa [:arai]]

The issue can be reproduced with the following minimal testcase on Nuxt:

<template>
  <a id="foo" href="/foo" @click="onFooClicked">FOO</a>
</template>

<script>
export default {
  name: 'IndexPage',
  methods: {
    onFooClicked(e) {
      this.$router.push("/bar");
    }
  }
}
</script>

when the link for /foo is clicked, the handler also navigates to /bar, which is also happening on fs.com,
and that results in aborting some request, and that causes the reload, due to the above error handling feature.

Still not sure why the behavior is different on Chromium tho, this is the website's issue.

Comment 8

[Tooru Fujisawa [:arai]]

even with the minimal testcase, Chromium works differently.
it seems to first navigates to /bar, and then /foo/, according to the history shown in "back" button.

Also, the existence of the click event handler I mentioned above was wrong.
Chromium also has the event handler for the link.

So the issue is caused by the Nuxt behaving differently between browsers, around how to handle $router.push done in click event handler for link, and it works unexpectedly(?) on Firefox and Safari.

Comment 9

[Tooru Fujisawa [:arai]]

with the above minimal testcase, the issue happens with Nuxt2
https://v2.nuxt.com/docs/get-started/installation
but not on Nuxt3
https://nuxt.com/docs/getting-started/installation

and given the error handling mentioned above is for version 3.3, so it would be unrelated.

then, looking into the code, Nuxt2 contains 2 window.location.reload callsites which seems to be corresponding to the above:

https://github.com/nuxt/nuxt/blob/2353db026dac9b482de0f25ba6aac6b8626fa56b/packages/vue-app/template/client.js#L210

    // Handle chunk loading errors
    // This may be due to a new deployment or a network problem
    if (/^Loading( CSS)? chunk (\d)+ failed\./.test(message)) {
      window.location.reload(true /* skip cache */)

https://github.com/nuxt/nuxt/blob/2353db026dac9b482de0f25ba6aac6b8626fa56b/packages/vue-app/template/utils.js#L165

            // check for previous reload time not to reload infinitely
            if (!previousReloadTime || previousReloadTime + 60000 < timeNow) {
              window.sessionStorage.setItem('nuxt-reload', timeNow)
              window.location.reload(true /* skip cache */)

So, this is an issue in Nuxt2, and possibly already-fixed on Nuxt3?

Comment 10

[Tooru Fujisawa [:arai]]

I want to have an opinion from DOM team about the event handler, navigation, and network request handling, whether this is something Firefox needs to address, or the website and framework need to address.
Nakano-san, can you take a look?

Comment 11

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug is invalid.
If you think the bot is wrong, please reopen the bug and move it back to its prior component.
If your bug description is written in a non-English language, please use Google Translate or a similar service to translate it.

Please note that this is a production bug database used by the Mozilla community to develop Firefox, Thunderbird and other products.
Filing test bugs here will waste the time of our contributors, volunteers and employees.
Accounts that abuse bugzilla.mozilla.org will be disabled.

Comment 12

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I have no idea. Posted to DOM team's channel in Slack. (Thank you for the investigation, really great!)

Comment 13

[Sean Feng [:sefeng211]]

Is this still the case? the Steps to reproduce in the description doesn't reproduce it for me.

Comment 14

[Jeff Muizelaar [:jrmuizel]]

Tooru, can you still reproduce with the minimal test case? I tried it and am seeing pretty similar behaviour in Chrome and Firefox. (Maybe I don't know what to look for though)

Comment 15

[Tooru Fujisawa [:arai]]

I still do see the erroneous navigation with the Nuxt 2 minimal testcase on the following:

• Nightly 132.0a1 (2024-09-11) (aarch64)
• Safari Technology Preview Release 202 (Safari 18.0, WebKit 19620.1.4.8)

While not observing the issue on the following:

• Google Chrome Canary 130.0.6710.0 (arm64)

The fs.com website seems to be upgraded to Nuxt 3, while the issue was confirmed to be specific to Nuxt 2,
so the issue won't happen on fs.com website.

Here's the details for the minimal testcase:

Setup the server

Run the following:

$ mkdir nuxt-test
$ cd nuxt-test
$ yarn create nuxt-app test-2
  # Just hit enter key for all questions
    * Project name: test-2
    * Programming language: JavaScript
    * Package manager: Yarn
    * UI framework: None
    * Template engine: HTML
    * Nuxt.js modules: (select none)
    * Linting tools: (select none)
    * Testing framework: None
    * Rendering mode: Universal
    * Deployment target: Server
    * Development tools: jsconfig.json
    * What is your GitHub username: -
    * Version control system: Git
$ cd test-2

Edit pages/index.vue:

<template>
  <a id="foo" href="/foo" @click="onFooClicked">FOO</a>
</template>

<script>
export default {
  name: 'IndexPage',
  methods: {
    onFooClicked(e) {
      this.$router.push("/bar");
    }
  }
}
</script>

Create pages/foo.vue:

<template>
  <div>foo</div>
</template>

Create pages/bar.vue:

<template>
  <div>bar</div>
</template>

Run the following and wait for the server to start:

$ yarn dev

Steps on browser

1. Open Firefox Nightly
2. Access http://localhost:3000/
3. Click "FOO"

Result on Firefox

Remains on http://localhost:3000/

Clicking multiple times sometimes navigates to http://localhost:3000/foo

Result on Chrome

Navigates to http://localhost:3000/foo

Comment 16

[Jeff Muizelaar [:jrmuizel]]

Yep. That reproduces for me.

Comment 17

[Randell Jesup [:jesup] (needinfo me)]

I can't get nuxt to start: FATAL listen EINVAL: invalid argument fe80::98f7:f44c:f75f:5f60:3000
Kershaw, Valentin - can you repro/get logs/etc?

Comment 18

[Kershaw Chang [:kershaw]]

I can start the test server successfully, but I can't reproduce this with Firefox Nightly.

Comment 19

[Kershaw Chang [:kershaw]]

The HTTP log doesn’t seem to help in identifying the issue, as it doesn't show any networking error. The address bar shows http://localhost:3000/foo after clicking the link.

FWIW, the log shows a request to http://localhost:3000/foo was created:

[Parent 32190: Main Thread]: E/nsHttp http request [
[Parent 32190: Main Thread]: E/nsHttp   GET /foo HTTP/1.1
[Parent 32190: Main Thread]: E/nsHttp   Host: localhost:3000
[Parent 32190: Main Thread]: E/nsHttp   User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:132.0) Gecko/20100101 Firefox/132.0
[Parent 32190: Main Thread]: E/nsHttp   Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
[Parent 32190: Main Thread]: E/nsHttp   Accept-Language: en-US,en;q=0.5
[Parent 32190: Main Thread]: E/nsHttp   Accept-Encoding: gzip, deflate, br, zstd
[Parent 32190: Main Thread]: E/nsHttp   Connection: keep-alive
[Parent 32190: Main Thread]: E/nsHttp   Referer: http://localhost:3000/bar
[Parent 32190: Main Thread]: E/nsHttp   Upgrade-Insecure-Requests: 1
[Parent 32190: Main Thread]: E/nsHttp   Sec-Fetch-Dest: document
[Parent 32190: Main Thread]: E/nsHttp   Sec-Fetch-Mode: navigate
[Parent 32190: Main Thread]: E/nsHttp   Sec-Fetch-Site: same-origin
[Parent 32190: Main Thread]: E/nsHttp   Sec-Fetch-User: ?1
[Parent 32190: Main Thread]: E/nsHttp   Priority: u=0, i
[Parent 32190: Main Thread]: E/nsHttp   Pragma: no-cache
[Parent 32190: Main Thread]: E/nsHttp   Cache-Control: no-cache

And the server replies:

[Parent 32190: Socket Thread]: I/nsHttp http response [
[Parent 32190: Socket Thread]: E/nsHttp   HTTP/1.1 404 Not Found
[Parent 32190: Socket Thread]: E/nsHttp   Content-Type: text/html; charset=utf-8
[Parent 32190: Socket Thread]: E/nsHttp   Accept-Ranges: none
[Parent 32190: Socket Thread]: E/nsHttp   Content-Length: 4074
[Parent 32190: Socket Thread]: E/nsHttp   Date: Mon, 07 Oct 2024 14:46:56 GMT
[Parent 32190: Socket Thread]: E/nsHttp   Connection: keep-alive
[Parent 32190: Socket Thread]: E/nsHttp   Keep-Alive: timeout=5
[Parent 32190: Socket Thread]: E/nsHttp     OriginalHeaders
[Parent 32190: Socket Thread]: E/nsHttp   Content-Type: text/html; charset=utf-8
[Parent 32190: Socket Thread]: E/nsHttp   Accept-Ranges: none
[Parent 32190: Socket Thread]: E/nsHttp   Content-Length: 4074
[Parent 32190: Socket Thread]: E/nsHttp   Date: Mon, 07 Oct 2024 14:46:56 GMT
[Parent 32190: Socket Thread]: E/nsHttp   Connection: keep-alive
[Parent 32190: Socket Thread]: E/nsHttp   Keep-Alive: timeout=5
[Parent 32190: Socket Thread]: I/nsHttp ]

Comment 20

[Jeff Muizelaar [:jrmuizel]]

I can still reproduce this in Nightly, but it isn't very reliable. It often ends up on http://localhost:3000/foo

Comment 21

[Jeff Muizelaar [:jrmuizel]]

Here's a profile of it happening with network logging turned on https://share.firefox.dev/3YcwE5L

Comment 22

[Valentin Gosu [:valentin] (he/him)]

I can reproduce this, though it usually only happens on a fresh profile and connection.
I didn't get any 404 for /foo but I did see this in the console:

JavaScript error: http://localhost:3000/_nuxt/runtime.js, line 896: ChunkLoadError: Loading chunk pages/bar failed.
(error: http://localhost:3000/_nuxt/pages/bar.js)

Capturing a profile shows the following:

LogMessages — (nsHttp) HttpChannelChild::AsyncOpen [this=592ed246f150 uri=http://localhost:3000/_nuxt/pages/bar.js]
LogMessages — (nsHttp) 592ed246f150 called from script: http://localhost:3000/_nuxt/runtime.js:919:28
...
DOMEvent — beforeunload - document
LogMessages — (nsHttp) HttpChannelChild::Cancel [this=592ed246f150, status=804b0002]

The request is triggered from the page, but then the navigation cancels it.
I expect this is related to bug 1671309 and possibly bug 896666.

(In reply to Tooru Fujisawa [:arai] from comment #5)

Then, when the issue happens, the e.t0 in both callsites contains the following error:

ChunkLoadError: Loading chunk 243 failed.
(error: https://fs-resource.fs.com/fs-platform/client/243.e030fb2.js)

and indeed the request for the URL is aborted.

So, the website is monitoring the request for certain resource, and if it fails, it reloads the page regardless of whether it's navigating away,
and the toLink above is somehow aborting the network request.

My run seems consistent with the above comment. I think there's an issue with the assumptions the framework makes about requests not being cancelled by navigations.

Comment 23

[Valentin Gosu [:valentin] (he/him)]

(In reply to Tooru Fujisawa [:arai] from comment #15)

The fs.com website seems to be upgraded to Nuxt 3, while the issue was confirmed to be specific to Nuxt 2,

It seems nuxt2 is end-of-life [1] though it doesn't mean it will go away.

I still don't quite understand why navigating to /foo first loads http://localhost:3000/_nuxt/pages/bar.js then http://localhost:3000/foo
But it seems it's this first navigation being cancelled that triggers the bug.

(In reply to Emilio Cobos Álvarez (:emilio) from bug 1732512 comment #4)

So for context: I tried to create a repro for this in https://crisal.io/tmp/fetch-after-slow-submission.php, and it is true that we cancel the network request as soon as we start navigating, but Chrome does it when the next page starts loading (at a rather hand-wavy time actually).

I think it's this difference in behaviour that's causing the issue.

[1] https://v2.nuxt.com/lts/

Comment 24

[Daniel Holbert [:dholbert]]

The error message here was the same as in bug 1956063 (and more recent bug 1985476), so I wonder if this may have the same underlying cause. Those other bugs are fixed on Nightly by bug 1954685 (with bug 1584269 tracking letting that config ride the trains to release).

So, a few questions (directing towards arai since they've repro'd this and have investigated a bit):

• Can anyone (arai perhaps) still reproduce this at the original site on release? (or on Nightly with dom.events.script_execute.enabled explicitly set to true)?
• If this is still reproducible: does toggling dom.events.script_execute.enabled to false fix the issue?
• How about for the minimal testcase in comment 7?

[Wondering if it'd make sense to consider this webcompat:platform-bug with dependency on bug 1584269; or better-still, maybe this is WFM if the site has changed such that this doesn't repro anymore.]

Comment 25

[Daniel Holbert [:dholbert]]

(ah sorry, I guess we already diagnosed this as bug 1732512 in comment 23. Still would be useful to know if this still repro's for anyone and if dom.events.script_execute.enabled might independently help, since it helped for other sites that were triggering similar-looking errors.)

Comment 26

[Tooru Fujisawa [:arai]]

(In reply to Daniel Holbert [:dholbert] from comment #24)

So, a few questions (directing towards arai since they've repro'd this and have investigated a bit):

• Can anyone (arai perhaps) still reproduce this at the original site on release? (or on Nightly with dom.events.script_execute.enabled explicitly set to true)?
• If this is still reproducible: does toggling dom.events.script_execute.enabled to false fix the issue?

The original site no longer causes the issue, given this issue is specific to Nuxt 2 and the original site already upgraded to Nuxt 3.

• How about for the minimal testcase in comment 7?

The minimal testcase with Nuxt 2 from the comment #15 still causes the issue, regardless of the dom.events.script_execute.enabled pref value.

Comment 27

[Daniel Holbert [:dholbert]]

Cool, thanks! I think we can close this bug here, then, for comprehensive-webcompat "users are currently experiencing a broken experience on $PARTICULAR-SITE" purposes (for $PARTICULAR-SITE = fs.com)

Would you mind spinning off a bug for the Nuxt 2 testcase breakage? (if that still seems worth tracking)