Bug 195104 – Web Inspector: Sources: disabled breakpoints banner should be sticky

• Status: RESOLVED
• Resolution: FIXED
• Component: Web Inspector

[Devin Rousso]

Created attachment 363102 [details]
[Image] Screenshot of Issue

It's not very helpful if you have a lot of breakpoints and want to disable/enable them quickly.

[Radar WebKit Bug Importer]

<rdar://problem/48442259>

[Devin Rousso]

Created attachment 364229 [details]
Patch

[Joseph Pecoraro]

Comment on attachment 364229 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=364229&action=review

> Source/WebInspectorUI/UserInterface/Views/SourcesNavigationSidebarPanel.css:125
> +@media (min-height: 600px) {

This is not described in the ChangeLog. What are you changing based on height?

> Source/WebInspectorUI/UserInterface/Views/SourcesNavigationSidebarPanel.js:1452
> +    _handleCallStackElementAddedOrRemoved(event)
> +    {
> +        function walk(parent) {
> +            let count = 0;
> +            if (!parent.root)
> +                ++count;
> +
> +            for (let child of parent.children)
> +                count += walk(child);
> +
> +            // Don't count the main thread element when it's hidden.
> +            if (parent instanceof WI.ThreadTreeElement && WI.targets.length === 1)
> +                --count;
> +
> +            return count;
> +        }
> +        this.element.style.setProperty("--call-stack-count", walk(this._callStackTreeOutline));
> +    }

How often does this happen? If huge call stack happens, such as (500 or 1000 elements is not uncommon on rAF loops), will this have been called 500 to walk the ...497,498,499,500 children?

It might be nice to take advantage of the fact that we should know tree outline has a depth of 2, so maybe we could compute faster:

    let count = 0;
    count += this._callStackTreeOutline.children.length;
    for (let threadElement of this._callStackTreeOutline)
        threadElement += this._callStackTreeOutline.children.length;

    // Don't count the main thread element when it is hidden.
    if (WI.targets.length === 1)
        --count;

Or maybe just enumerating the call frames list and not the tree elements.

[Devin Rousso]

Comment on attachment 364229 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=364229&action=review

>> Source/WebInspectorUI/UserInterface/Views/SourcesNavigationSidebarPanel.css:125
>> +@media (min-height: 600px) {
> 
> This is not described in the ChangeLog. What are you changing based on height?

I swear I wrote this down somewhere -.-  Oh well :(

The reason for this is at small heights, if we still were to disallow overflowing we'd end up in situations where each section would only be ~50px tall, which is barely enough to show more than one `WI.TreeElement` with the header of a `WI.DetailsSection`.  I chose 600px because it seemed like a nice number where each section would get an even amount of space, assuming they were all each individually overflowing into their own scrollable areas (e.g. the `.pause-reason-container` wouldn't go over ~80px since it's a single element with a known description length, each of `.call-stack-container` and `.breakpoints-container` are limited to a max of `135px`, leaving a good amount of space for the resources list since the 600px also includes the toolbar/tabbar/prompt/etc).

>> Source/WebInspectorUI/UserInterface/Views/SourcesNavigationSidebarPanel.js:1452
>> +    }
> 
> How often does this happen? If huge call stack happens, such as (500 or 1000 elements is not uncommon on rAF loops), will this have been called 500 to walk the ...497,498,499,500 children?
> 
> It might be nice to take advantage of the fact that we should know tree outline has a depth of 2, so maybe we could compute faster:
> 
>     let count = 0;
>     count += this._callStackTreeOutline.children.length;
>     for (let threadElement of this._callStackTreeOutline)
>         threadElement += this._callStackTreeOutline.children.length;
> 
>     // Don't count the main thread element when it is hidden.
>     if (WI.targets.length === 1)
>         --count;
> 
> Or maybe just enumerating the call frames list and not the tree elements.

I'll rework this (and the one for breakpoints) to add `.children.length` to hopefully make it a bit quicker.  Neither of them should ever have a depth more than 2, so I think that that would be fine.

[Devin Rousso]

Created attachment 365274 [details]
Patch

[Devin Rousso]

Created attachment 365276 [details]
Patch

[Devin Rousso]

Created attachment 365277 [details]
Patch

[WebKit Commit Bot]

Comment on attachment 365277 [details]
Patch

Rejecting attachment 365277 [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-03', 'land-attachment', '--force-clean', '--non-interactive', '--parent-command=commit-queue', 365277, '--port=mac']" exit_code: 2 cwd: /Volumes/Data/EWS/WebKit

Logging in as [e-mail]...
Fetching: https://bugs.webkit.org/attachment.cgi?id=365277&action=edit
Fetching: https://bugs.webkit.org/show_bug.cgi?id=195104&ctype=xml&excludefield=attachmentdata
Processing 1 patch from 1 bug.
Updating working directory
Processing patch 365277 from bug 195104.
Fetching: https://bugs.webkit.org/attachment.cgi?id=365277
Failed to run "['git', 'svn', 'dcommit', '--rmdir']" exit_code: 1 cwd: /Volumes/Data/EWS/WebKit

Committing to http://svn.webkit.org/repository/webkit/trunk ...
	M	Source/WebInspectorUI/ChangeLog

ERROR from SVN:
Item is out of date: File '/trunk/Source/WebInspectorUI/ChangeLog' is out of date
W: 2586a42906bbde7909294954322b6486128e1799 and refs/remotes/origin/master differ, using rebase:
:040000 040000 7149f95d37d047814148454a74a990c6efeb8496 1f50d7b699f9d063cbc264c15d6f81fb1cdc18a6 M	Source
Current branch master is up to date.
ERROR: Not all changes have been committed into SVN, however the committed
ones (if any) seem to be successfully integrated into the working tree.
Please see the above messages for details.


Failed to run "['git', 'svn', 'dcommit', '--rmdir']" exit_code: 1 cwd: /Volumes/Data/EWS/WebKit

Committing to http://svn.webkit.org/repository/webkit/trunk ...
	M	Source/WebInspectorUI/ChangeLog

ERROR from SVN:
Item is out of date: File '/trunk/Source/WebInspectorUI/ChangeLog' is out of date
W: 2586a42906bbde7909294954322b6486128e1799 and refs/remotes/origin/master differ, using rebase:
:040000 040000 7149f95d37d047814148454a74a990c6efeb8496 1f50d7b699f9d063cbc264c15d6f81fb1cdc18a6 M	Source
Current branch master is up to date.
ERROR: Not all changes have been committed into SVN, however the committed
ones (if any) seem to be successfully integrated into the working tree.
Please see the above messages for details.


Failed to run "['git', 'svn', 'dcommit', '--rmdir']" exit_code: 1 cwd: /Volumes/Data/EWS/WebKit
Updating OpenSource
From https://git.webkit.org/git/WebKit
   a5d701050c4..0c9d3f66ea6  master     -> origin/master
Partial-rebuilding .git/svn/refs/remotes/origin/master/.rev_map.268f45cc-cd09-0410-ab3c-d52691b4dbfc ...
Currently at 243201 = a5d701050c44b1ceb00597a55951a075668d733d
r243202 = c35164c1f4b9b756c1d550c768f44e4da66ca9e3
r243203 = 76eaf82c0366fd824da669a3127104ad474d0078
r243204 = 4f72278689eba06985fc5d3bdc3be6f29e3640e9
r243205 = 4895966e112528a82efec2c8e7b96378b7f64238
r243206 = 0c9d3f66ea6b0fafb552532f67d88d437da52d40
Done rebuilding .git/svn/refs/remotes/origin/master/.rev_map.268f45cc-cd09-0410-ab3c-d52691b4dbfc
First, rewinding head to replay your work on top of it...
Fast-forwarded master to refs/remotes/origin/master.

Full output: https://webkit-queues.webkit.org/results/11580924

[Devin Rousso]

Created attachment 365367 [details]
Patch

[WebKit Commit Bot]

Comment on attachment 365367 [details]
Patch

Clearing flags on attachment: 365367

Committed r243225: <https://trac.webkit.org/changeset/243225>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.