Issue regarding the Issue cache function: Permalink does not update after using the "Back" button on the creation screen.

[1abcdefggs]

🏷️ Discussion Type

Bug

Body

Overview and background

When creating an issue from the code view, I used the browser's "Back" function intending to change the selected lines of code. However, upon modifying the code and navigating to the issue, the code remained unchanged. This prompted an investigation into the caching mechanism.

Furthermore, even when the cancel button is used, the code view after the redirect restores the old selection state; consequently, the issue creation screen generates the old permalink.

and,Accessing the discussion page also results in an error.

Cause: Persistence of initial parameters

• The issue creation page reads URL parameters only once during the initial load and stores them in the component state.

• The state is not updated when the URL changes due to "Back" or "Forward" navigation, causing the old permalink to persist.

Regarding specific aspects (symbols/identifiers) that differ from my own findings,
@sahare-mayur-0071 presented an analysis regarding caching in the discussion for #194956.

• Does the issue reproduce consistently across multiple browsers (Chrome, Firefox, Safari)?
• Does it occur only with code navigation references, or also when navigating between files through normal repository links?
• Does disabling browser extensions change the behavior?
• Does the issue occur when using browser back/forward navigation after following a reference?

Proposed

Introduce a useEffect hook in the Issue creation page component that depends on location.search, and reload the permalink whenever the URL parameters change.

useEffect(() => {
  const syncPermalink = () => {
    const params = new URLSearchParams(window.location.search);
    setPermalink(params.get("permalink") || "");
  };

  // Sync on initial render
  syncPermalink();

  // Listen for browser back/forward (popstate)
  window.addEventListener("popstate", syncPermalink);
  return () => window.removeEventListener("popstate", syncPermalink);
}, []);

Generally expected behavior:

If a user navigates back using the "Back" button and then selects a new range, the permalink on the issue creation screen should update to reflect the newly selected range.

This is because the "Code" and "Issues" pages are distinct sections.

Page navigation and the intuition behind "Back":

In GitHub's architecture, "Code" and "Issues" are completely independent, major categories.
Operations that span these categories are perceived by users as "full-page navigation."
When a full-page transition occurs, using the browser's "Back" button to return to the previous location is a completely natural action (mental model) in web browsing.

The process of selecting a code range and creating a new issue is, in fact, a "page transition."

Cancel" button:

To the user, the "Cancel" button on the issue creation screen appears to mean only "discard the text of the issue currently being written."

Consistency with standard GitHub issue behavior:

Normally, when creating an issue, it appears in a modal window overlaid on the current screen. To write in full-screen mode, one must click the full-screen button in the top-right corner.
In this standard scenario, clicking "Cancel" closes the modal window and returns the user to the list of existing issues.
In other words, the behavior of the "Cancel" button when creating an issue from the code view is inconsistent with the behavior of the "Cancel" button for standard issues.

Based solely on its visual appearance, no one would intuitively understand that this is a "reset button to clear the backend or frontend cache for code selection."

*While this may be a separate issue, the lack of a "Save Draft" button is also a contributing factor.

【CASE1】The permalink does not update after using the "Back" button on the creation screen.

Chrome is up to date Version 150.0.7871.47 (Official Build) (64-bit) win11

1. First, select L1–L10; the ISSUE view correctly displays L1–L10.
2. Go back using the browser's "Back" function, change the selection to L40–L50, and check the ISSUE view; it still shows L1–L10.

【CASE2】I executed "Cancel" on the task and changed the line number range.

1. First, select L1–L10. L1–L10 are correctly displayed in the ISSUE view.
2. If you return using the "Cancel" button in the ISSUE view, change the selection to L20–L30, and then check the ISSUE view again, L1–L10 are still displayed.
   Incidentally, after clicking "Cancel" the second time—and just before the redirect occurs—the screen actually displays L20–L30.
   This can sometimes be observed briefly during the transition. Pressing the cancel button clears the initial cache and sets the next row range; however, a redirect occurs, returning the user to the code view.

【CASE3】If you execute "Cancel" and reopen the ISSUE without changing the line number range, it succeeds.

1. First, select L1–L10. L1–L10 are correctly displayed in the ISSUE view.

