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.

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

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.

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.

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.

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.

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...?

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.

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.

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?

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?

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