Use first commit title for multi-commit PRs and fix auto-focus title field

[silverwind]

Fixes: #34865

1. When opening a PR from a branch with multiple commits, use the first (oldest) commit's title as the default title instead of the branch name
2. Add autofocus to the PR title input field for convenience

[Copilot]

Pull request overview

Updates the compare/PR-creation flow so multi-commit PRs default their title from the oldest commit (instead of the branch name), and improves UX by auto-focusing the title input when the PR form is shown.

Changes:

• Set default PR title for multi-commit compares to the oldest commit’s summary.
• Add autofocus to the issue/PR title field in the shared new issue/PR form template.
• Add an integration test covering multi-commit PR title prefilling behavior.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
routers/web/repo/compare.go	Changes default PR title derivation to use the oldest commit summary when multiple commits exist.
templates/repo/issue/new_form.tmpl	Adds autofocus to the title <input> used by both new issue and new PR forms.
tests/integration/compare_test.go	Adds an integration test intended to validate multi-commit PR title prefilling.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[silverwind]

Regarding autofocus, I see there is a data-global-init="initInputAutoFocusEnd" attribute which in theory should trigger .focus(), but it does nothing and the element never gets focused. Only HTML autofocus works. Investigating...

[silverwind]

Analysis by Claude:

Why data-global-init="initInputAutoFocusEnd" doesn't work here

registerGlobalInitFunc handlers are triggered via a MutationObserver that watches for DOM node additions (childList: true). On page load, the observer scans all existing [data-global-init] elements and calls their handlers immediately, then marks them _giteaGlobalInited = true to prevent re-initialization.

On the PR compare page, the form is already in the DOM on page load, just hidden with tw-hidden:

<div class="pullrequest-form {{if not .ExpandNewPrForm}}tw-hidden{{end}}">
  {{template "repo/issue/new_form" .}}
</div>

So initInputAutoFocusEnd fires immediately during page init — calling el.focus() on a hidden element, which is a no-op. The element is then marked as already initialized, so it never runs again.

When the user clicks "New Pull Request" to toggle the form visible, it's just a CSS class change (removing tw-hidden), not a DOM addition, so the MutationObserver doesn't fire. The toggle handler in web_src/js/features/common-button.ts does have a fallback that focuses [autofocus] elements — which is why autofocus is the correct attribute to use here instead of data-global-init.

[silverwind]

As per above, I've removed the broken data-global-init="initInputAutoFocusEnd". Native autofocus works fine in Firefox and Chrome when opening to the Compare page and clicking the button. I assume this may be a special browser behaviour regarding hidden elements with autofocus that may have changed at some point in time.

[wxiaoguang]

As per above, I've removed the broken data-global-init="initInputAutoFocusEnd". Native autofocus works fine in Firefox and Chrome when opening to the Compare page and clicking the button. I assume this may be a special browser behaviour regarding hidden elements with autofocus that may have changed at some point in time.

No, browsers are not that smart. I did it

[wxiaoguang]

As per above, I've removed the broken data-global-init="initInputAutoFocusEnd".

It isn't broken. It is designed to move the cursor to the end of the title.

When the title in the issue has a value, set the text cursor at the end of the text. (#30090)

Not only one user asks for this.

[silverwind]

As per above, I've removed the broken data-global-init="initInputAutoFocusEnd".

It isn't broken. It is designed to move the cursor to the end of the title.

When the title in the issue has a value, set the text cursor at the end of the text. (#30090)

Not only one user asks for this.

Try on main branch, this JS autofocus is not working at all. Cursor is already at the end on this branch.

BTW I think the best autofocus variant would be with selection of the whole <input> so user can immediately type to write a custom title.

[wxiaoguang]

As per above, I've removed the broken data-global-init="initInputAutoFocusEnd".

It isn't broken. It is designed to move the cursor to the end of the title.
When the title in the issue has a value, set the text cursor at the end of the text. (#30090)
Not only one user asks for this.

Try on main branch, this JS autofocus is not working at all. Cursor is already at the end on this branch.

Ar you sure?

---

[silverwind]

regarless of the current issue, I question that "autofocus on end of input" is good behaviour. Is the most common use case really to append to the title? I think a much more common use case would be to replace the title, so a full selection autofous may make more sense imho.

Personally i don't really care much about this so I can keep the "end" behaviour. in 99% of cases I keep the original PR title I had written earlier.

[wxiaoguang]

When the title in the issue has a value, set the text cursor at the end of the text. (#30090)

I question that "autofocus on end of input" is good behaviour. Is the most common use case really to append to the title? I think a much more common use case would be to replace the title

Have you read #30090 ? 30090 is the real use case. And not only one user asked for this behavior, for example: @tyroneyeh #36322 ef649c8

[silverwind]

I think it's weak use case, but I wont chase that topic futher, so lets keep it focusing at the end of the text.

[silverwind]

Autofocus is back with initInputAutoFocusEnd and is now using a IntersectionObserver. This is needed because on the PR compare page, the <input> is hidden until Compare is clicked so el.focus() was a noop (hidden elements can't receive focus). Now it triggers as soon as the element becomes visible.

The behaviour of "last element" is also restored, but is not doing anything useful because issue/pr title can only be once on the page.

[silverwind]

all fixed now and tested.

[silverwind]

If you want to do more edits, do them now.

[wxiaoguang]

By your approach, the cursor flickers.

Because by using "autofocus", the element is focused in first time. But the "move to end" happens some time later after DOM ready.

---

It's up to you

[wxiaoguang]

Native autofocus attributes has benefits, it works even when the browser has JS disabled. We should extend native autofocus, not replace it.

The new changes just cause flickers. I insist on that my code is already good enough. If you don't like the "init name", you can change it to others you like. But the approach is almost the perfect one.

I don't see why you still use "JS disabled" as a reason, we all know that Gitea won't work without JS nowadays.

[silverwind]

Reverted to JS focus again, it can not be solved cleanly with native autofocus.

[silverwind]

Tested the latest changes, working as expected, so lgtm.

@lunny, @lafriks please re-review.