fix: Replace 'Bas de page' button with 'Précédent' (Back) button

[EthanThePhoenix38]

• Changed mobile footer button from jump-to-bottom to navigate-back
• Uses browser history.back() or fallback to home if no history
• More useful for article reading flow

https://claude.ai/code/session_0138bAjho1fWwiRZju3nJFJ3

---

Continue Tasks: ▶️ 1 queued — View all

[Copilot]

Pull request overview

This pull request improves the mobile user experience in the article reader by replacing a jump-to-bottom button with a back navigation button. The change recognizes that mobile users reading articles would benefit more from quick navigation back to the article list rather than scrolling to the bottom of the current article (which they can already do by swiping).

Changes:

• Renamed mobile footer button from "Bas de page" (jump to bottom) to "Précédent" (back/previous)
• Implemented browser history navigation with fallback to home view when no history is available
• Updated button ID from articleJumpBottomBtn to articlePreviousBtn for semantic clarity

---

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

[Copilot]

The check window.history.length > 1 is unreliable for determining if the user can navigate back within the application. The history length can be greater than 1 even if the user arrived directly to this page (e.g., from a bookmark or external link), which would cause unexpected navigation outside the application.

The codebase already has a more reliable pattern in 404.html (lines 354-360) that checks document.referrer and validates it contains window.location.host. This approach ensures the user only navigates back if they came from within the application. Consider using the same pattern here for consistency.

Suggested change

	if (window.history.length > 1) {
	const referrer = document.referrer || '';
	const isInternalReferrer = referrer && referrer.indexOf(window.location.host) !== -1;
	if (isInternalReferrer) {

[Copilot]

The fallback navigation clears both search parameters and hash from the URL to return to the home view. However, this approach may not work correctly if the reader.html page has view-switching logic that depends on URL parameters.

Looking at the page structure, reader.html has two views: 'view-home' (active by default, showing readme-viewer.html) and 'view-article' (showing article content). The fallback should simply use window.location.assign('reader.html') or relative path to ensure proper navigation to the home view, rather than manipulating the current URL which might have unintended side effects.

Suggested change

	const fallbackUrl = new URL(window.location.href);
	fallbackUrl.search = '';
	fallbackUrl.hash = '';
	window.location.assign(fallbackUrl.toString());
	window.location.assign('reader.html');