Defining ENABLE_WEBPROCESS_WINDOWSERVER_BLOCKING as 1 will deactivate the WindowServer connection for the WebContent process.
<rdar://problem/38313938>
Created attachment 337612 [details] Patch
Comment on attachment 337612 [details] Patch r=me, but don't land until the build bots are ready.
Comment on attachment 337612 [details] Patch Thanks for reviewing!
Comment on attachment 337612 [details] Patch Clearing flags on attachment: 337612 Committed r230523: <https://trac.webkit.org/changeset/230523>
All reviewed patches have been landed. Closing bug.
Reverted r230523 for reason: Introduced MotionMark regression Committed r230552: <https://trac.webkit.org/changeset/230552>
Comment on attachment 337612 [details] Patch I am not able to reproduce the MotionMark regression now.
Comment on attachment 337612 [details] Patch Rejecting attachment 337612 [details] from commit-queue. Failed to run "['/Volumes/Data/EWS/WebKit/Tools/Scripts/webkit-patch', '--status-host=webkit-queues.webkit.org', '--bot-id=webkit-cq-01', 'validate-changelog', '--check-oops', '--non-interactive', 337612, '--port=mac']" exit_code: 1 cwd: /Volumes/Data/EWS/WebKit ChangeLog entry in Source/WTF/ChangeLog contains OOPS!. Full output: http://webkit-queues.webkit.org/results/7316375
Created attachment 337960 [details] Patch
Comment on attachment 337960 [details] Patch Clearing flags on attachment: 337960 Committed r230659: <https://trac.webkit.org/changeset/230659>
Re-opened since this is blocked by bug 184633
> r=me, but don't land until the build bots are ready. What Brent said. Rolling back now.
(In reply to Alexey Proskuryakov from comment #14) > > r=me, but don't land until the build bots are ready. > > What Brent said. Rolling back now. This should be okay to land now. The performance bots are now running the fixed QuartzCore, so this should be safe.
(In reply to Brent Fulgham from comment #15) > (In reply to Alexey Proskuryakov from comment #14) > > > r=me, but don't land until the build bots are ready. > > > > What Brent said. Rolling back now. > > This should be okay to land now. The performance bots are now running the > fixed QuartzCore, so this should be safe. ... and this does not introduce any build or test correctness issues.
Comment on attachment 337960 [details] Patch Clearing flags on attachment: 337960 Committed r230677: <https://trac.webkit.org/changeset/230677>
Comment on attachment 337960 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=337960&action=review > Source/WTF/wtf/FeatureDefines.h:241 > +#define ENABLE_WEBPROCESS_WINDOWSERVER_BLOCKING __MAC_OS_X_VERSION_MIN_REQUIRED >= 101400 Are you sure this pattern works? I seem to recall that this form does not work correctly. I think it needs to be more like: #if __MAC_OS_X_VERSION_MIN_REQUIRED >= 101400 #define ENABLE_WEBPROCESS_WINDOWSERVER_BLOCKING 1 #else #define ENABLE_WEBPROCESS_WINDOWSERVER_BLOCKING 0 #endif
(In reply to Darin Adler from comment #19) > Comment on attachment 337960 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=337960&action=review > > > Source/WTF/wtf/FeatureDefines.h:241 > > +#define ENABLE_WEBPROCESS_WINDOWSERVER_BLOCKING __MAC_OS_X_VERSION_MIN_REQUIRED >= 101400 > > Are you sure this pattern works? I seem to recall that this form does not > work correctly. I think it needs to be more like: > > #if __MAC_OS_X_VERSION_MIN_REQUIRED >= 101400 > #define ENABLE_WEBPROCESS_WINDOWSERVER_BLOCKING 1 > #else > #define ENABLE_WEBPROCESS_WINDOWSERVER_BLOCKING 0 > #endif I believe it works since I have tested this by building for several macOS versions. However, I will double-check.
Reverted r230677 for reason: Introduced Netflix problems. Committed r230811: <https://trac.webkit.org/changeset/230811>
Comment on attachment 337960 [details] Patch Clearing flags on attachment: 337960 Committed r230930: <https://trac.webkit.org/changeset/230930>