2. If you click the "Cancel" button in the ISSUE view to return, change the selection to L11–L20, and check the ISSUE view again, L1–L10 are still displayed.

3. If you click the "Cancel" button in the ISSUE view to return, keep the selection as L11–L20, and check the ISSUE view again, L11–L20 are displayed this time.

As explained in CASE 2, this phenomenon occurs because the initial cache is cleared upon cancellation and the previous line range is set; this is the underlying mechanism. Consequently, if you navigate to the ISSUE page by clicking "ISSUEnew" without changing the line range in the code view, the page will reflect the permalink for the previously set line range.

The expectations associated with the word "New"

When users click the "Reference in new issue" button, they expect to create something fresh from scratch using the latest state they have currently selected.
However, the actual system retrieves a cached version of the old line number selected previously. This is not "New" (creation of something new), but rather a "Restore previous state" operation.

Transient state should be discarded: The act of selecting a line of code is a transient state (much like an SNS share button). The system is responsible for completely clearing this transient state (cache) the moment the user returns to the previous screen using the browser's "Back" function.

【CASE4】Switch the browser to Edge and reproduce Case 3.

Microsoft Edge is up to date.Version 149.0.4022.98 (Official build) (64-bit)　Privatemode.

1. First, select L1–L10. L1–L10 are correctly displayed in the ISSUE view.

2. If you click the "Cancel" button in the ISSUE view to return, change the selection to L25–L35, and check the ISSUE view again, L1–L10 are still displayed.

3. If you click the "Cancel" button in the ISSUE view to return, keep the selection as L25–L35, and check the ISSUE view again, L25–L35 are displayed this time.

【CASE5】I checked the Discussion section as well, but there was an error.

【CASE6】Reproduce #194956

When I reproduced it, there was no change.

Source:https://github.com/octokit/octokit.js/blob/v5.0.5/src/index.ts
Regarding Symbol, caching might be the cause, but we were unable to reproduce the issue.

That is all. Thank you for reading to the end.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[sahare-mayur-0071]

Thanks for the detailed investigation and for referencing the earlier discussion.

Your reproduction steps across multiple scenarios and browsers make it easier to understand the behavior. One thing that stands out is that both the browser Back flow and the Cancel flow appear to preserve the originally selected permalink, even after a new line range has been selected.

That suggests the selected code reference may be treated as persistent client-side state instead of being refreshed from the current URL or selection whenever a new issue is opened.

I also agree with your point about user expectations. When a user selects a new range and chooses "Reference in new issue", they would generally expect the newly selected lines to be used rather than a previously cached selection.

Hopefully the additional reproduction cases and cross-browser testing help the GitHub team determine whether this is an intentional optimization or a client-side state management issue.

[1abcdefggs]

@sahare-mayur-0071 Thank you for your comment!!

I would like to add some details regarding the behavior.
and If the cache-related fix is ​​not modified... .

Initially, I thought the error occurred simply during a "Back" operation.

I realized I hadn't actually clicked the "Cancel" button; when I did click it, the behavior seemed similar, so I investigated further.

Clicking the "Cancel" button triggers the following background processes:

Recap of what has been confirmed so far

• The cache is cleared.
• The previously selected line range is cached.
• The user is redirected to the code page.

Add scenario: Entering text and then clicking Cancel

Entering text causes "Discard changes?" to appear.

My previous verification involved opening the ISSUE view from the code view, where the permalink is automatically inserted into the title and body input fields.
I confirmed that clicking "Cancel" without entering any additional text resulted in a redirect to the code page.

However, this gif, text is entered into the title or body fields before clicking "Cancel," a confirmation modal appears.

First, select lines L1 through L3. The ISSUE view displays lines L1 through L10.
*Note: Since this is a partial screenshot, lines L1 through L10 appear on the Issue page even though lines L1 through L3 were selected. Please disregard this inconsistency.

Next, enter some text after the permalink.
Click the "Cancel" button in the ISSUE view.
The image from earlier.

Discard changes?
You have unsaved changes. Are you sure you want to discard them?
Continue editing | Close and discard

Could this difference in behavior be caused by caching?

Result: Clicking the "Cancel" button leaves the permalink intact but clears the entered text.

