User Details
- User Since
- Jan 16 2025, 9:59 AM (82 w, 3 d)
- Availability
- Available
- LDAP User
- Unknown
- MediaWiki User
- Viktoria Hillerud (WMSE) [ Global Accounts ]
Jul 17 2026
Firefox is reporting the microphone permission as "granted" via navigator.permissions.query even after closing and reopening the tab, while still prompting for permission again anyway. This seems like a Firefox-side inconsistency. Flagged with a BUG: comment in HardwareCheckStep.vue for future reference.
The usePermission from vueuse was indeed helpful! The latest commit uses it to reactively check the actual browser permission state for the microphone, instead of relying on a local variable (permissionInfoShown) that reset every time the step was mounted or refreshed. The instruction message is now only shown when the browser hasn't actually granted microphone access yet. If it's already 'granted', the message is skipped and the hardware check starts directly.
Jul 16 2026
Nothing that needs to change now, but I suppose that the "recording type" will be set automatically once you can chose that in an earlier step. If so we may want to remove it, though it could still be useful as a manual override.
Here are version 1 proposal of the recording view:
This is very true. I will implement that.
Ah, I understand, so if the user has clicked allow, and then click previous, this message should not appear again right?:
One thing that should be fixed is that the message appears even when the microphone has permission. This happens both if you've told the browser to remember the choice in an earlier session and if you go back to the hardware check.
Yes, I liked how you mocked it up on PenPot though, with the extra "Listen" button and the warning message
Jul 15 2026
Jul 14 2026
I understand what you mean, it will be an extra click if adding the previous extra step, though in the acceptance criteria of the story this task is in, we had:
The first version of the profile view:
Jul 9 2026
We discussed on having the same color as "Start recording" since it is the next step that is expected:
This is only a small step toward refactoring all the fields. I'm not entirely convinced that tackling this incrementally is the best approach, given the number of form fields still to update. Perhaps this step is best viewed as a proof of concept for how the remaining fields should be edited.
Suggestions for alternatives for fields: