Wednesday, Mar 21

myles.borins
19:18
please lmk if there is a better place to put this information
6.2 on 8.10.0 broke some meteor stuff and other libraries doing weird threading stuff
alexeykuzmin
19:31
@myles.borins Cool, thank you!
myles.borins
19:37
np
alexeykuzmin
19:44
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)
Sunday, Mar 25

alexeykuzmin
23:09
What can go wrong if we start an upgrade to Chromium 66 next?
codebytere
23:10
yolo
id support it
marshallofsound
23:12
I mean, worst case everything goes terribly and we drop back and start again on a closer version
it might be a big job, but would catch us up pretty quick
I will say though, the last time we skipped 1 Chromium version we had a noticeably harder time (59 -> 61)
But I think we've made a lot of progress since then around testing and upgrading. So I'm on giving 66 a shot
But 66 isn't stable for a while right?
~4 weeks? (edited)
alexeykuzmin
23:14
We have time now.
2.0 is not stable yet, and we have Chromium 63 in the master for the 3.0.
Yes, Ch66 is not stable yet. But I don’t expect any massive changes in there by the time it gets stable.
But we might have to finish some heavy refactorings before we can use Ch66, like OOPIF, maybe something else. cc @robo (edited)
marshallofsound
23:21
We'll need to fully be on the PlzNavigate code path for sure, they're removing the old code path in 65
alexeykuzmin
23:44
Any estimates for the PlzNavigate migration?
I mean roughly will it take days, weeks, or months?
Monday, Mar 26

robo
11:31
@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.
codebytere
11:32
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)
it also fails with that when i try to apply patches
marshallofsound
13:49
Rerun bootstrap?
alexeykuzmin
14:26
@codebytere ^ should be enough (edited)
alexeykuzmin
19:43
@alexeykuzmin set the channel topic: Ch66 https://github.com/electron/electron/projects/10
ales
20:54
So is the plan to skip some versions or will there be parallel development on 3 branches?
alexeykuzmin
21:12
The plan is to make an upgrade to Chromium 66.
> there be parallel development on 3 branches?
I’m not sure if I fully understand the question though ) (edited)
ales
23:09
Will there be dev branches for upgrading to 64, 65, 66?
codebytere
23:10
no, we’re gonna try to go straight to 66
bypassing 64, 65 (edited)
Tuesday, Mar 27

alexeykuzmin
03:26
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)
alexeykuzmin
03:39
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
Thursday, Mar 29

marshallofsound
12:36
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
marshallofsound
13:29
ETA: April 17th, 2018
Checklist
☑︎ make -j4 test (UNIX), or vcbuild test (Windows) passes
☑︎ commit message follows commit guidelines
CI: https://ci.nodejs.org/job/node-test-pull-request/13568/
V8: https://ci.nodejs.org/job/node-test-commit-v8-linux/1254/
marshallofsound
15:00
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.
alexeykuzmin
18:22
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
> we need to bump crashpad this time around
@marshallofsound I thought we agreed to bump it every time we bump Chromium )
Anyway I created a task on the project board for that.
Friday, Mar 30

alexeykuzmin
00:19
> 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)
myles.borins
05:46
So V8 6.6 is where they deprecate gyp
you can follow along in https://github.com/nodejs/node/pull/19201 with all the things we are having to do to get it working
ETA: April 17th, 2018
Checklist
☑︎ make -j4 test (UNIX), or vcbuild test (Windows) passes
☑︎ commit message follows commit guidelines
CI: https://ci.nodejs.org/job/node-test-pull-request/13568/
V8: https://ci.nodejs.org/job/node-test-commit-v8-linux/1254/
I THINK… that the build is currently working, but the issue is in our infra getting V8-CI to work
will keep you updated, likely to dig in early next week
robo
22:58
@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.
Monday, Apr 2

alexeykuzmin
23:55
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
codebytere
23:55
i was
it’s a hot mess though
a lot changed
Tuesday, Apr 3

