[tracing] Remove debug UI pref requirement when accessing chrome://traces [chromium/src : main]
Gabriel Charette (Gerrit)
Gabriel Charette voted and added 1 comment![]( "Open in Gerrit")
Votes added by Gabriel Charette
| Commit-Queue | +1 |
1 comment
Rob, as discussed, we should move chrome://traces back to be considered a non-debug UI surface as the pref opt-in interstitial affects user flow and doesn't add a layer of security as it might for other entry points.
Related details
- Robert Liao
Code-Coverage
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Robert Liao (Gerrit)
Robert Liao voted and added 1 comment![]( "Open in Gerrit")
Votes added by Robert Liao
| Code-Review | +1 |
1 comment
CCing dpapad and rbpotter. This sounds reasonable to me.
Related details
- Gabriel Charette
Code-Coverage
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Gabriel Charette (Gerrit)
Gabriel Charette added 1 comment![]( "Open in Gerrit")
Thanks
@etiennep: c/b/tracing/traces_internals/
@rakina: /content/public
@csharrison: histograms/m/page/histograms.xml
Related details
- Charlie Harrison
- Etienne Pierre-Doray
- Rakina Zata Amni
Code-Coverage
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Demetrios Papadopoulos (Gerrit)
Demetrios Papadopoulos added 1 comment![]( "Open in Gerrit")
As discussed offline, we want to lift any hindrance to users followingNot blocking this CL, but posting my thoughts below for posterity.
Who was part of this discussion for the record? I don't recall any threads about it.
Note that presumably by removing the official "debug" bit from this UI, should be satisfying the requriements of "user-facing" UIs, per https://www.chromium.org/developers/webui/#debug-uis (localization, a11y, sufficient testsing). So either these are already met, or this removal is proliferating a "gray zone" between the two categories (user-facing vs debug), which we have tried to eliminate.
Also, there was an entire effort to make it as seamless as possible to enable debug WebuIs without a restart and without too many clicks (automatic forwarding back to the original UI) a while ago, so I don't quite undrestance why the "hindrance" you are refering to is such a big deal to eliminate, at the expense of creating the gray zone mentioned above. Do you really think that this is preventing people who actually do want to access `chrome://tracing` from using it?
Related details
- Charlie Harrison
- Etienne Pierre-Doray
- Gabriel Charette
- Rakina Zata Amni
Code-Coverage
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Charlie Harrison (Gerrit)
Charlie Harrison voted Code-Review+1![]( "Open in Gerrit")
Rakina Zata Amni (Gerrit)
Rakina Zata Amni voted Code-Review+1![]( "Open in Gerrit")
| Code-Review | +1 |
Related details
- Etienne Pierre-Doray
- Gabriel Charette
Code-Coverage
Code-Owners
Gabriel Charette (Gerrit)
Gabriel Charette added 1 comment![]( "Open in Gerrit")
As discussed offline, we want to lift any hindrance to users followingNot blocking this CL, but posting my thoughts below for posterity.
Who was part of this discussion for the record? I don't recall any threads about it.
Note that presumably by removing the official "debug" bit from this UI, should be satisfying the requriements of "user-facing" UIs, per https://www.chromium.org/developers/webui/#debug-uis (localization, a11y, sufficient testsing). So either these are already met, or this removal is proliferating a "gray zone" between the two categories (user-facing vs debug), which we have tried to eliminate.
Also, there was an entire effort to make it as seamless as possible to enable debug WebuIs without a restart and without too many clicks (automatic forwarding back to the original UI) a while ago, so I don't quite undrestance why the "hindrance" you are refering to is such a big deal to eliminate, at the expense of creating the gray zone mentioned above. Do you really think that this is preventing people who actually do want to access `chrome://tracing` from using it?
Not blocking this CL, but posting my thoughts below for posterity.
Who was part of this discussion for the record? I don't recall any threads about it.
I chatted with robliao@ offline about it.
Note that presumably by removing the official "debug" bit from this UI, should be satisfying the requriements of "user-facing" UIs, per https://www.chromium.org/developers/webui/#debug-uis (localization, a11y, sufficient testsing). So either these are already met, or this removal is proliferating a "gray zone" between the two categories (user-facing vs debug), which we have tried to eliminate.
I think this gray zone already exists (chrome://crashes as a sibling UI and prime example).
> Also, there was an entire effort to make it as seamless as possible to enable debug WebuIs without a restart and without too many clicks (automatic forwarding back to the original UI) a while ago, so I don't quite undrestance why the "hindrance" you are refering to is such a big deal to eliminate, at the expense of creating the gray zone mentioned above. Do you really think that this is preventing people who actually do want to access `chrome://tracing` from using it?
It's just one more thing and it doesn't add any value IMO. It's already a URL the user has to explicitly go to (can't follow a link to a chrome:// URL). I don't think it's worth spending energy adding friction in front of that flow.
Related details
- Etienne Pierre-Doray
Code-Coverage
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Etienne Pierre-Doray (Gerrit)
Etienne Pierre-Doray voted and added 1 comment![]( "Open in Gerrit")
Votes added by Etienne Pierre-Doray
| Code-Review | +1 |
1 comment
Gabriel Charette (Gerrit)
Gabriel Charette voted Commit-Queue+2![]( "Open in Gerrit")
| Commit-Queue | +2 |
Demetrios Papadopoulos (Gerrit)
Demetrios Papadopoulos added 1 comment![]( "Open in Gerrit")
As discussed offline, we want to lift any hindrance to users followingGabriel CharetteNot blocking this CL, but posting my thoughts below for posterity.
Who was part of this discussion for the record? I don't recall any threads about it.
Note that presumably by removing the official "debug" bit from this UI, should be satisfying the requriements of "user-facing" UIs, per https://www.chromium.org/developers/webui/#debug-uis (localization, a11y, sufficient testsing). So either these are already met, or this removal is proliferating a "gray zone" between the two categories (user-facing vs debug), which we have tried to eliminate.
Also, there was an entire effort to make it as seamless as possible to enable debug WebuIs without a restart and without too many clicks (automatic forwarding back to the original UI) a while ago, so I don't quite undrestance why the "hindrance" you are refering to is such a big deal to eliminate, at the expense of creating the gray zone mentioned above. Do you really think that this is preventing people who actually do want to access `chrome://tracing` from using it?
Not blocking this CL, but posting my thoughts below for posterity.
Who was part of this discussion for the record? I don't recall any threads about it.
I chatted with robliao@ offline about it.
Note that presumably by removing the official "debug" bit from this UI, should be satisfying the requriements of "user-facing" UIs, per https://www.chromium.org/developers/webui/#debug-uis (localization, a11y, sufficient testsing). So either these are already met, or this removal is proliferating a "gray zone" between the two categories (user-facing vs debug), which we have tried to eliminate.
I think this gray zone already exists (chrome://crashes as a sibling UI and prime example).
> Also, there was an entire effort to make it as seamless as possible to enable debug WebuIs without a restart and without too many clicks (automatic forwarding back to the original UI) a while ago, so I don't quite undrestance why the "hindrance" you are refering to is such a big deal to eliminate, at the expense of creating the gray zone mentioned above. Do you really think that this is preventing people who actually do want to access `chrome://tracing` from using it?It's just one more thing and it doesn't add any value IMO. It's already a URL the user has to explicitly go to (can't follow a link to a chrome:// URL). I don't think it's worth spending energy adding friction in front of that flow.
I think this gray zone already exists (chrome://crashes as a sibling UI and prime example).
I know the gray zone already exists, which is why I used the term "proliferate" instead of "introduce".
It's just one more thing and it doesn't add any value IMO
It sounds that you have objections about the overal goal of "programmatically categorizing user-facing WebUI from debug WebUI, and adding an extra click for regular users to visit debug WebUIs in order to protect them, given that debug WebUIs are held to much looser standards". Note that this categarization has been discussed at length already, before it was deployed.
Also your position of *"doesn't add any value"* has been discussed at length already, and for the most part is derived from taking a narrow view of debug WebUI owners of *"it does not add any value **to my team**"*, and overlooking the value it adds to the codebase as a whole, and also to the WebUI team maintenance burden, which are already listed at https://www.chromium.org/developers/webui/#debug-uis.
Note that [1] had been landed by etiennep@ to make it easier to access chrorme://tracing, but it sounds that it wasn't deemed enough in practice, or was there a change of opinion after the fact?
I don't think it's worth spending energy adding friction in front of that flow.
Understood. The current mechanism is designed in a way where individual WebUIs can opt-out of the categorization (as done in this CL), but note that it proliferates the wild wild west of Chromium debug WebUIs shipping as equal citizens along with the rest of the Chrome product (aka user-facing WebUIs) with whatever consequences/side-effeccts this can have.
[1] https://chromium-review.googlesource.com/c/chromium/src/+/6622116
Related details
- Gabriel Charette
Gabriel Charette (Gerrit)
Gabriel Charette added 1 comment![]( "Open in Gerrit")
I hear your concerns. In this case we will own whatever breakage may occur (and you can delete it if we go away as the whole point is to have a direct line to user diagnosis while we actively use that path).
Re. internationalization. I understand, but this is also where I think we need to not have "The great become the enemy of the good". If we add i18n, it's not clear that we will improve our diagnosis ability but we will definitely increase the bug surface you are trying to reduce.
I know there have been discussions about this in the past and I was likely one of the strongest opponents to adding this friction. Given this particular UI is not subject to all the concerns listed there, I asked Rob for an exception.
Related details
- Demetrios Papadopoulos
Chromium LUCI CQ (Gerrit)
Chromium LUCI CQ submitted the change![]( "Open in Gerrit")
Change information
[tracing] Remove debug UI pref requirement when accessing chrome://traces
As discussed offline, we want to lift any hindrance to users following
public docs to send traces to Chrome developers
Docs: https://bit.ly/chrome-trace
- M content/browser/tracing/traces_internals/traces_internals_ui.h
- M content/public/common/url_constants.h
- M tools/metrics/histograms/metadata/page/histograms.xml
Code-Review: +1 by Robert Liao, +1 by Charlie Harrison, +1 by Etienne Pierre-Doray, +1 by Rakina Zata Amni
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |