|
|
| Line 1: |
Line 1: |
| * [[Compatibility|Web Compatibility Meeting]] Meeting - 2022-12-13 | | * [[Compatibility|Web Compatibility Meeting]] Meeting - 2022-11-22 |
| * [[Compatibility/Meetings|Minutes]]: [[Compatibility/Meetings/2022-11-22|Previous 2022-11-22]] | | * [[Compatibility/Meetings|Minutes]]: [[Compatibility/Meetings/2022-11-08|Previous 2022-11-08]] |
|
| |
|
| == Minutes == | | == Minutes == |
| Scribed by Dennis | | Scribed by Ksenia |
| Facilitated by Honza
| |
|
| |
|
| === Should we ship interventions to sites we cannot really test? (dennis) === | | === Workweek in Berlin (Honza) === |
| '''Dennis''': one example: https://github.com/webcompat/web-bugs/issues/101497
| | Detailed [https://docs.google.com/document/d/1mDQcItNs1nZ6gN6C8OVApPDcf2w5gXbJXTcqY6-_h3g/edit#heading=h.x9erc9acm1kk agenda] of the week |
| | |
| | * '''honza''': Simon will join us in Berlin as well. There will be 11 of us. We have the whole 3d floor, at least 2 meeting rooms. I'll be cancelling all meetings for next week, including this one. |
|
| |
|
| * '''Dennis''': Stubled upon this at the triage yesterday. It's hard to test and ship UA | | * '''simon''': bgrins was planning on doing http archive presentation for the whole team and I would like to help |
| * '''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.
| |
|
| |
|
|
| |
|
| | === Reporting web compat issues in our org (Honza) === |
| | * Providing simple instructions and process for greater org to report web compat issues |
| | * Should be easy track it |
|
| |
|
| === Tooling for WebCompat diagnoses (Alex, Bomsy) ===
| | * '''honza''': what is the right way of reporting compat issues from inside the org? are there simple instructions on what one should do? |
| Collecting feedback and demo
| |
|
| |
|
| * Local HTTP overrides | | * '''tom''': if they're not sure whether it's webcompat issue, they can just ping us on slack or report on webcompat.com. if they know that it is a webcompat issue, they could try to investigate it themselves (using testcase reducer, for example) |
| * JS Tracer ([proto patch](https://phabricator.services.mozilla.com/D163614))
| |
|
| |
|
| * '''Bomsy''': (shows demo of the local override prototype) | | * '''dennis''': better to not report on bugzilla, always on webcompat.com |
| * '''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. | | * '''james''': for a gecko engineer, probably better on #webcompat channel. if not, "report site issue" probably is best |
| * '''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. | | * '''honza''': probably people can use webcompat ? flag on bugzilla |
|
| |
|
| | * '''james''': yeah, it makes sense. the usecase for it, "I have a core issue and I want to make it a higher priority" |
|
| |
|
| === Top 20 sites for Bocoup (Honza) ===
| | * '''tom''': would be helpful if people use their github account as anonymous issue have higher chance of being closed |
| 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
| | === Get compat reports from all channels (Honza) === |
| * https://docs.google.com/spreadsheets/d/128x7npL8THeiGbXsYoiSRN3W19Ha7VrGN3zBUH5w3ik/edit#gid=0 | | * Blipz Experiment |
| | * What went well and what not |
| | * Can we get some inspriation and try again? |
|
| |
|
| Here's a doc from Bocoup on the approach for sourcing the list of Gecko-only featuers and criteria for scoring each feature:
| | * '''honza''': should we start getting webcompat reports from release channel? |
| * https://docs.google.com/document/d/12v1f_ZQTDR4BuEOBbp4xrE4ymWI6O_CtyA9A4K5Y7vU/edit#heading=h.wftc6qb14jhv
| |
| * Copy shared with everyone at Mozilla: https://docs.google.com/document/d/12v1f_ZQTDR4BuEOBbp4xrE4ymWI6O_CtyA9A4K5Y7vU/edit
| |
|
| |
|
| * Sources: caniuse, webkit.org/status, chromestatus.com/features, wpt, bcd | | * '''tom''': we haven't too much value from them. but if we just want to capture them to look at trends, I'm not against trying it again. But we need to be prepared for it. |
| * 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.
| | * '''dennis''': the data we recieved was absolute garbage, people just reported everything. it might be worth reconsidering if we do it right. |
|
| |
|
| * '''Simon''': See the second Google Document for details on the criteria. | | * '''tom''': we should make it org wide effort, not just webcompat. this might be a good opportunity to start talking to other teams about general error reporter |
| * '''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)
| | * '''james''': we need to know the metric on how many sites are broken, how bad is compatibility problem. it would be nice to have release reports as long as they don't have too much noise |
|
| |
|
| * '''Calin''': How should we treat anonymous bug reports related to payments/paid features, especially if the user claims it's an ETP issue? | | * '''tom''': as long as we have enough headcount / other teams it worth trying |
|
| |
|
| e.g. https://github.com/webcompat/web-bugs/issues/114611
| | * '''james''': perf looks like a good example and we got lots of reports. I don't think the usecase is getting high quality reports and such, but more for statistics and not for diagnosis. I would be nice to analyse reports not just from North America |
|
| |
|
| * '''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. | | * '''tom''': tracking protection team might be interested, but we have to be careful so we not end up looking at the issues only by ourselves. maybe data science team could help. |
| * '''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. | | * '''dennis''': we would need some better infrastructure for better handling of data |
| * '''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. | | * '''james''': it will have to be a completely different backend |
| * '''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. | | * '''simon''': there is a bias for reports in English, so we would need localisation. There is a document https://docs.google.com/document/d/1s07ZVHF0ZswrCuSoP9W2cmDritLXsqOuGlZwhYQy02A/edit#heading=h.uugefq19ogtp about capturing signals from developers regarding webcompat data |
| * '''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. | | * '''honza''': I could start talking to the perf team to see how this could be useful for them |
| * '''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. | | === Needs triage issues on the week of Nov 28th - Dec 2nd (Paul) === |
| | * We will probably not be able to triage everything incoming in the week due to 2 days of National holidays |
| | * Also, Raul will be on PTO the entire week, so only Calin will be triaging issues. |
| | * We'll return to 0 in the following week when Raul returns. Any concerns regarding this? |
| | |
| | |
| | === Work week meeting recorded? (Paul) === |
| | * Due to the same reasons, Calin might not be able to join the meeting as he will be quite busy with triage. |
| | * Will the meeting be recorded? We would like to watch it when we'll have the time. |
| | |
| | * '''honza''': we can record some important meetings. somebody should keep it in mind :) |
| | |
| | === "Cookie Banner Reduction" option - Android (SV) === |
| | * We have seen an interesting report about this option: [issue #114364](https://github.com/webcompat/web-bugs/issues/114364). How should we act upon such issues? The cookie banner is still showed, and the option is turned on by default in the browser. Is there a certain behaviour that we should look for when the option is enabled? |
| | |
| | * '''james''': this is probably not webcompat issues? they should be labeled |
| | |
| | * '''tom''': possibly we want to label and close them, but keep track of the list |
| | |
| | * '''dennis''': yeah I agree that we should close them |
| | |
| | * '''tom''': there is an extension to move issues from webcompat to bugzilla |
| | |
| | * '''paul''': just the list of such issues would help |
| | |
| | * '''raul''': can we close existing ones as non compat? |
| | |
| | * '''paul''': let's sync with the other QA team, but yes closing and keeping track of the issue should do it as they just need to know the domain |