West Midlands | 26 March SDC | Iswat Bello | Sprint 1 | Purple Forest/bug report/Can't log in from profile page

[Iswanna]

Learners, PR Template

Self checklist

• I have titled my PR with Region | Cohort | FirstName LastName | Sprint | Assignment Title
• My changes meet the requirements of the task
• I have tested my changes
• My changes follow the style guide

Changelist

This PR fixes a bug where logging in from a profile page resulted in a 501 Error. The issue was caused by an incorrect event listener in the profile.mjs view. By changing the listener to target the form's submit event instead of a button's click event, the application now correctly prevents the default browser behavior and sends the login request to the Backend API (Port 3000) instead of the Frontend server (Port 8080).

1. The Problem

Users were unable to log back in if they logged out while viewing a profile page. Instead of a successful login, the application showed a 501 Error: Server does not support this operation.

2. Reproduction Steps

To confirm the bug, I performed the following steps:

1. Logged in as sample / sosecret.
2. Navigated to another user's profile (e.g., /#/profile/AS).
3. Clicked Logout.
4. Attempted to log in again as sample.
5. Observation: The Frontend terminal (Port 8080) reported a POST request error 501. The Backend terminal (Port 3000) showed no activity, meaning the login request was being sent to the wrong building.

3. The Discovery

I compared frontend/views/home.mjs (where login works) with frontend/views/profile.mjs (where it fails).

• Logic Difference: home.mjs was correctly listening for a submit event on the login form.
• The Bug: profile.mjs was listening for a click event on the login button.
• The Consequence: Because it was listening to the button, the event.preventDefault() in the login handler wasn't working correctly. This caused the browser to perform a "Default HTML Submission" to the Frontend server instead of using the apiService.

4. The Fix

I updated the event listener logic in frontend/views/profile.mjs:

• Changed the selector from [data-action='login'] (the button) to [data-form='login'] (the form).
• Changed the event type from click to submit.

5. Final Verification

After applying the fix, I repeated the reproduction steps. I confirmed that:

1. The login is now successful.
2. The user remains on the profile page they were previously viewing.
3. The Network tab shows the POST request is now correctly going to the Backend (Port 3000).

[nedssoft]

Iswat, this is a genuinely excellent bug report — one of the clearest I've seen at Sprint 1. 👏 Diagnosing it by comparing the working home.mjs against the broken profile.mjs, spotting submit-on-form vs click-on-button, and connecting that to why preventDefault() wasn't firing (so the browser did its default POST to :8080 instead of the API on :3000) — that's exactly how you hunt a bug. The fix matches the pattern that already works, and you verified it properly. Lovely work.

One thing to think about for future PRs (not a change I need here): alongside the login fix you also added several .gitignore entries. Ignoring .env and the database is a great instinct! 👍 But when you're fixing one specific bug, do you think a reviewer prefers unrelated changes bundled in, or the PR kept focused on just the bug (with the .gitignore tidy-up as its own small PR)? Worth keeping in mind as your changelists grow.

[Iswanna]

Iswat, this is a genuinely excellent bug report — one of the clearest I've seen at Sprint 1. 👏 Diagnosing it by comparing the working home.mjs against the broken profile.mjs, spotting submit-on-form vs click-on-button, and connecting that to why preventDefault() wasn't firing (so the browser did its default POST to :8080 instead of the API on :3000) — that's exactly how you hunt a bug. The fix matches the pattern that already works, and you verified it properly. Lovely work.

One thing to think about for future PRs (not a change I need here): alongside the login fix you also added several .gitignore entries. Ignoring .env and the database is a great instinct! 👍 But when you're fixing one specific bug, do you think a reviewer prefers unrelated changes bundled in, or the PR kept focused on just the bug (with the .gitignore tidy-up as its own small PR)? Worth keeping in mind as your changelists grow.

Thank you so much @nedssoft for the feedback! I’m really glad the logic in the report was clear.

Regarding the .gitignore entries, I definitely see your point now. I added them because I noticed the database files were cluttering my local Git status, but I realize now that bundling them makes the PR 'noisier' for a reviewer. In the future, I’ll keep my bug fixes and environment tidy-ups in separate, focused PRs.
Thanks for the tip and the encouragement.