Publish minutes of 2022-03-03 meeting #171
Conversation
| * [alexei] This is a trust issue. Google's actions thus far have not inspired trust. | ||
| * [jack] MV3 not feature complete, deadline with MV2, not confident that we can resolve issues in time before Chrome fixes its issues. | ||
| * [craig] Major issue is the deadline. Never seen a transition like this in my 20 years. | ||
| * [mandoline] What about the vast majority of developers not represented in these meetings? Will their extensions just stop working one day because of Google's poor communication? |
There was a problem hiding this comment.
Should "mandoline" here and elsewhere be updated to Frederic?
There was a problem hiding this comment.
I wrote "mandoline" because that was the Zoom name.
There was a problem hiding this comment.
@ghostwords I want to merge this PR, and this is the only pending issue. Are you sure that these comments should be attributed to Frederic?
There was a problem hiding this comment.
I thought that was the person speaking in "mandoline", but I could be wrong!
There was a problem hiding this comment.
I'd suggest that land the minutes as is and follow up with Dashlane folks to see if we should update "mandoline" in a separate PR.
|
@dotproto, I don't know how we should comment on these excerpts so I'll post it here:
No, chrome.storage.session doesn't address "detrimental effects on performance". The overhead of initializing is still present: 50ms to start the worker + the time to start/compile the script(s). We need to prolong the lifetime of the service worker so that it doesn't restart hundreds of times a day, which may easily eat an hour off the battery. Please tell MV3 engineers to finally address this basic aspect of software performance because currently MV3 is wasting much more resources than a persistent script in MV2. Also, I'm afraid my earlier request to produce a verifiable evidence on why persistent background scripts are bad for performance was misunderstood, so I'll clarify why I'm even asking about it. MV3 plan claims that persistent background script is bad for performance and resource consumption, this claim has been reinforced in nearly every official announcement on MV3, but so far what we see in the real world doesn't match these claims, the real performance/consumption of MV3 extensions that hook into frequent events is much worse due to the overhead to restart the service worker. One such extension can nullify the gains from 10 simple non-persistent extensions. Each user is likely to have at least one such extension because any non-trivial use case requires hooking such frequent events. The plan also claims "the platform will evolve with the open web; as improvements to ServiceWorkers and the web platform are made, the extensions platform benefits from those same improvements." but now after 2 years we see that it's not true either: the service workers don't evolve in any meaningful way from the viewpoint of the extension-specific use cases and are many years behind the standard page environment that we were using in extension's background script for the past 10 years. Judging by the fact that the web platform doesn't need our extension-specific stuff, it will take Chromium team many years to replicate the lost functionality. |
|
|
||
| ## Meeting notes | ||
|
|
||
| Discussion item: Evidence for performance claims about persistent background scripts |
There was a problem hiding this comment.
As an extension maintainer, this doesn't really strike confidence that everything is going to be resolved by next year. As mentioned by craig, "It's unreasonable to impose deadlines and force rewrites on companies". A fake deadline to scare everyone into moving may be even less respectful. From my POV it would be better to compel developers with promises of better x, y, z, that could give products a competitive edge in their category.
The fact that extensions can no longer be updated, without exception, and the fact that chrome is now aggressively stating in the errors section of the developer console that MV2 extensions will no longer work come next year means that one must hedge bets.
There's a limited event page proposal that is implemented by Mozilla/Apple already that gave me some hope there might be a reasonable path forward one could follow without overdue (edit: overly paying) attention, but Google (who seems to chair this committee) is already proposing something different @ https://docs.google.com/document/d/1b-I-vXq2h7OFFmus78jZXIWcKilKJLKLeGplnY9wt7k/edit
This leaves me with the impression that I'll have to hawk this evolution and prepare for a service workers only scenario, (edit: while hoping the "limited event pages" proposal pans out).
As part of the review process for extensions it's already standard to have to justify use of permissions. Could there not be an extension of the existing (working just fine) api for a while longer provided there is a reasonable justification? If that seems like a lot of work ...
Currently, it takes very little extra work (in the scheme of things) to support multiple platforms with an extension. The future is now uncertain.
|
@dotproto The "Create a merge commit" option has disappeared from the Github UI. I manually created and committed a merge commit with the same format as before, so that the PR with commentary can be found via the commit history. Could you re-enable the creation of the merge commit? |
|
Undid the change; it’s possible to create merge commits again. |
Generated from https://docs.google.com/document/d/1QkwhEMtMS67JBUkl_WVPZ4lRSKoWcQNlLJSf_GwSXg8/edit using the tool and process from #105.
During this meeting we discussed or mentioned #165, #154, #170, #134 and PR #167. Although added to the agenda, we did not discuss #157, #164, #168, #169 because we ran out of time.