Refs #2356: Add a note to the prerequisites section about requiring a modern browser

[matthiask]

Description

We have introduced Promise.try in #2356 and therefore should state clearly that we expect developers to have an up-to-date browser for using the toolbar.

Checklist:

• I have added the relevant tests for this change.
• I have added an item to the Pending section of docs/changes.rst.

AI/LLM Usage

• This PR includes code generated with the help of an AI/LLM

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🔵	Lines	98.18%	54 / 55
🔵	Statements	98.21%	55 / 56
🔵	Functions	94.73%	18 / 19
🔵	Branches	71.42%	10 / 14

File Coverage

No changed files found.

Generated in workflow #3091 for commit e0404a4 by the Vitest Coverage Report Action

[github-actions]

Coverage report

This PR does not seem to contain any modification to coverable code.

[codingjoe]

Good call. I left some small suggestions.

[codingjoe]

Maybe we explicitly mention Baseline Newly Available here. Since it sets a clear expectation and serves as a guideline for internal development.

Perhaps even linked, it never hurts if people learn a little about the platform they are developing for.

[tim-schilling]

FWIW, I'm not in agreement with the philosophy of, "use a modern browser or don't use this tool." I believe we're not doing anything super special that we should have to resort to only using modern browser features.

We don't expect people to run the latest version of python, despite the nice DX features it has for us to use. The browser should be treated the same.

[codingjoe]

FWIW, I'm not in agreement with the philosophy of, "use a modern browser or don't use this tool." I believe we're not doing anything super special that we should have to resort to only using modern browser features.

We don't expect people to run the latest version of python, despite the nice DX features it has for us to use. The browser should be treated the same.

@tim-schilling I agree with the accessibility sentiment, and maybe we might need to rephrase. In this context “modern browser” means "not a legacy browser" like IE11 (EoL). This would mainly affect compatibility testing sessions on BrowserStack. I believe it's good that people know to disable the toolbar here to avoid issues.

Beyond that, I don't believe anyone will notice any impairment during development, even if they are not sporting the latest MacBook Pro.

[tim-schilling]

In this context “modern browser” means "not a legacy browser" like IE11 (EoL).

I don't think this is true. It's listed as "Newly available" and will be so for another year. According to https://caniuse.com/?search=promise.try there's a segment of Chrome browsers that's about 2.8% of users that would be impacted by this.

Edit: The rest of the groups are fairly small and probably negligible even added up.

[codingjoe]

@tim-schilling, I honestly don't think that's a fair comparison. That's global usage. With things like hospitals that run Windows XP for their old MRI machine software. We are addressing software engineers, enthusiasts, or students debugging their Django applications. I hope those will use a more recent version of Chrome that isn't vulnerable to a multitude of exploits. They may not all have the latest gear, but I have trust in their ability.

I certainly can provide the same patch without Promise.try, but the main reason to use it was because the previous code was so complicated that it hid an error. Now it's 4 lines of code. See also #2356

True, accessibility is important and dear to me too. But so is the maintainability, security, and ability to evolve a package. Knowing where we came from in #2356, I believe we struck the right balance.

If you believe we didn't, I'll change it. It is just one line of code.

[tim-schilling]

I phrased that poorly. I don't believe that 2.8% of our users would be impacted by this, but there's a reasonable chance that someone could. Chrome 124 was released in July 2024. I'm not aware of a better number to use to understand impact of browser tooling.

I certainly can provide the same patch without Promise.try, but the main reason to use it was because the previous code was so complicated that it hid an error. Now it's 4 lines of code.

As I mentioned there are likely legitimate use cases of people using older browsers. Unless there's something we can't implement otherwise, we shouldn't be using Newly Available frontend features. There's a reason both you and Matthias hesitated at first. And if we do use one, there should be a fallback for people, not a general error that breaks the app.

What I'd like to see:

• A clarification on what modern browser means to us
• A graceful failure where Promise.try is being used (it can even be that things aren't debounced at all), though I think the following works

  export function debounce(func, timeout) {
      let timer;
      return (...args) => {
        clearTimeout(timer);
        timer = setTimeout(() => func.apply(this, args), timeout);
      };
  }

[codingjoe]

I slept on it. No need to make this harder than it needs to be. I'll provide a patch without Promise.try and will update the docs too.

[tim-schilling]

I'd like to hear others' thoughts before you invest more time implementing something.

[codingjoe]

I'd like to hear others' thoughts before you invest more time implementing something.

No worries, my remarks were not founded on resignation. You pointed out a very valid concern, and after some consideration I share it. In fact, it makes the implementation leaner, but I missed that earlier. So thank you for your persistence.