please lmk if there is a better place to put this information

@myles.borins Cool, thank you!

np

The issue was introduced in V8 6.2.146 [1] and fixed in V8 6.3.166 [2].
We use V8 6.3.292 in the master, and V8 6.1.something for 2.0.x releases, so we should be safe at least for now.
[1] https://github.com/nodejs/node/issues/19274#issuecomment-374298732
[2]

$ git branch -r --contains 596d55a | head
    branch-heads/6.3
    branch-heads/6.4
    branch-heads/6.5
    branch-heads/6.6
    origin/6.3-lkgr
    origin/6.3.166

(edited)

What can go wrong if we start an upgrade to Chromium 66 next?

yolo

I mean, worst case everything goes terribly and we drop back and start again on a closer version

We have time now.
2.0 is not stable yet, and we have Chromium 63 in the master for the 3.0.

We'll need to fully be on the PlzNavigate code path for sure, they're removing the old code path in 65

Any estimates for the PlzNavigate migration?

@alexeykuzmin Need a week with plznavigate, i can get it done. Will kick off the work today. And yes oopif transition is also needed for 66 but its not pressing as the old code path is not removed like plznavigate.

i’m seeing

Traceback (most recent call last):
    File "/Users/codebytere/Developer/libchromiumcontent/script/apply-patches", line 8, in <module>
      from lib.patches import PatchesConfig
    File "/Users/codebytere/Developer/libchromiumcontent/script/lib/patches.py", line 6, in <module>
      import yaml
  ImportError: No module named yaml

when i run script/update…any ideas? (edited)

Rerun bootstrap?

@codebytere ^ should be enough (edited)

@alexeykuzmin set the channel topic: Ch66 https://github.com/electron/electron/projects/10

So is the plan to skip some versions or will there be parallel development on 3 branches?

The plan is to make an upgrade to Chromium 66.

Will there be dev branches for upgrading to 64, 65, 66?

no, we’re gonna try to go straight to 66

Here’s a libcc branch for the Ch66 work: chromium-upgrade/66, https://github.com/electron/libchromiumcontent/commits/chromium-upgrade/66
I’ve fixed some of the patches, but not all of them. And I think it doesn’t make sense to create a PR yet, it will just create an unnecessary load on the CI. (edited)

Error: 11 patch(es) failed:
  patches/common/chromium/web_contents.patch
  patches/common/chromium/webgl_context_attributes.patch
  patches/common/chromium/worker_context_will_destroy.patch
  patches/common/chromium/webui_in_subframes.patch
  patches/common/chromium/export_blink_webdisplayitemlist.patch
  patches/common/chromium/restore_adding_custom_cors_enabled_schemes.patch
  patches/common/chromium/latency_histogram_macros.patch
  patches/common/chromium/gin_enable_disable_v8_platform.patch
  patches/common/chromium/disable-recursive-surface-sync.patch
  patches/common/chromium/can_disable_desktop_capture_throttling.patch
  patches/common/chromium/patch_catalog_vuln.patch

So libcc now builds on C66 for mac and linux 64, a quick run at Electron though looks like we need to bump crashpad this time around

Also blocked by https://github.com/nodejs/node/pull/19201

I pushed up a upgrade-to-chromium-66 branch to electron/electron so folks can play with stuff. Won't make a PR yet. Also pushed up a tmp-66 branch to electron/node which upgrades node to the branch in targos's PR linked above.

Libcc compilation works, but only because a few patches are disabled.
Tasks to fix them and enable back, and all other tasks, are on a project board here:
https://github.com/electron/electron/projects/10

> a few patches are disabled.
> Tasks to fix them and enable back, and all other tasks, are on the project board
Those are the most important tasks at the moment, btw. (edited)

So V8 6.6 is where they deprecate gyp

@alexeykuzmin Wrt https://github.com/electron/electron/projects/10#card-8464268, we can remove the resource_request_details.patch the corresponding electron api for which it is used, will be gone because of https://bugs.chromium.org/p/chromium/issues/detail?id=783981. I have already removed the event as a part of plznavigate https://github.com/electron/electron/commit/686c3d49690c7737c896ea552f9bc0ee5eebd544 because with browser side navigation every request has a corresponding blob request (this will improve with chromium 67 where mojo data pipes are used) and this event is just triggered twice as much with no usefulness for end users. Also when this event was created there wasn't any alternative, but later webRequest api was added which provides utilities to observe the same. So i am removing this event in favor of fixing all these problems.

