I've spent the last few days investigating this.
I can very easily get into the broken state using downloaded cefclients from
http://opensource.spotify.com/cefbuilds/index.html. I found that all 3.3071 versions got stuck, but no 3.3029 versions did. I was running with the --off-screen-rendering-enabled flag only, on Windows 10.
I downloaded and built from source. Building as at 3.3071.1634 again produced a stuck cefclient, building as at 3.3029.1619 again produced a cefclient that I could not get into the stuck state. A quick[0] bisection of the CEF commits between these two revisions gave me that
2f6475c0 did not get stuck, and that
3f711386 did get stuck. Predictably, 3f711386 updates the Chromium version that CEF builds against.
- Code: Select all
λ git log branch-heads/3029..branch-heads/3071 | grep "^commit " | wc -l
11016
Only 11K commits that could break it
(This is a slight over-count, since there are commits after the known-broken one.)
Searching for "resize" in these commits produces some scary-looking changes, including:
At this point I am in quite a bit over my head. Bisecting the Chromium changes is difficult because the CEF changes needed to match them are combined into a
single commit that would need to be partially applied to match how the Chromium code would look at various stages between the endpoints of the bisection. There are a lot of changes there! I'm sure this is possible but it is not currently looking an attractive prospect.
My hope is that this bug has been caused by a simple oversight and a lack of a test case. I believe that someone familiar with the code could jump in here, take a close look at some of the Chromium changes knowing that this case fails, and quickly deduce what is wrong.
I am keen to get this bug fixed, and happy to offer assistance in whatever way I can! Just hesitant to jump in to further bisection...
[0] I'm not sure "quick" is the correct word given the amount of time this actually took.