TP browser support disclaimer

[mitchell852]

This Improvement request (usability, performance, tech debt, etc.) affects these Traffic Control components:

• Traffic Portal

Current behavior:

There is no disclaimer in TP that only one browser is guaranteed to fully work: chrome and another is known to fully work: firefox.

New behavior:

Some sort of disclaimer about this in TP would be nice so people don't use Safari, for example.

[hritvikpatel4]

@mitchell852 - Should we do this using the navigator.userAgent property?

[mitchell852]

@mitchell852 - Should we do this using the navigator.userAgent property?

sure. you mean check the value of navigator.userAgent and if not chrome/firefox display a message or something? sound good to me. the message could be set using:

messageModel.setMessages([{level: 'warning', text: 'Unsupported browser. Use chrome or firefox.'}], false);

[ocket8888]

globalThis.navigator.userAgentData is a great interface for doing that without parsing the insane jumble of text that UA strings have become - but it's not available in Firefox (or Safari or stably in most versions of Samsung Internet). So it's possible we could find a shim on npm or something.

[hritvikpatel4]

globalThis.navigator.userAgentData is a great interface for doing that without parsing the insane jumble of text that UA strings have become - but it's not available in Firefox (or Safari or stably in most versions of Samsung Internet). So it's possible we could find a shim on npm or something.

There are three popular npm packages:

1. https://www.npmjs.com/package/ua-parser-js
2. https://www.npmjs.com/package/bowser
3. https://www.npmjs.com/package/useragent

The third one claims it's the fastest parser. I would rank them as 1 > 2 > 3 based on their popularity on npmjs.com

@ocket8888 @mitchell852 - What are your thoughts on this?

[ocket8888]

It's unlikely to be a performance bottleneck, especially since if done correctly it should only be calculated once. Speed is a non-issue. Whatever library is easiest to use and/or smaller and/or more accurate (I would hope they're all equally accurate) is the best choice. Or if you think it's easiest to just parse it yourself since we only support two browsers, that's fine too.

[hritvikpatel4]

It's unlikely to be a performance bottleneck, especially since if done correctly it should only be calculated once. Speed is a non-issue. Whatever library is easiest to use and/or smaller and/or more accurate (I would hope they're all equally accurate) is the best choice. Or if you think it's easiest to just parse it yourself since we only support two browsers, that's fine too.

Got it.

@ocket8888 - Could you tell me if there is any documentation on how to integrate new features into traffic portal?

I see there are two modules folders traffic_portal/app/src/modules and traffic_portal/app/src/common/modules.

[mitchell852]

@ocket8888 - Could you tell me if there is any documentation on how to integrate new features into traffic portal?

I see there are two modules folders traffic_portal/app/src/modules and traffic_portal/app/src/common/modules.

sorry, no documentation on how to do it but traffic_portal/app/src/modules is really for view/pages. module was a bad name for that directory i guess. so probably go with "common modules".

Actually, you might just want to inject your code into ApplicationService.js as i believe that runs on TP startup.