Since <a target=_blank> open in the same WebContent process, we should be nice and give them a little extra margin on their memory kill limits.
Created attachment 313570 [details] Patch
Comment on attachment 313570 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=313570&action=review r=me > Source/WTF/ChangeLog:3 > + Increase memory kill limits for WebContent process that manage multiple tabs. processes
Created attachment 313572 [details] Patch for landing
Comment on attachment 313572 [details] Patch for landing Rejecting attachment 313572 [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-02', 'apply-attachment', '--no-update', '--non-interactive', 313572, '--port=mac']" exit_code: 2 cwd: /Volumes/Data/EWS/WebKit Last 500 characters of output: unk #1 succeeded at 1 with fuzz 3. patching file Source/WebCore/page/Page.cpp Hunk #1 succeeded at 287 (offset 1 line). Hunk #2 succeeded at 316 (offset 1 line). patching file Source/WebCore/platform/graphics/cocoa/FontCacheCoreText.cpp Hunk #1 FAILED at 1293. 1 out of 1 hunk FAILED -- saving rejects to file Source/WebCore/platform/graphics/cocoa/FontCacheCoreText.cpp.rej Failed to run "[u'/Volumes/Data/EWS/WebKit/Tools/Scripts/svn-apply', '--force']" exit_code: 1 cwd: /Volumes/Data/EWS/WebKit Full output: http://webkit-queues.webkit.org/results/3974756
Created attachment 313574 [details] Patch for landing :|
Comment on attachment 313574 [details] Patch for landing Clearing flags on attachment: 313574 Committed r218669: <http://trac.webkit.org/changeset/218669>
All reviewed patches have been landed. Closing bug.
Would have been better to use the term “page” or even “view” rather than “tab” in this context (and similar contexts in WebKit). The macOS Mail app, for example, uses one web process for multiple web views in a single conversation view (and across multiple conversation views), which do not appear as separate tabs or even windows.
(In reply to mitz from comment #8) > Would have been better to use the term “page” or even “view” rather than > “tab” in this context (and similar contexts in WebKit). The macOS Mail app, > for example, uses one web process for multiple web views in a single > conversation view (and across multiple conversation views), which do not > appear as separate tabs or even windows. Sure, that's a fair point. Let's go with Page then, since that's the name of the object we're counting. Long term I'd like us to come up with a better name for Page :|
<rdar://problem/32567548>