Fix theme dev shortcut to editor tracking non page requests

[EvilGenius13]

WHY are these changes introduced?

Fixes https://community.shopify.dev/t/shopify-cli-theme-dev-editor-shortcut-loading-ajax-url/29157/5

When running theme dev, non-navigational requests like AJAX/fetch requests could be tracked as the lastRequestedPath. This caused the theme editor (E) shortcut to open the editor pointing to an AJAX endpoint (e.g., /cart/add.js or section URL instead of the actual page the user was viewing.

WHAT is this pull request doing?

Use Sec-Fetch-Mode HTTP header to update the lastRequestedPath only if it's a navigation type (like clicking links, typing a URL in the address bar)

How to test your changes?

You can replicate the issue by making a new file /layout/product.ajax-test.liquid and add this code

Details

{%- layout none -%}
<div class="ajax-response">
  <h2>{{ product.title }}</h2>
  <p>{{ product.description | strip_html | truncate: 100 }}</p>
  <span class="price">{{ product.price | money }}</span>
</div>

Then edit your layout/theme.liquid by adding this code

<script>
      document.addEventListener('DOMContentLoaded', function() {
        if (window.location.pathname.startsWith('/products/')) {
          fetch(window.location.pathname + '?view=ajax-test')
            .then(response => response.text())
            .then(data => console.log('AJAX response loaded:', data.substring(0, 100) + '...'))
            .catch(err => console.error('AJAX fetch error:', err));
        }
      });
    </script>

Run theme dev, navigate to a product page and then try the shortcut key to the editor. You should get an error.
Afterwards, build and run this branch and try the same thing, you should see the product page as expected.

Post-release steps

Measuring impact

How do we know this change was effective? Please choose one:

• n/a - this doesn't need measurement, e.g. a linting rule or a bug-fix
• Existing analytics will cater for this addition
• PR includes analytics changes to measure impact

Checklist

• I've considered possible cross-platform impacts (Mac, Linux, Windows)
• I've considered possible documentation changes

[tyleralsbury]

Claude review:

PR #6924: Fix theme dev shortcut to editor tracking non page requests

Summary: Good bug fix. The approach of using Sec-Fetch-Mode: navigate to distinguish real page navigations from AJAX/fetch requests is the right solution. Two issues need addressing before merge.

---

Issue 1: console.log left in production code

packages/theme/src/cli/utilities/theme-environment/html.ts — the new isNavigationRequest function contains a console.log:

function isNavigationRequest(event: H3Event): boolean {
  console.log('Sec-Fetch-Mode:', event.headers.get('sec-fetch-mode'))
  return event.headers.get('sec-fetch-mode') === 'navigate'
}

This looks like a debug leftover. It should either be removed entirely or replaced with outputDebug() (which is already imported and used elsewhere in this file) if the logging is intentionally desired.

---

Issue 2: Behavioral regression — lastRequestedPath will never be set when the header is missing

The old code unconditionally set lastRequestedPath on every request. The new code only sets it when Sec-Fetch-Mode is exactly "navigate". This means if the header is absent entirely (e.g., older browsers, curl, non-browser clients, or requests made with mode: 'no-cors'), lastRequestedPath will never get updated and will stay at its initial empty-string value.

The existing test at line 42 ('sets lastRequestedPath to the rendering URL') is updated in the PR to pass {'sec-fetch-mode': 'navigate'}, but there's no coverage for the case where the header is completely absent (vs. present but non-navigate). Consider whether the check should be:

function isNavigationRequest(event: H3Event): boolean {
  const mode = event.headers.get('sec-fetch-mode')
  // If the header is missing (non-browser client), default to treating it as navigation
  return mode === null || mode === 'navigate'
}

This would preserve the original behavior for clients that don't send Sec-Fetch-Mode while still filtering out AJAX requests (which always send the header with a non-navigate value like cors, no-cors, or same-origin). The current implementation is probably fine for the real-world use case (browsers always send this header), but it's a subtle behavioral change worth being intentional about.

---

Minor notes

• Changeset is present and correctly scoped — good.
• Tests cover both the positive case (navigate) and negative case (cors) — good.
• The createH3Event helper was nicely extended to accept headers.

Verdict: Fix the console.log, consider the missing-header edge case, and this is good to ship.

[EvilGenius13]

Thanks for the claude review @tyleralsbury. 🤦 on the console.log. That's been fixed. As for the part about the headers. This header should be available on all modern browsers (at least 2023 onwards). Since users are navigating links via browser, I would expect this is okay. Happy to hear if there are any differing opinions.

[github-actions]

Coverage report

St.❔	Category	Percentage	Covered / Total
🟡	Statements	78.86%	14523/18416
🟡	Branches	73.18%	7227/9876
🟡	Functions	79.04%	3692/4671
🟡	Lines	79.21%	13729/17333

Test suite run success

3789 tests passing in 1448 suites.

Report generated by 🧪jest coverage report action from ae77bc6

[binks-code-reviewer]

🤖 Code Review · #projects-dev-ai for questions
React with 👍/👎 or reply — all feedback helps improve the agent.

✅ Complete - No issues

📋 History

✅ No issues