Compatibility/Meetings/2021-09-14

From MozillaWiki
Jump to: navigation, search

Minutes

Scribed by Thomas

Version 100 Priority (karl)

If you see one in your radar, let's prioritize and do outreach and site interventions. https://github.com/webcompat/web-bugs/labels/version100

  • Idea: A feature of the type if ua_version >= 100, use 99 for example.com/path/blah.js
  • Karl: cpeterson is leading on an experiment to detect breakage when Firefox's user agent string hits version 100. we're likely to receive new bug reports on Android but not all of them may be directly related. Please triage and diagnose with a version 100 UA spoof on and off to confirm whether it truly is.
  • Oana: I have only seen perhaps 4 of these so far.
  • Karl: Let's try to push for outreach on these issues right away, so we can hopefully get them fixed as early as possible before 100 actually hits. And for Thomas: can we add a feature where we change the version number for users currently in that experiment for known-to-be-problematic sites, form 100 back to 99 or so?
  • Thomas: yes we can. we already have the ability, and we can simplify the process if we'd like.

Non Compat Thoughts (karl)

There's a category of issues that we close as non compat. We might want to think twice about some of them, where we could fix them with a site intervention. The site is broken, but useful, it breaks in many places but we have an opportunity to make it work in Firefox. Not all of them, but maybe some of them. Bad idea? What do you think?

  • Thomas: Let's not make people think that their website is not broken. … I haven't seen that many issues of this type that could be fixed. …But I'm not against the idea, if we think it's worthwhile.
  • James: putting a manager hat on, what's the cost/benefit here? If it's broken on Chrome, is there real value in us making it work on Firefox? Perhaps there are too few users for it to be an overall benefit, given that it's not working on Chrome so not many users are likely to care?
  • Thomas: I think if we can reduce the cost of testing/QA first, with an automated test suite, then we might be able to tackle this more realistically without worrying about cost/benefit as much.
  • Oana: how would we tackle this, if we do it? There are a lot of these issues to go through again.
  • Karl: some history: Alex Mayorga once raised the point that if we just close these bugs, users will feel like we're sweeping them under the rug. Our response was that we don't have the bandwidth to deal with them, but our broader community can help with the outreach work. But clearly that has not been done to this date. And worse, we're not in a position to increase our diagnosis load right now, so I thought I would raise this question.
  • Ksenia: we will need to diagnose them to make sure they can be fixed by us with an intervention, so the effort is probably not feasible until we lower our current diagnosis queue anyhow.
  • Karl: yes, as James suggested, we would probably need to limit this to topsites to make it worth the effort. …so this is something to put on the backburner for now until we have more time/a better idea of the scope.

bfcache site compatibility (karl)

Do we have issues with bfcache? https://web.dev/bfcache/

  • Karl: there is an effort right now to make bfcache more efficient/effective. So if we notice anything while diagnosing/triaging, let James or Karl know so we can raise it with the relevant group. Basically we can confirm it if Chrome and Firefox differ in how bfcache works (unload and load events and the like).
  • James: I suspect that we can also confirm by reloading the page, and if it's not broken anymore, then it might be this kind of issue. Which means we might not even notice these as webcompat issues while triaging. … we're trying to improve the automated tests for this right now.
  • Tom: should we ping someone if we're not 100% sure if something is bfcache-related? I worry we might close issues too early without being sure, due to lack of experience.
  • Karl: the way this feature works across browsers is not necessarily consistent to begin with, so it might be too difficult for us to be sure if a given bug is bfcache-related to begin with. For example issues with Analytics during back navigation. The page not receiving a hit for the analytics because it comes from the cache and not a request from the network.
  • James: this is not the normal kind of webcompat issue, as the problems vary a great deal more then our usual workload.

FYI - Diagnosis Hell (karl)

Let's work as a team to burn down the pile of bugs.

  • Karl: let's aim to be back in shape by year's end. we've had worse, but we're floating around 300 open issues right now, so we need to push (but we've been at 1200 issues a couple of years ago).
  • Karl: if things become too difficult to deal with, we may need to deprioritize Firefox on iOS, since issues aren't being handled by that team right now. I'm also reaching out to Apple to see if they can deal with their own bugs. Also IceDragon (?) to see if they can handle their own backlog. As for Chrome, I'm assigning them to Mike Taylor :)

AVIF images issues (Oana)

  • Oana: there have been some broken-images issues recently, any help/ideas as to why ?
  • Tom: AVIF support is enabled in nightly Firefox, but some images might not be handled properly yet. You can confirm if it's AVIF easily right now because it should be nightly-only (Fx92 doesn't have it enabled yet) and there is an about:config flag to toggle it on nightly (image.avif.enabled = false). One such bug with AVIF: https://bugzilla.mozilla.org/show_bug.cgi?id=1729071 We should probably file bugs against AVIF here: https://bugzilla.mozilla.org/show_bug.cgi?id=1443863

Two Minutes ( 👹 )

The useful, the silly, the things you did since the last meeting. Pro and Perso accepted.

  • Dennis: PTO.
  • James: Running (walking) up that hill. Script execution in WebDriver BiDi, cross-context messaging in wpt.
  • Karl: Rest. Moving houses. Looking at web-bugs / bugzilla relationships.
  • Ksenia:
  • Oana: PTO in Austria + Triage and moderation. Enterprise testing.
  • Raul: PTO
  • Thomas: A little burn out hit me, so I took it easy for a week. Otherwise, I've managed to get the ETP team to help out a little more with SmartBlock issues, at least related to certain projects we're working on right now.
  • Joe:

PTO / Travel ( 👹 )

(no more travel until the end of 2021… probably) Coming holidays across the world https://www.timeanddate.com/holidays/

  • Dennis: September 13-24 (PTO)
  • Raul: September 6-17 (PTO)
  • Ksenia: September 17 (PTO)

FYI: 2021H1 Ideas (karl)

Let's keep this around so we have a reference. https://docs.google.com/document/d/1w3_AU4ZYJJLSkqOW5j_6K49JxmutEsxcpsiwHXz8Tbw/edit?usp=sharing

Retrieved from "https://wiki.mozilla.org/index.php?title=Compatibility/Meetings/2021-09-14&oldid=1238129"