codebytere
03:22
i will now haha
brenca
03:23
Most of the OSR patches are closely related to the CEF equivalents
I usually check https://bitbucket.org/chromiumembedded/cef/wiki/BranchesAndBuilding to see which branch is what version, and go from there
Wednesday, Apr 4

alexeykuzmin
20:02
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)
Friday, Apr 6

alexeykuzmin
01:43
> I’ll rebase it on the latest master and clean some stuff up there then.
The branch is rebased and forcepushed.
robo
02:28
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
alexeykuzmin
20:58
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)
marshallofsound
21:52
I was looking at that today, quite a few usages. Can deal with it on Monday if no one beats me to it
Saturday, Apr 7

Ed
06:37
@Ed has joined the channel
Wednesday, Apr 11

nitish
03:04
Getting 403 forbidden when trying to bootstrap electron on the upgrade-to-chromium-66 branch.
jkleinsc
03:06
@nitish try bootstrap.py --dev
nitish
03:07
Yes, running with --dev flag already.
jkleinsc
03:07
@nitish on a mac?
alexeykuzmin
03:11
@nitish there's no prebuilt binaries of the Ch66 branch for Mac
only relatively old revisions
jkleinsc
03:11
nitish
03:12
Okay. I’ve gone crazy. I just wanted to update the submodule. So need to run the update script, or git. (edited)
Don’t know what I was thinking. Thanks!
robo
16:27
Hi! I would like some thoughts on the solution choices for https://github.com/electron/electron/projects/10#card-8868084 , thanks!
Thursday, Apr 12

marshallofsound
13:34
just pushed up a libcc bump to the electron PR, we've got S3 builds now thanks to VSTS
robo
14:01
robo
14:20
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!
Friday, Apr 13

alexeykuzmin
00:10
../../atom/browser/api/frame_subscriber.h:10:10: fatal error: 'content/browser/renderer_host/render_widget_host_view_frame_subscriber.h' file not found
  It has been removed in https://crrev.com/c/896588
codebytere
00:11
@brenca? i think it’s related to changes from the patch i removed earlier
create_window
brenca
00:12
Yup, this is the one (edited)
I'll take a look at it
alexeykuzmin
00:16
Great, thank you!
Monday, Apr 16

alexeykuzmin
21:02
FYI, I just rebased the Electron’s Ch66 branch to resolve merge conflicts and squash all fixup! commits.
cc @robo, @trycl
alexeykuzmin
21:09
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.
jkleinsc
23:48
FYI… if you want macos to build for Chromium 66 libcc, rebase to the latest from master to get the updated CI changes.
alexeykuzmin
23:54
> rebase to the latest from master to get the updated CI changes
Done
Thursday, Apr 19

alexeykuzmin
19:08
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
brenca
19:30
We might have to add //services/viz as a dep in our build.gn, AFAICS it's not being built currently
alexeykuzmin
19:39
@brenca that’s can be the reason, thx! I’ll try to do it now. (edited)
alexeykuzmin
21:06
@brenca
Just did a clean build of libcc with the //services/viz added to deps and then built Electron. Got the same linking errors.
brenca
21:16
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
and btw this uses mojo, not sure how we build the generated mojo proxies in libcc
alexeykuzmin
21:19
We build them exactly like Chromium does. At least I haven’t seen any changes in the build configs.
alexeykuzmin
21:32
services/viz/privileged/interfaces/compositing was built
brenca
23:03
My last guess is that our create-dist script is not copying the built lib files, but this is a bit beyond my skills
Yesterday

robo
04:48
@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)
alexeykuzmin
04:51
It seems like we don't need/want source_sets at all. Maybe we can build them all as static libraries?
Or it will will/can break something?
robo
04:59
> 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.
alexeykuzmin
20:18
I’m going to rebase libcc’s Ch66 branch onto the latest master to fix Mac builds.
cc @robo @trycl
alexeykuzmin
21:40
> 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