Detect browser without relying on vendor prefixes#1160
Detect browser without relying on vendor prefixes#1160jan-ivar wants to merge 1 commit intowebrtcHacks:mainfrom
Conversation
|
isn't waiting for https://bugzilla.mozilla.org/show_bug.cgi?id=1750143 easier? |
|
Merging this PR should have the same net effect (of making the check UA-string based). It might also end up being faster given Mozilla's neutral position on UA client hints. I should have done this a year ago when we discovered this, but we gotta plant the seed at some point. |
|
Firefox (Nightly) 138 now has While most major video conferencing websites I've tested so far appear to work, we're in contact with one affected by this. They're applying a fix on their end, but getting this merged would probably help them and other consumers of adapter. |
|
Just trying to get it into the same release as #1127 https://www.reddit.com/r/firefox/comments/1j8401w/another_media_service_fallen_f1tv_is_a_costly/?share_id=qEAEN4EyxZnU9fGVFNaDI&utm_content=2&utm_medium=android_app&utm_name=androidcss&utm_source=share&utm_term=1&rdt=56689 should have demonstrated that UA sniffing is far more costly to Firefox than helping do actual feature detection but... |
|
Thanks for the link. It's a good example of why we want to get rid of things like Streamlining UA sniffing helps us respond quickly with out-of-band interventions or dot-releases, which might need to include overriding UA strings in cases where websites reactively blocked Firefox. |
This comment was marked as off-topic.
This comment was marked as off-topic.
|
rebase needed |
|
I still think that providing a minimal UserAgentData that saves developers from the pain of parsing the UA string would be easier to adopt. |
Fixes #1156.