[MichaelUray]

Fixes #5122

Problem and change

LiveKitClient.setScreenShareEnabled caught every error from starting a screen share and only logged it to the console. When the browser or the operating system blocked screen capture, or getDisplayMedia was not available (unsupported browser, insecure context), clicking the share button silently did nothing.

Classify the error in a small helper (getScreenShareErrorKind) and show a notification. Recognizable OS or permissions-policy denials, unsupported environments and other failures are shown as errors with a matching explanation. A plain NotAllowedError is reported by browsers both when the user closes the source picker and when capture is blocked, so it is shown as a soft informational hint asking the user to check the browser and OS permissions if they did not cancel. Add the new strings to all love-assets languages and a unit test for the helper.

Tests

New unit tests plugins/love-resources/src/__tests__/screenShareError.test.ts; test scripts added to the package so CI runs them. A real denial needs a media server and OS settings to reproduce: e.g. on macOS disable screen recording for the browser and click Share → an error notification; cancelling the picker shows a short informational hint (browsers report a cancel and a block with the same NotAllowedError).

[ArtyomSavchenko]

@MichaelUray Please take a look at the failed formatting step.

What do you think about this UI suggestion?
A plain NotAllowedError is overwhelmingly the user pressing Cancel in the source picker — something people do all the time. Showing an info toast (“check your browser and OS permissions if you did not cancel”) on every cancel will feel naggy. The genuinely blocked cases are already caught by the message checks above, so I’d return silently for plain NotAllowedError (or at least show the hint only once per session).

[MichaelUray]

@ArtyomSavchenko Thanks for checking this. I investigated the latest CI run on beb09343; the formatting failure comes from mixed merge revisions.

The build checks out the moving PR merge ref, while formatting checks out the event’s original merge SHA. The build cache includes source files, so restoring it overlays newer develop changes onto the older checkout:

• build logs Merge beb09343… into f292d165… and Cache saved with key: Linux-build-cache-build-results-37e61100ad19b97bd891bab64c49cf4dc8e5a68e.
• formatting logs HEAD is now at 37e61100ad Merge beb09343… into e3f4f168…, logs Cache restored from key: Linux-build-cache-build-results-37e61100ad19b97bd891bab64c49cf4dc8e5a68e, then exits 1 on five file diffs.
• I matched every diff hunk to develop e3f4f168…f292d165, from #11144, #11072, #11068: plugins/tracker-resources/src/components/NewIssueHeader.svelte, plugins/tracker-resources/src/components/issues/edit/ControlPanel.svelte, plugins/view-resources/src/actionImpl.ts, plugins/view-resources/src/components/ActionHandler.svelte, plugins/view-resources/src/components/ActionsPopup.svelte. None of these files is changed by this PR.

I’m preparing a separate workflow-fix PR to pin the checkouts to github.sha, make cache consumers restore-only, and rebuild on a cache miss. Re-running an old run keeps its original workflow definition and can repeat these failures.

I’ve addressed the cancel-toast suggestion by returning silently for plain NotAllowedError; I’ll push the follow-up commit with that change shortly.

[MichaelUray]

@ArtyomSavchenko I pushed the follow-up. A plain NotAllowedError from the source picker now returns without a toast. OS denial (by system), both permissions-policy spellings and SecurityError still show the existing denial message as an error toast, and unsupported or other failures keep their messages.

liveKitClient.test.ts goes through the public setScreenShareEnabled and checks that the cancel cases call no notification and the blocked cases call exactly one with the existing message. The two ScreenShareNotStarted keys are no longer referenced, so I removed them from plugin.ts and all 14 locales. Build, validate, svelte-check, formatting and the package tests pass locally on the rebased branch.

The workflow fix I mentioned is #11160. It pins the checkouts to github.sha, makes the build-cache consumers restore-only and lets only the build save. The same change runs green in Platform-Collective/platform#248. hc has no rebuild-on-miss step, so I didn't add one there.

Could you approve the workflow run for this push?