Add e2e test for editor and improve other e2e tests

[Nateowami]

This change is 

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 82.49%. Comparing base (c4b4dac) to head (b5b0fac).
Report is 1 commits behind head on master.

✅ All tests successful. No failed tests found.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #3259   +/-   ##
=======================================
  Coverage   82.49%   82.49%           
=======================================
  Files         605      605           
  Lines       35186    35186           
  Branches     5726     5721    -5     
=======================================
  Hits        29027    29027           
  Misses       5306     5306           
  Partials      853      853           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[pmachapman]

These ran successfully on Windows after changing the timeout. Just a couple of questions...

Reviewed 10 of 10 files at r1, all commit messages.
Reviewable status: all files reviewed, 3 unresolved discussions (waiting on @Nateowami)

---

src/SIL.XForge.Scripture/ClientApp/e2e/e2e-utils.ts line 137 at r1 (raw file):

  await page.getByRole('button', { name: 'Connect' }).click();
  await waitForNavigationToProjectPage(page, E2E_SYNC_DEFAULT_TIMEOUT);

Now that you are syncing the source and the target, this timeout is not enough. Can you make it 180_000?

Code quote:

E2E_SYNC_DEFAULT_TIMEOUT

---

.github/workflows/e2e-tests.yml line 6 at r1 (raw file):

on:
  # Temporarily enabling pull_request to test before merging
  pull_request:

Would it make your life easier, if this was set to PRs for branches with a specific naming convention, such as:

  pull_request:
    branches:
      - 'e2e/**'

Code quote:

  # Temporarily enabling pull_request to test before merging
  pull_request:

---

src/SIL.XForge.Scripture/ClientApp/e2e/workflows/edit-translation.ts line 143 at r1 (raw file):

async function openNote(page: Page, user: UserEmulator, side: Side, chapter: number, verse: number): Promise<void> {
  // FIXME(application-bug) we shouldn't have to wait

Are the FIXMEs in the file bugs we should file in JIRA?

Code quote:

// FIXME(application-bug) we shouldn't have to wait

[pmachapman]

Really randomly... I noticed this behavior while the e2e tests were running, and a draft was generating. I have no idea how it happened, as my read of the logic in navigation.component.html says it can't do this, but I thought I'd show you anyway incase you see it or have any ideas:

Screen Recording 2025-06-23 151449.mp4

Reviewable status: all files reviewed, 3 unresolved discussions (waiting on @Nateowami)

[pmachapman]

Reviewed 2 of 2 files at r2, all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @Nateowami)

[Nateowami]

I agree; the logic is supposed to prevent this from ever happening. The only thing I can think of that might lead to this state is a digest cycle erroring part way through, putting the sync-in-progress class on, but not properly setting [matBadgeHidden]

Reviewable status: complete! all files reviewed, all discussions resolved

---

.github/workflows/e2e-tests.yml line 6 at r1 (raw file):

Previously, pmachapman (Peter Chapman) wrote…

Would it make your life easier, if this was set to PRs for branches with a specific naming convention, such as:

  pull_request:
    branches:
      - 'e2e/**'

That's a great idea; thanks.

---

src/SIL.XForge.Scripture/ClientApp/e2e/e2e-utils.ts line 137 at r1 (raw file):

Previously, pmachapman (Peter Chapman) wrote…

Now that you are syncing the source and the target, this timeout is not enough. Can you make it 180_000?

How about this change?

---

src/SIL.XForge.Scripture/ClientApp/e2e/workflows/edit-translation.ts line 143 at r1 (raw file):

Previously, pmachapman (Peter Chapman) wrote…

Are the FIXMEs in the file bugs we should file in JIRA?

@pmachapman Forgot I hadn't responded to this. For some of them, probably yes. For this one, it seems like the note gets removed and re-added. I consider it a poor implementation that feels like a bug but may never cause actual problems for the user. I guess my definition of what is/isn't a bug somewhat depends on context, and I'm quicker to call it a bug in this context than in Jira. Part of my intention of leaving these comments around is in the hope that future improvements may be made, and these workarounds removed. Maybe I should label it something different.