Repository navigation
fix: notifications across browsers, show every notification, in-app dialogs - #20
Merged
Merged
Conversation
…us one ## Summary Session-complete notifications did not pop up after the sample notification. **Cause:** every notification reused one tag (web) / id (extension). When a notification with the same tag is still in the notification list, Chrome swaps the new content into it *silently*, without showing a pop-up. The sample sent on "Turn on" stayed in the list, so "Focus session complete" replaced it invisibly. **Fix:** each notification gets a fresh id, and the previous one is closed (web) / cleared (extension) first, so only one is ever listed and every session or break end pops up. ## Testing - Lint, typecheck, unit tests and build pass. - Stubbed Notification API: sample opens without a tag, is closed, then "Focus session complete" opens fresh. - Reported scenario (Turn on → sample shown → session ends → nothing shown) to be re-checked on a real machine.
Drop the in-app 'Turn on' banner and the app-level on/off setting. The app calls Notification.requestPermission() on first open, so Chrome's own Allow/Block prompt is the only step; the extension is granted by its manifest and needs no ask. Menu → Settings → Notifications shows On / Blocked (with how to change it), or 'Turn on notifications' to ask again when the prompt was dismissed.
ttncode
changed the title
Replace every window.alert/confirm with an in-app dialog (OK, or Cancel/confirm with a red Delete for destructive actions; Esc cancels, Enter confirms, queued one at a time). Firefox and Safari ignore a permission request that is not inside a click or key press and answer 'default' at once, so the ask on load never showed a prompt there. When that happens the app now asks again on the user's first click or key press. A dismissed Chrome prompt (which takes the user time to answer) is not asked again.
ttncode
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Two notification fixes from testing on a real machine.
Ask Chrome directly. The in-app "Turn on" banner and the app-level on/off setting are gone. On first open the app calls
Notification.requestPermission(), so Chrome's own Allow/Block prompt is the only step. In the extension the manifest grants the permission, so there is nothing to ask. Menu → Settings → Notifications shows On or Blocked (with how to change it in site settings), or Turn on notifications to ask again when the prompt was dismissed or shown in Chrome's quiet form.Show every notification. Every notification reused one tag (web) / id (extension). While the previous one was still listed, Chrome swapped the new content in silently without a pop-up, so "Focus session complete" never appeared after an earlier notification. Each notification now gets a fresh id and the previous one is closed/cleared first.
Testing
Also in this PR
In-app dialogs. Every
window.alert/window.confirmis replaced by an in-app dialog styled like the app: OK for messages; Cancel plus a red Delete for destructive confirmations (sessions, habits, notes, tags, goals, comments). Esc cancels, Enter confirms, a click outside cancels, and dialogs queue one at a time.Firefox and Safari. They ignore a permission request that is not inside a click or key press and answer
defaultimmediately, so the ask on load never showed a prompt there. When the browser answers that fast, the app asks again on the user's first click or key press. A Chrome prompt the user dismissed (which takes time to answer) is not asked again. Edge shows its quiet bell in the address bar by default; allow it there or via the menu entry.Extra testing