Compatibility/Meetings/2022-12-13

From MozillaWiki
Jump to: navigation, search

Minutes

Scribed by Dennis Facilitated by Honza

Should we ship interventions to sites we cannot really test? (dennis)

  • Dennis: Stubled upon this at the triage yesterday. It's hard to test and ship UA
  • James: There seemed to be two cases yesterday: one was a HR-tool that we can't get access to, and a site in a foreign language that we don't understand enough to be able to test. I'm not neccessarily advocating that we should ship interventions in those cases, but it's possible that Firefox just doesn't work on a lot of those sites, and we don't do anything about it. Maybe we should talk to :mkaply or so.
  • Tom: We can't do much about sites that are completely hidden, like intranet stuff.
  • James: Right. But there's cases where the app is running on the internet and we could maybe get access to (like Workday), and we could address those. I was more concerned that those two cases where instances where we do have access to the site or the login form, but we don't do anything about that. This might limit our ability to ship interventions to a couple of sites.
  • Tom: It's unrealistic to expect us to ship interventions for the long tail of sites - we can't maintain a large number of interventions. We could try to ship some of the interventions only to pre-release versions of Firefox and then see if they get used at all. The other option would be to crowdsource feedback in some way (a subreddit or something) to gauge if the site works with a UA override or if it's broken.
  • Simon: Two thoughts: for the specific example, we can translate the message shown there to see if the interventions work or not. We could also leverage our internal translation tools.
  • Dennis: The bigger problem here is not languages, but hte login form: we don't know what's hidden behind a login form. Even if it's a japanese comic site for example, we can look at it, and if we see images or videos working, then we can be pretty sure that it works, even if we don't understand the text. But if it's behind a login form, then we have no idea what's going on.
  • James: Crowdsourcing stuff never seems to work too well. Maybe there would be a way to show a doorhanger with "hey we're shipping an intervention here, let us know if this works or not". But this does not seem worse than knowing a site just not breaking and not doing anything about it.
  • Tom: We have to be careful not to annoy sites too much. So we'd need to have a document about the steps we take and why we do that. Telemetry might be an alternative to crowdsourcing (i.e. counting how many users access a site and checking if the usage increases). We could also leverage the fact that someone is already reporting those issues, and find a way to contact them.
  • James: Maybe there's a way to indicate in the reporting flow that it's better if the reporter provides us with a way to contact them if they really want to get this fixed.
  • Tom: (agrees with james)
  • Dennis: The idea of providing an alternative way to contact reporters isn't new e.g. we've thought about WebPush. We talked to the privacy team years ago, and they weren't happy with doing that with the reporter in firefox because it would give us too much PII. We might be able to revisit this going forward with better infrastructure for preserving privacy. But we can't do this now. Adding a bigger push to add a GH account when reporting might be the easiest thing. But the issue reporters might not have a GH account, especially in some locales.
  • Tom: Finding something that reporters would be willing to opt-into that's also useful for us. And given that all of this would still be opt-in, I'm not sure how useful this is.
  • James: stack.pop() - you're worried about offending sites, but I'm not sure how much we should be worried about this. We're also removing cookie banners for example, and it seems to be justifyable to ship an intervention.
  • Tom: I'm not saying that we should be worried about everything, but there might be cases where sites might get angry for a wide range of reasons, including legal.
  • Dennis: I think for simple UA overrides like the case mentioned here: we should just try shipping it. We know there are users using it because we received a report - and we can ship an intervention for that. If we see a lot of breakage reported about that site afterwards, we can reconsider that, but the risk of breaking a site even more doesn't mean we shouldn't try.


Tooling for WebCompat diagnoses (Alex, Bomsy)

Collecting feedback and demo

  • Bomsy: (shows demo of the local override prototype)
  • Dennis: First thought: when can I use this? ;D
  • Alex: We looked at what Chrome is doing, and it's much more powerful. We went for the simplest implementation for now, just for WebCompat. My plan was to limit this feature for the WebCompat team only, probably behind a pref. Maybe we can have a single pref for "enable all WebCompat-special-features". The patch is almost ready, but I need some more feedback from Necko team. Maybe there's some edge-cases.
  • James: FWIW, having it in there doesn't seem worse to developers than not having it. Maybe users would want a different workflow for loading an existing file vs saving it as a new file. But I don't think this is too confusing to users. But I understand that you might not be willing to support this.
  • Alex: We assumed that the default workflow would be to save a file and then edit it. Is this fine, or is loading an existing file more common?
  • Tom: Most of the time, just saving and editing it would be fine.
  • Dennis: I agree. Rarely, I have to restart the browser or whatever and then open an exsting file, but that's rare.
  • Tom: How do the breakpoints work? If the file changes drastically, the breakpoints will just stay at the same line as they've been before, correct?
  • Bomsy: Yes.
  • Bomsy: Rather than saving and do the editing, the possiblity that if a local file already exists and to just load that into Firefox, maybe that's useful. You said that you don't mind and that doesn't happen too often, but maybe it would be better to have that.
  • Tom: Maybe one option would be to pick an existing file or to save a new one.
  • Ksenia: Being able to open an existing file might be useful when I use the same JS in Chrome and Firefox. I do this quite a lot.
  • Bomsy: I don't think that would be super complex to add that.
  • Dennis: If it's not too much work, then go for it.
  • Tom: ++
  • Ksenia: ++
  • Alex: I did demo the tracer at the workweek in Berlin. Looking for feedback. The main complication is around the UI, where I have to logging outputs. I added a link to the patch above. Try it, and provide feedback. We can also land that behind a pref, but it might also be something we can expose to the web developers. I'll probably push a new revision that includes a pref, but I'll keep it to default to on for now to make testing easier.


