Bug 39991 - Web Inspector: Add whitelisting for panels based on user input
Summary: Web Inspector: Add whitelisting for panels based on user input
Status: RESOLVED INVALID
Alias: None
Product: WebKit
Classification: Unclassified
Component: Web Inspector (Deprecated) (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-06-01 06:19 PDT by Simon Thulbourn
Modified: 2014-12-12 14:09 PST (History)
7 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Simon Thulbourn 2010-06-01 06:19:19 PDT
Proposal: 
Add a whitelisting feature to the inspector so people could make selected panels auto enable for specific sites based on user input, either direct url (http://webkit.org) or via regexp pattern (\w+.webkit.org).
Comment 1 Simon Thulbourn 2010-06-01 06:19:41 PDT
UI concepts will come later today, once I finish work.
Comment 2 Patrick Mueller 2010-06-01 06:54:08 PDT
This is for resource tracking in the Resources panel, debugging on the Scripts panel, profiling on the Profiles panel, audits on the Audits panel?  Anything else?

In terms of UI concepts, we've talked in the past about some kind of "preferences" page, this would probably be a good thing to have on a preferences page, if we had one.  :-)
Comment 3 Simon Thulbourn 2010-06-01 07:00:51 PDT
Yes, there the only 4 panels that need to be enabled (at the minute).

If there were preferences for the inspector, where would it be placed? in the browser prefs or a new one specific to the inspector?

(In reply to comment #2)
> This is for resource tracking in the Resources panel, debugging on the Scripts panel, profiling on the Profiles panel, audits on the Audits panel?  Anything else?
> 
> In terms of UI concepts, we've talked in the past about some kind of "preferences" page, this would probably be a good thing to have on a preferences page, if we had one.  :-)
Comment 4 Pavel Feldman 2010-06-01 07:32:49 PDT
(In reply to comment #3)
> Yes, there the only 4 panels that need to be enabled (at the minute).
> 

Audits does not need to be enabled, so it is 
- Resources, Scripts and Profiles for WebKit / JSC
- Resources only for Chromium (we don't need to explicitly enable profiling)

Wrt prefs page, I don't think we are ready for it. As of today, each panel has a splash screen while disabled. It could host a list of enabled domains. "Enable always" would split into "Enable for domain foo.com" and "Enable always".
Comment 5 Simon Thulbourn 2010-06-02 08:27:21 PDT
I suggest that it could be implemented by adding another radio item with the text of "whitelist webkit.org" and to be able to whitelist each panel independently of one another. 

To disable the whitelist, it would be the same as the "Always Enabled" option.
Comment 6 Timothy Hatcher 2010-06-02 08:45:19 PDT
An "enable for this domain" rtadio button was planned, but we didn't implement it. I still think it is a good idea. I think it is simplier than regex. Just whitelist whole domains.
Comment 7 Timothy Hatcher 2010-06-02 08:45:37 PDT
And subdomains of those domains.
Comment 8 Simon Thulbourn 2010-06-02 08:47:58 PDT
Yes, that sounds like a good optimisation to add. If more people agree, I can start it sometime this week.

(In reply to comment #6)
> An "enable for this domain" rtadio button was planned, but we didn't implement it. I still think it is a good idea. I think it is simplier than regex. Just whitelist whole domains.

(In reply to comment #7)
> And subdomains of those domains.
Comment 9 Pavel Feldman 2010-06-02 09:09:41 PDT
(In reply to comment #5)
> I suggest that it could be implemented by adding another radio item with the text of "whitelist webkit.org" and to be able to whitelist each panel independently of one another. 
> 
> To disable the whitelist, it would be the same as the "Always Enabled" option.

You still need to show the list somewhere to avoid confusion and allow removing entries from there. I think the panel enabler view would be best for it. I agree with the rest, I think it is safe to start putting the mock and the patch together.
Comment 10 Brian Burg 2014-12-12 14:09:56 PST
Closing as invalid, as this bug pertains to the old inspector UI and/or its tests.
Please file a new bug (https://www.webkit.org/new-inspector-bug) if the bug/feature/issue is still relevant to WebKit trunk.