Is anyone working on the "compositor_delegate.patch" for the Ch66? It's in the "In Progress" column, but doesn't have an assignee =/
https://github.com/electron/electron/projects/10#card-8464251

i was

@codebytere Have you checked this? https://bitbucket.org/chromiumembedded/cef/src/173d79a417b97aa62216d3c54531a4671aa3ff1f/patch/patches/compositor_1368.patch?at=3359&fileviewer=file-view-default (edited)

i will now haha

Most of the OSR patches are closely related to the CEF equivalents

It seems like nobody is actively working on the libcc’s Ch66 branch right now.
I’ll rebase it on the latest master and clean some stuff up there then. (edited)

> I’ll rebase it on the latest master and clean some stuff up there then.
The branch is rebased and forcepushed.

Have got plznavigate working on all platforms https://github.com/electron/electron/pull/12535, should unblock the work for ch66. Finally fixes a long standing navigation bug https://github.com/electron/electron/issues/3471. /cc @alexeykuzmin @zcbenz

BrowserThread::FILE has been removed in https://chromium-review.googlesource.com/890263.
Can someone eliminate at least some of its usages in the Electron code?
Here’s a “task” on the board: https://github.com/electron/electron/projects/10#card-8686851 (edited)

I was looking at that today, quite a few usages. Can deal with it on Monday if no one beats me to it

@Ed has joined the channel

Getting 403 forbidden when trying to bootstrap electron on the upgrade-to-chromium-66 branch.

@nitish try bootstrap.py --dev

Yes, running with --dev flag already.

@nitish on a mac?

@nitish there's no prebuilt binaries of the Ch66 branch for Mac

Okay. I’ve gone crazy. I just wanted to update the submodule. So need to run the update script, or git. (edited)

Hi! I would like some thoughts on the solution choices for https://github.com/electron/electron/projects/10#card-8868084 , thanks!

just pushed up a libcc bump to the electron PR, we've got S3 builds now thanks to VSTS

I have created https://github.com/electron/electron/projects/10#card-8900814 that has a list of features that don't have test suite in our code base and whose implementations were changed in this upgrade so far, please add the features/implementation changes that you find should be tested before merging 66. Thanks!

Is anyone working on https://github.com/electron/electron/projects/10#card-8854138 ?

@brenca? i think it’s related to changes from the patch i removed earlier

Yup, this is the one (edited)

Great, thank you!

FYI, I just rebased the Electron’s Ch66 branch to resolve merge conflicts and squash all fixup! commits.
cc @robo, @trycl

The debug build is still not expected to pass, so I didn’t run the CI jobs.
The branch misses fixes in the native-mate submodule and probably some others.

FYI… if you want macos to build for Chromium 66 libcc, rebase to the latest from master to get the updated CI changes.

> rebase to the latest from master to get the updated CI changes
Done

Electron builds on Mac and Linux fail on linking with a number of undefined symbol: viz:::FrameSinkVideoConsumer* errors.
All of them are related to the new implementation of atom:::FrameSubscriber. Any ideas how they can be fixed?
cc @brenca

We might have to add //services/viz as a dep in our build.gn, AFAICS it's not being built currently

@brenca that’s can be the reason, thx! I’ll try to do it now. (edited)

@brenca
Just did a clean build of libcc with the //services/viz added to deps and then built Electron. Got the same linking errors.

does //services/viz pull everything starting with //services/viz? the implementation I used as a base has //services/viz/privileged/interfaces/compositing as a dep

We build them exactly like Chromium does. At least I haven’t seen any changes in the build configs.

services/viz/privileged/interfaces/compositing was built

My last guess is that our create-dist script is not copying the built lib files, but this is a bit beyond my skills

@alexeykuzmin the implementation is built as a source_set by //services/viz:lib , we should create a library target depending on it in the component_build. The more we use mojo, we will be facing with this issue. Another reason why electron has to be built as a part of libcc. (edited)

It seems like we don't need/want source_sets at all. Maybe we can build them all as static libraries?

> Maybe we can build them all as static libraries?
this needs patching the configs instead having it as a source_set allows us to workaround the current issue by linking them into our custom library target and exporting it.

I’m going to rebase libcc’s Ch66 branch onto the latest master to fix Mac builds.
cc @robo @trycl

> rebase libcc’s Ch66 branch onto the latest master
Done.
I’m also going to rebase Electron’s Ch66 branch to resolve merge conflicts.
cc @robo @trycl