Top 20 sites for Bocoup (Honza)

Bocoup (external company) is working on providing a prioritized list of web platform features that are not available in Gecko. Part of the work is survey for top 20 sites (HTTP Archive, developer survey)

We are starting with top 100 and identifying criteria to filter down to top 20

Here's a doc from Bocoup on the approach for sourcing the list of Gecko-only featuers and criteria for scoring each feature:

  • Sources: caniuse, webkit.org/status, chromestatus.com/features, wpt, bcd
  • Scoring: use in httparchive, github stars, is polyfillable, chrome use counter, webkit use counter, wpt failures, is on standards track, time shipped in chromium & webkit, privacy analysis, accessibility analysis, webdev survey, "top 20 websites" survey, is open UI feature, evidence of webdev interest, is in interop 2023, has moz already rejected.

We should pin down the 20 websites & give feedback on the criteria plan.

  • Simon: See the second Google Document for details on the criteria.
  • James: I don't quite know how to pick the top 20 from that list. Those top websites are also the most complicated websites, and for most of them we already have pretty good relationships with. So one question is: should we exclude everything for which we already have ongoing relationships with to learn something new, or should we incldue the priority partners? Also, the top N list might not be very representative for how browser support actually looks like.
  • Honza: One thing we've talked about is testing sites that use a popular framework - if we fix those issues, we might fix issues in a wide range of sites.
  • James: True, but the way that Facebook is using React might be very different to the way most devs are using React. But yes, picking sites that are based on a wide variety of frameworks probably makes more sense than picking 10 React sites
  • Tom: Maybe we could use the number of webcompat reports could be a signal: sites with lots of reports could be higher.
  • Dennis: The number of webcompat reports is directly proportional to the site's popularity, so I'm not sure how useful that is.
  • James: It's probably relevant enough in the top 100, as all of them are very high-traffic.
  • James: For things like Google, we might see a lot more reports just because there's a lot of different products running on that domain, as opposed to "just one product" on Facebook.
  • Simon: The list is also not limited to the Top N of websites. Another idea would be to include maintainers of popular frameworks if they're relying no specific features.
  • James: It probably depends on what we want to focus on. For streaming sites, for example, there isn't really a long tail of sites that deliver streaming video content. It may be a good idea to include some representation of lots of "special areas", like streaming, gaming, ...
  • Honza: Most likely we'll be limited to just English sites because we want to reach out to them, so it's already pretty biased.
  • Simon: If you have feedback about the criteria document, please provide it to me and Honza.

Anonymous reports - payments/paid features (SV)

  • Calin: How should we treat anonymous bug reports related to payments/paid features, especially if the user claims it's an ETP issue?

e.g. https://github.com/webcompat/web-bugs/issues/114611

  • Dennis: If it's a very popular site, then we should look into that. But for the long tail of small webshops for example, there probably is little we can do.
  • Ksenia: Might there be a way to expense things?
  • Honza: For big sites, sure. Apple TV might be one, Disney Plus another one. We can always ask, but expensing supscriptions is only possible for large things.
  • Calin: What about cases where the reporter claims it's an ETP issue?
  • Tom: That'd be good to just forward that to the ETP team, and they can decide what they want to do with that.
  • Calin: How do we do that?
  • Tom: File a bug on bugzilla in the Anti-Tracking component, and mention if this happens in ETP Standard or Strict.
  • Calin: So we should just copy the details from the webcompat report into Bugzilla?
  • Tom: Yeah. If we think we're sure that this is ETP related, like if the reporter claims it works with ETP disabled, then it's worth filing it on Bugzilla, and the team will triage that further.
  • Calin: Should we note in the bug that we can't test that ourselves, but the reporter claims it's ETP?
  • Tom: Yes. Having that in Bugzilla makes that clear.
Retrieved from "https://wiki.mozilla.org/index.php?title=Compatibility/Meetings/2022-12-13&oldid=1244962"