First of all, thank you very much for creating MeetingBar! It saves me a lot of time, and is one of the most useful programs I've used so far!
There are 2 issues I found when using MeetingBar to connect to meetings created in Google Calendar (and provided via macOS calendar app): one being technical and one being closer to product decisions, I suppose.
It relates to how MeetingBar prioritizes and parses calendar event fields, what's called "Notes" in macOS Calendar terms, and another one containing Google Meet link.
Two issues are:
When connecting/copying link to event, MeetingBar prefers using the link in Notes section, instead of the actual Google Meet link (so for example above it would open https://google.com instead)
If Notes field contains some HTML content (which Google Calendar allows to put there), MeetingBar copies the whole section, making it impossible to connect to meeting altogether, since it tries to open something like <ul><li>list item<br></li></ul><br><a href="https://google.com" target="_blank">https://google.com</a> (confirmed by "Copy meeting link" function of MeetingBar), which is, obviously, not a valid URL, leading to the errors below
There seems to be a problem with how MeetingBar works with events created in Google Calendar and, specifically, containing HTML content in URL/Notes field.
Whenever event contains a Google Meet link in location field AND a link in event's URL/Notes field that's formatted in HTML
Reproduction steps
Open Google Calendar
Create an event (see pic below) that will contain:
Google Meet link, generated and provided by Google Calendar itself
HTML content, for example consisting of a single list item and another link itself
Sync macOS Calendar app
Try to connect to the meeting via MeetingBar to witness a failure, OR
Use "Copy meeting link" to see that the whole event's whole Notes contents were copied (and used in previous step)
Expected behavior
For first issue, I would argue that in particular for Google Calendar/Meet case it makes sense to use the Google Meet link provided in event description, ignoring Notes content altogether.
For second issue, If the parsing issue spreads to other calendar providers as well, it makes sense to fix parsing as a whole.
Screenshots/screen recordings
Provided above
Additional context
I believe I've included the whole context required, but feel free to reach out in case I've missed anything :)
macOS version
14.4.1 (23E224)
MeetingBar version
4.8.0
Installation source
Homebrew
Calendars provider
macOS Calendar app
Bug description
Hello!
First of all, thank you very much for creating MeetingBar! It saves me a lot of time, and is one of the most useful programs I've used so far!
There are 2 issues I found when using MeetingBar to connect to meetings created in Google Calendar (and provided via macOS calendar app): one being technical and one being closer to product decisions, I suppose.
It relates to how MeetingBar prioritizes and parses calendar event fields, what's called "Notes" in macOS Calendar terms, and another one containing Google Meet link.
Two issues are:
https://google.com
instead)<ul><li>list item<br></li></ul><br><a href="https://google.com" target="_blank">https://google.com</a>
(confirmed by "Copy meeting link" function of MeetingBar), which is, obviously, not a valid URL, leading to the errors belowThere seems to be a problem with how MeetingBar works with events created in Google Calendar and, specifically, containing HTML content in URL/Notes field.
Whenever event contains a Google Meet link in location field AND a link in event's URL/Notes field that's formatted in HTML
Reproduction steps
Open Google Calendar
Create an event (see pic below) that will contain:
Sync macOS Calendar app
Try to connect to the meeting via MeetingBar to witness a failure, OR
Use "Copy meeting link" to see that the whole event's whole Notes contents were copied (and used in previous step)
Expected behavior
For first issue, I would argue that in particular for Google Calendar/Meet case it makes sense to use the Google Meet link provided in event description, ignoring Notes content altogether.
For second issue, If the parsing issue spreads to other calendar providers as well, it makes sense to fix parsing as a whole.
Screenshots/screen recordings
Provided above
Additional context
I believe I've included the whole context required, but feel free to reach out in case I've missed anything :)