From MozillaWiki
Jump to: navigation, search


  • Scribe: James
  • Chair: Honza

H2 2023 Goals (Honza)

  • Honza: See also the devtools roadmap document. Suggested goals are in in there, but can be changed. Hopefully nothing is surprising.

Why strategy?

  • Get alignment on which problems to solve
  • Guide our work and provide clear way to decide what we do what we don’t do and how we prioritize
  • Constrain our options to the ones that make the difference.
  • Honza: Want to make overall strategy clear so it's easier to prioritise.

What do we do and why?

  • WebCompat
 * What: KB, new in-product tool, SoWC report
 * Why: Help platform teams with prioritization and contribute to top level company OKR (improving technical fundamentals for web compatibility)
  • Automated Cross-browser Testing
 * What: WebDriver BiDi
 * Why: Help web devs with cross browser automated end-to-end testing (web compat).
  • Developer Tools
 * What: tooling for web compat team, tooling for web developers. Performance and reliability of Firefox DevTools Toolbox.
 * Why: Make web compat issues diagnoses more effective (focusing on debugging production sites) and help developers to identify and fix compatibility issues in Firefox.
  • Honza: For devtools, want to help people avoid compat issues during development. Written a little summary of the whole team's goals. Please read befiore it's shared. Goals in culture amp should have a description as well as a title.
  • Raul: How does this apply to QA?
  • Honza: You're in the table, but no Culture Amp required.

New Reporting Tool (Honza) =

  • Less bugs landing in the GH rep, more reports going to BQ
  • List of issues to triage needs to be generated (spreadsheet, grouping & sorting)
  • New in-product Reporting tool (how the existing Report Site Issue and new items work together)
  • What if users are reporting issues from differen device that the one where the issue appeared in the first place?
  • Honza: Where are we with visulising the list?
  • Dennis: Expect to have something ready by Thursday for discssion. If it's all good we can trial next week, but there might be changes. So far the data is looking useful. If we can't get a prototype soon, we should roll back the change and make sure new reports all end up in GitHub.
  • Honza: Do we record the operating system?
  • Dennis: We are currently not storing the UA string, but we should change that.
  • Ksenia: UA should be there, but not for every issue?
  • Dennis: Details are empty if people submit directly to BigQuery and not from reporter. We should store at least the UA string in all cases.
  • Dennis: If people go directly to and then submit a simple bug report, we don't store any additional details e.g. user agent. We should file a bug. Don't want to end up processing reports for very old / other browsers. Need to consider how to do that in the query.
  • Honza: What happens if they report from a different device? We will get incorrect UA string.
  • Ksenia: Typically users mention this in the comments. The old/extended form has a specific question about this.
  • Dennis: We might make up for this with higher volume.
  • Honza: UX person is working on the in-product reporter. There's a diagram of the workflow. Question about "report site issue": new tool will work from the shield icon. Then there will be an item in hamburger menu. Could be under help, or directly under the top level. There might be a time where we have both the old and new report site issue entries.
  • Dennis: I'd just remove the old one as soon as the new one is ready.
  • Honza: The new reporting tool will also have a link to
  • jgraham: Do we want stuff to end up on Doesn't seem great to have multiple triage queues.
  • Honza: Some people might want to do really detailed reports. We might want to do both as we learn the tradeoffs.
  • Ksenia: We could keep the GH authorised reporter and remove anonymous.
  • Honza: We don't want to close the GH repo.
  • Dennis: Depends on the volume of reports we keep getting on GitHub. It's hard to tell what will happen.
  • Honza: Things are happening, but it will still take time.

All Hands Talk Submissions (jgraham)

  • Lighting talk about WebCompat KB
  • Should we submit a deep dive proposal for Web Compat / Interop in general?
  • James: we were taling about this before, any progress on defining what we should talk about, Dennis?

Some talking points: - why web compat is important - how the proces look like - how to contribute

  • Dennis: We can propose it. I hope people already know, but maybe not.
  • Honza: I sometimes get questions about how to handle webcompat issues. We could talk about this. e.g. file a bug, report site issue. Good chance to talk about that.
  • Dennis too busy, James will look into this.

Exploratory Testig Top 100 sites - similar issues on multiple pages(SV)

Some similar issue were observed on numerous sites, mostly the same UI discrepancies between Firefox and Chrome - the scrollbar and drop-down lists and menus have a different UI compared to Chrome. Is this something worth reporting individually for each site, or should we create a META bug for similar issues?


  • Dennis: Might be webkit scrollbar styling. If it breaks layout that is a problem, but otherwise not likely to be a priority. If it's just about e.g. colour realisitcally we would mark it P3.
  • Honza: In dev satisfaction survey, scrolling was one of the challenges mentioned.
  • Raul: Scrolling itself wasn't affected, it was just a UI issue. Dropdown lists are also affected.
  • Dennis: always OK to file a bug. We can look into it.

jgraham: Looks like the differences might just be form control rendering and not breaking anything. Differences might just be expected.