[Webkit-unassigned] [Bug 162865] New: Change behavior of tabs on macOS

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=162865

            Bug ID: 162865
           Summary: Change behavior of tabs on macOS
    Classification: Unclassified
           Product: WebKit
           Version: Safari 10
          Hardware: Macintosh
                OS: macOS 10.12
            Status: NEW
          Severity: Enhancement
          Priority: P2
         Component: Platform
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: craig.hockenberry at gmail.com

On iOS, both in native and web applications, there's a notion of "what's in front gets resources". If a web page or app isn't on screen, it's using little or no CPU time. They also have a reduced memory footprint.

I think this notion should be extended to the desktop version of Safari/WebKit.

Many users on the desktop end up with a lot of windows and tabs. It's not uncommon for me to have dozens, and I have friends who end up with hundreds (**cough** Siracusa **cough**). The web is a wonderful research tool, and as a result, we end up with a lot of "mind state" in the form of tabs.

To deal with this, many folks with tab glut have resorted to tools like this:

https://chrome.google.com/webstore/detail/the-great-suspender/klbibkeccnjlkjkiokjodocebajanakg?hl=en

I think the developers of the browser itself could do a lot better job at suspending tabs. Tabs become inactive because its container window is no longer frontmost or because it's replaced by another tab. When this happens a tab could be replaced with a picture of the content, it's process spun down, and memory resources deallocated.

Yes, there is probably a cost to replace that picture and restart the process when the tab becomes active again, but it would be much more bearable than overall system sluggishness and crashes associated with resource abuse. It's also going to save me time hunting down com.apple.WebKit.WebContent processes that are hogging the CPU and memory. 

Yes, it will probably break some websites. Just like getting rid of Flash did, but that turned out great in the end. Getting JavaScript developers into the same mindset as iOS developers would lead to a better web experience for everyone. If you know that Safari isn't going to run your script while it's in the background, you code accordingly.

I could also see this behavior as a user preference - one that self-reinforces. One of the times when I accumulate the most tabs is when I'm doing HTML/CSS/JavaScript development. I'm going to benefit from this change at the same time my code is being affected by suspension. As more developers learn why this is good for them, and for others, you could eventually turn this user preference on by default.

Thanks for your time in considering this proposal!

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20161003/19ae5055/attachment-0001.html>