FOLIO should run and perform well on any modern browser compliant with recent standards from W3C (e.g. HTML, CSS, DOM) and ECMA (e.g. ECMAScript [JavaScript]). We use the current desktop version of Google Chrome from the Stable channel as a 'reference implementation' for these standards. Due to time and resource constraints, we only regularly evaluate functionality and performance against our chosen reference implementation.

Browser-specific bug reports will be accepted. Although we prioritize making things work correctly in our reference implementation, we also evaluate a bug's severity and scope when setting its priority.

  • No labels


  1. I like this. Is this the place to discuss how UI bugs are triaged in terms of teams vs stripes or does that go in some other documentation? (Or maybe it is already understood by the necessary people?)

    1. Going to ask steve when a DB merge will be good for him - rest should have gone in

      I think it would be good for there to be advice on how to do this. I would want this with the rest of the documentation about browser support.

      I wonder if we might be intending to merge our work with the existing browser support document and that will be extended with this guidance.

  2. This looks good to me from the TC perspective.  PC / Support SIG will probably have input.

  3. It seems like some of the Rationale section from the Browser support document that Julian Ladisch would be worth preserving/including. I think it's good to document the motivation for policies, it helps us navigate when we get into legalistic binds.

  4. I wonder if in the last sentence it needs re-iterating that it is "the current desktop version of Google Chrome from the Stable channel." rather than just "Chrome". I know it's repetitive but unfortunately "Chrome" isn't specific enough, especially as Chrome on iOS uses Webkit instead of Chromium and so is really a completely different product to the Chromium based Chrome (this has led to confusion before - at least on my part!)

  5. I think that the last sentence needs to explained. It leaves a lot unsaid. Is it simply a matter of time/resources if a non-Chrome browser bug gets fixed or does something else factor into the decision?  Also, what, if any, plans are there for re-evaluating the policy?  And will any Jiras that were closed out of hand simply because they were for non-Chrome bugs be re-evaluated and/or can people re-submit them?

  6. The Support SIG discussed this proposal briefly on Monday. We would be happy to survey the community and gather browser preferences as well as gauge people’s level of interest/emotion on the topic if this draft is moving toward becoming concrete.

    For better or worse, because the project does not officially support other browsers, potential past tickets have been largely self-censored, and therefore Jira is not a reliable data source for such interest. One of the SIG’s general responses, though, was that there is a considerable volume of development work related to critical features, which would make it a real challenge to prioritize browser-compatibility of existing features over longstanding requests for new ones.

  7. No matter what I would advocate for having just one statement somewhere - right now there are several different pages talking about browser support, like Julian's page above and also the page in Tips & Tricks: Using different browsers with FOLIO

    Not a criticism that we have multiple pages - it makes sense with how this has developed - but just, once the policy is set, point all the pages towards the core policy.