I tested a scenario where text was entered into the title and body fields. While the caching behavior itself remained unchanged, the entered text was lost.

• The behavior should be consistent, regardless of whether the permalink is inserted by default or entered manually.
• In fact, observing this behavior makes it clear that the issue is related to permalink caching.
• If caching is essential to the overall functionality and this structure is an intentional optimization, then—as mentioned in the initial post—UI/UX adjustments are needed to prevent the intuitive misunderstanding caused by the current labels.

To summarize the situation:

• The Code page and the Issue page are separate pages; the user initiates the issue creation process from the Code page.
• Regarding browser navigation, the initial cache is preserved.

Behavior
Clicking "Cancel" clears the initial cache and returns the user to the Code page with the previously selected lines still set.

However, because the state remains locked to the previous cache, any changes are not reflected if the user opens the issue again (even when attempting to create a "New Issue").

【Pattern1】If maintaining the structure that transitions from code to an issue.Change the label "Cancel" to something like "Back."

An image showing how it would look if the label were changed to "back"
An example where the label used during issue creation is changed from "Cancel" to "Back."

[Proposal: Changing the label to "Back" on the issue page (mockup)]
Note: The image below is a mockup created by modifying the current UI to illustrate the proposed improvement
.

*Note, however, that for standard issues, the body text is entered via a modal window on the issue list screen, so "Cancel" is appropriate in that case.

When creating a new issue, it initially appears in a modal window.

I have verified this behavior.

For "Standard" issues, the display is overlaid, so the only available options are "Close" or "Cancel."

This modal overlay was likely implemented to reduce the friction of page transitions when viewing details from the issue list. There is a full-screen button in the top-right corner.

To close the modal window, please click "Cancel." This is presumably the reason why the "Cancel" button exists.

Regarding the issue from the code view: As mentioned earlier, since the user is working within the "Issues" page, "Back" is more appropriate than "Cancel" from a usability perspective.

Alternatively, another option is to display a message such as: "Returning and re-selecting will preserve the issue cache. Please go back to the previous step and create a new issue with the same selections."

【Pattern2】 If the "Cancel" label is retained(If left without modification):

By displaying the "New Issue" screen as a modal window over the code view, it becomes clear that "Cancel" simply closes that modal window.

This is also an example of what happens when the "New Issue" screen is displayed over the code view.

Switching to a modal window (dialog):
Instead of navigating to a separate page, display the Issue creation screen as an overlay (modal dialog) in front of the code view. This eliminates the concept of "going back" entirely, leading users to naturally choose "Close" or "Cancel."

【Proposal: Modal Display over Code View (Mockup)】
Note: The image below is a mockup created by modifying the current UI to illustrate a potential improvement.

However, modal windows have limited display space. While suitable for short text, they may feel cramped for displaying detailed content like an Issue. There is also a risk that it may become unclear to the user whether a draft has been saved.
In this case as well, it might be better to include a full-screen button in the top-right corner of the modal window.

[sahare-mayur-0071]

Thanks for taking the time to investigate this further and for sharing the additional scenarios.

The distinction you found between using Back and Cancel, especially when unsaved text triggers the "Discard changes?" dialog, adds useful context. It suggests that there may be separate state-management paths for the issue draft and the referenced permalink.

I also think your UX observations are valuable. From a user's perspective, "Reference in new issue" implies that the current code selection will always be used. If the previous selection is intentionally preserved, the interface should make that behavior clearer to avoid confusion.

Whether the underlying behavior is an intentional optimization or a bug, the additional reproduction cases and comparison of the different navigation flows provide much more information for the GitHub team to evaluate.

Thanks again for documenting the different scenarios so thoroughly.

[1abcdefggs]

I realize I wrote a very long message, and I imagine it was quite a task to read through. Thank you for taking the time to do so.

I'm glad we could lighten the burden, and I hope it contributes to a better experience for everyone. Thanks again for the productive collaboration!

　
　
If you encounter difficulties in creating a more evidence-based explanation,
the following page may be helpful.

Interpretation of "Back" / "Cancel"
https://ux.stackexchange.com/a/136355

Regarding browser "Back" behavior
https://ux.stackexchange.com/questions/127710/recommended-browser-back-button-behaviour-for-spas/127736