Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Publish minutes of 2022-03-03 meeting #171

Merged
merged 1 commit into from
Mar 17, 2022
Merged

Publish minutes of 2022-03-03 meeting #171

merged 1 commit into from
Mar 17, 2022

Conversation

Rob--W
Copy link
Member

@Rob--W Rob--W commented Mar 3, 2022

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.

* [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?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should "mandoline" here and elsewhere be updated to Frederic?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wrote "mandoline" because that was the Zoom name.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought that was the person speaking in "mandoline", but I could be wrong!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@tophf
Copy link

tophf commented Mar 3, 2022

@dotproto, I don't know how we should comment on these excerpts so I'll post it here:

  • [craig] Examples of detrimental effects on performance (overhead of initializing extensions instead of keeping in memory, e.g. password managers).
  • [simeon] The storage.session API addresses that class of concerns.

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.

@Rob--W Rob--W requested a review from dotproto March 10, 2022 16:58

## Meeting notes

Discussion item: Evidence for performance claims about persistent background scripts
Copy link
Member

@sublimator sublimator Mar 11, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@Rob--W Rob--W merged commit 0addc26 into main Mar 17, 2022
github-actions bot added a commit that referenced this pull request Mar 17, 2022
SHA: 0addc26
Reason: push, by @Rob--W

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
@Rob--W
Copy link
Member Author

Rob--W commented Mar 17, 2022

@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?

@dotproto
Copy link
Member

dotproto commented Mar 17, 2022

Undid the change; it’s possible to create merge commits again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants