Proposal - Centralized environment flags

[michaelcunningham19]

Is your feature request related to a problem? Please describe. Not related to a functional problem of any kind, more about consistency with browser-specific code paths.

When performing a search in the codebase for navigator.userAgent, we currently have 8 occurrences of navigator.userAgent in the code base (some are within tests and demos) for use in conditionals for browser-specific handling for various aspects.

Describe the solution you'd like A single source of truth for environment information so we don't need to repeatedly manipulate and .test a user agent string throughout the codebase.

For example, in the mp4-remuxer:

if (outputSamples.length && navigator.userAgent.toLowerCase().indexOf('chrome') > -1) {
  ...
  ...

Describe alternatives you've considered A pattern where we store local environment state in the respective scopes (e.g. controller instance members isChrome and similar)

However that introduces room for many different instances of these flags across the code base.

Additional context I'm thinking of something that resides near the top-level API so that controllers can reference it, and optionally pass it down further into lower level utilities

We don't need to expose it on the public API, typically an application will have their own determinations of their operating environment

[johnBartos]

This works well for us in JW; we can implement something like this here too: https://github.com/jwplayer/jwplayer/blob/master/src/js/environment/environment.js

[robwalch]

HI @michaelcunningham19,

Care to take a look at feature/v1.0.0 #2370 and contribute some centralized env flags?

[robwalch]

Next release we can look at adding a module that centralizes methods like isChrome,isSafari,isFirefox, isAndroid and chromeVersion,webkitVersion (it's down to 5 places now). These should be lazy with values cached in the module scope. I don't think we should offer anything on the public API/top-level. That would be the work of another library, and for HLS.js this is just what we need for very specific MSE and media playback quirks - not general use.