Chromium

[Empty comment from Monorail migration]

[Empty comment from Monorail migration]

[Monorail components: Platform>DevTools]

Can reproduce.

[Monorail components: -Platform>DevTools Platform>DevTools>Authoring Platform>DevTools>UX]

It seems this is intentional
https://source.chromium.org/chromium/chromium/src/+/master:third_party/devtools-frontend/src/front_end/elements/ElementsPanel.js;l=858;drc=09e523d4093e70e6bf92a1e5bc0e3871c5f7a8a5?originalUrl=https:%2F%2Fcs.chromium.org%2F

🤔 If it's intentional, it's not working for seeing computed styles. Could it be changed to just be preserved as a separate tab?

Even with the "Computed" tab gone, I can access the computed styles (see attachment). Can't you ?
And yes, adding the tab shouldn't be a big problem. But might be breaking some other requirement from past of "merging the tabs in horizontal mode".

That's a fair remark, I never noticed (since typically the box model diagram pushes it below the inside fold and I tend to have the Console always on at the bottom). The confusing thing is that the Computed tab is back once you go ultra narrow (screenshot). Maybe it could just consistently stay there?

"Computed tab is back once you go ultra narrow....."
Yes, that's really strange behavior. But to be honest I'm not sure what's the best behavior.
As in super narrow case if we decide to keep "computed" merged, there should be a horizontal scroll bar then as there's not enough space.

My theory is the behavior of having "computed merged" was to make UX easier for "Dock to right" users. As then you don't have to switch back and forth for compute tab. (Just a theory :))

It's not a very strong argument, as one can also argue then why not make it merged for all modes. If it's better.

As discussed in the grid sync, Changhao will take a look.

[Empty comment from Monorail migration]

The following revision refers to this bug:
  https://chromium.googlesource.com/devtools/devtools-frontend/+/0b38e248bc279ca0747dd64380fb6934bbb26e62

commit 0b38e248bc279ca0747dd64380fb6934bbb26e62
Author: Changhao Han <changhaohan@chromium.org>
Date: Mon Jun 08 14:27:56 2020

Remove behavior of merging Computed pane in the Elements Tab

Currently when the width of the DevTools' viewport is within some range,
the Computed pane is merged inside the Styles pane. This behavior is
confusing and performance-intensive. This CL removes this bahavior.

Design doc: https://goo.gle/computed-pane-positioning

Bug: chromium:1073899
Change-Id: I2d2ed6feaf22f686c12105e71861ad360ee19b89
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2232945
Commit-Queue: Changhao Han <changhaohan@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Alex Rudenko <alexrudenko@chromium.org>
Auto-Submit: Changhao Han <changhaohan@chromium.org>

[modify] https://crrev.com/0b38e248bc279ca0747dd64380fb6934bbb26e62/front_end/ui/Widget.js
[modify] https://crrev.com/0b38e248bc279ca0747dd64380fb6934bbb26e62/front_end/elements/ElementsPanel.js

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/8e2ed6abdeb0e4c104ffb93d08a74547328154d7

commit 8e2ed6abdeb0e4c104ffb93d08a74547328154d7
Author: chromium-autoroll <chromium-autoroll@skia-public.iam.gserviceaccount.com>
Date: Mon Jun 08 19:13:30 2020

Roll DevTools Frontend from 4fa4342740a8 to 1557a1c16778 (2 revisions)

https://chromium.googlesource.com/devtools/devtools-frontend.git/+log/4fa4342740a8..1557a1c16778

2020-06-08 jacktfranklin@chromium.org Components dev server
2020-06-08 changhaohan@chromium.org Remove behavior of merging Computed pane in the Elements Tab

If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/devtools-frontend-chromium
Please CC devtools-waterfall-sheriff-onduty@grotations.appspotmail.com on the revert to ensure that a human
is aware of the problem.

To report a problem with the AutoRoller itself, please file a bug:
https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug

Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+doc/master/autoroll/README.md

Bug: chromium:1073899
Tbr: devtools-waterfall-sheriff-onduty@grotations.appspotmail.com
Change-Id: I736c7cee49d699f5617473f8a33574465c4d3298
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2235957
Reviewed-by: chromium-autoroll <chromium-autoroll@skia-public.iam.gserviceaccount.com>
Commit-Queue: chromium-autoroll <chromium-autoroll@skia-public.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#776146}

[modify] https://crrev.com/8e2ed6abdeb0e4c104ffb93d08a74547328154d7/DEPS

Design doc: https://goo.gle/computed-pane-positioning

[Empty comment from Monorail migration]

[Empty comment from Monorail migration]

I just got chrome update 85. And I have to say for me it's a lot worse now.
I use an ultrawidescreen for frontend development. I have my developer toolbar on the right side, and the "panel layout" was set to "horizontal" (so not auto/vertical).

This enabled me to see the HTML in the top pane,
and there was a nice "split pane" below, with the Styles and computed next to each other. This was perfect for widescreens, and you could quickly skip to the style that was setting that property.

Now I just have a lot of empty space in the bottom pane, and have to switch to see the computed values, this is a lot worse for my workflow actually.
It seems as this was only tested for pretty small screens?

I would love for this "fix" to be undone, or at least give us an option to keep the split "styles/computed" view.

Fixing the disappearing tab is fine in my opinion, it can stay there for consistency, but don't remove the split view.

See the screenshot for good explanation, this is just a waste of space really.

Very much agreed with the above, I find it incredibly frustrating now without the split view, loads of wasted space and definitely a change for the worse in this regard.

Make it configurable. I like previous behavior

it is incredibly frustrating now without the split view

I also use a wide screen and would love the split view behavior to be configurable (I want it back).

[Empty comment from Monorail migration]

We hear you.

[Empty comment from Monorail migration]

[Empty comment from Monorail migration]

Hi guys,

sorry, but i'm so disapointed about the current solution :-(

I am a web develper and Chrome devtools are my absolute favourite working horse - because of it's compact overview of all relevant DOM parameters in one view. I have the devtools open the whole day long and using Chrome Browser instead of Firefox for my developing work was an absolute no-brainer - until now.

One former main advantage of working with Chrome was, that in contrast to Firefox devtools the computed styles (bounding boxes AND styles) always were in ONE view with the active style list.

To monitor styles AND computed in one view is absolutely crucial when developing responsive UX. Now with the last update the computed control moved to a separate tab - out of sight. Now one of the most important advantages of Chrome devtools are gone :-(

I use the device simulation whole day long, when programming CSS / JS for responsive UX. If styles and computed are in ONE view together with DOM, you can exactly monitor what happens if you slowly increase or decrease viewport width or height. And the computed properties are absolutely important, because sometimes CSS do not work like expected. Classes and style rules seem to  change, but maybe you have a typo in your CSS. So you allways must verify, that the computed styles are really active.

Another point: if a computed style does not work like expected, maybee it's because of the specificity of another selector. So you typicaly check the origin of the computed style by expanding its sources and jump over to the styles list (click little gray arrow) to see from which style rule the active computed style property retrieved it's final value. This feature is so important when debuging your CSS.

Now, with styles and computed in 2 separate tabs you always switch back an forth to get a clue, why your CSS does not work like expected and where a "stronger" selector may cascade from or where you may have a typo in your CSS rules.

Again: to me the "old" panel layout with styles and computed in ONE view was an absolute key feature in Chrome devtools and a real benefit for my daily work. No it's almost as impractical as in Firefox devtools :-( In Firefox even the style, computed and layout are devided. This may look "nice an tidy" but is pretty useless when seriously using the devtools to debug and monitor your responsive layout during viewport changes.

PLEASE, PLEASE, PLEASE - make this devtools layout adjustable via a devtools setting. Styles AND computed (together with bouding box layout) have to be monitored in ONE view. As in the former panel layout.

Thanks

It sounds like we did over-simplify the solution, and we'll work on an update to bring this behavior back soon.

I just want to echo my preference for the previous layout as well. It's one of the main reasons I use Chrome dev tools over FF.

I appreciate that you are looking into it.

jec@, petermueller@, changhaohan@, and I just met to discuss this and we decided to move forward as follows:

- We’ll keep the standalone Computed tab as-is.
- Additionally, we’ll make it possible to view both the info in the Styles and Computed tabs at the same time, by adding UI to the Styles tab to toggle this. Ideally we want to keep the state between the two Computed views in sync. petermueller@ will create a UI mock for this, and changhaohan@ will investigate the technical feasability.
- We’ll add usage metrics so we can make data-driven decisions.

[Empty comment from Monorail migration]

I'm new to this - how quickly will we see the new changes mathias@chromium.org? And thanks so much to all for quick response!

This had been bothering me for many years, so thank you for addressing it. I had to keep my dev pane expanded more than desirable almost all the time to accommodate for this.
However, I hold the same viewpoints as expressed in https://crbug.com/chromium/1073899#c25. Once the old layout is established as a selectable option, this will have been addressed properly.
If resorting to the old approach will still force it to collapse on small screens, then my suggestion is to at least include an option to have the Computed section placed at the top of the Styles tab.

Have you opened a new crbug to track the continued work on this or should this one be re-opened? (I've looked but can't find the crbug. It would be great to get it linked in the comments here if it exists.)

Great you guys are looking into this.
mathias@chromium.org If I may add a suggestion, perhaps you already meant this, if so then ignore, but i think you can make this improvement more flexible and future proof:

- Keep the current tabs as is, with everything separated, it is consistent.

- But add a totally new "tab" called "Mixed" or "Columns" (or something like that).
-- You could implement the new "mixed" tab in 2 different ways, depending on difficulty:
-- Option 1: bring back the 'old' 2 column/pane layout, but with the extra option, of being able to choose what tab you want to see in which column/pane.
--- So in the old way, the columns were fixed on the "styles" and "computed" tabs. in my proposal, people could choose to see "event listeners" & "accessibility".
-- Option 2: Almost the same as option 1, but with the addition, that you could add as many columns as you want, instead of just the fixed 2.
--- This would be great for ultra-wide-screens: You would be able to have the "styles", "computed" and "accessibility" tab open at once, next to each other.

This solution would be much more flexible, and people would be able to customize the "mixed" tab more to their liking: maybe somebody wants to have the "computed" tab in the left pane, and the "styles" tab in the right, or whatever. And if you would be able to add as many columns as you want (or just make it a setting, 2/3/4 columns more would probably not fit, but why restrict it, maybe somebody has their dev tools open on their second screen and wants to have all the tabs open in one view next to each other)

Hope this helps. If this new solution would take to long, i would propose to revert this bugfix (because it's pretty annoying at the moment to be honest) and just steadily work on the new and improved solution.

To martigandrews@gmail.com: it will be added/brought back in Canary first, from where we'll gather more user feedback and make necessary adjustments, and be available in the next stable Chrome release (M86 in early October). This issue thread will be updated automatically when it lands in Canary.

To koolstr@gmail.com and bernard.skibinski@intracto.com: our plan is to always keep a separate Computed tab, while allowing developers to toggle on/off a 2-column layout in the Styles tab. For now these two columns will always be the current Styles tab's content + the Computed tab's content, because we want to address this quickly, and making it configurable / flexible will require more user study. But please rest assured that we know this is not permanent; we are consistently trying to improve how developers use the Elements panel, and a configurable layout in the sidebar pane definitely sounds interesting. Thanks for the idea :)

To shanejc@microsoft.com: let me reopen this one because in a sense this is a follow-up to Computed tab disappearing in responsive mode. Also most of the discussions are here, and it's hard to bring people yet to another issue.

Sounds great, and I think this is a great way to move forward, i know how much unexpected work a 'simple' new tab can bring. I won't pollute this thread further, and I'll switch to Canary. Thanks for listening to all the feedback. (wish i just had a thumbs up button for a comment or something ;-)

startswithj@yahoo.com, there is a lot of context in this issues thread. Please read before asking.

[Empty comment from Monorail migration]

I understand there are plans to resolve this regression, which involves going through the proper procedure of a user feedback loop to settle on a UX that works for everyone.

I'm curious however if this same procedure was followed when making the initial decision to remove the split pane view? It seems like a lot of assumptions were made in https://goo.gle/computed-pane-positioning that exclude a large, if not majority, user-base that relies heavily on the split pane for their development workflow.

It's baffling and concerning how a decision like this can make it into production without anyone stopping to think about the obvious implications of simply removing a feature that's been in DevTools since forever because one guy calls it a bug.

Perhaps instead of rushing the new UI, or making everyone wait an indeterminate amount of time to get split view back, this "fix" should be reverted in the next stable release since it's clearly not solving any more problems than it's causing.

[Empty comment from Monorail migration]

Please, revert. This was definitly NOT a bug but instead, a developer prefference😒
I miss having computed with styles.

[Empty comment from Monorail migration]

Just noticed this changed and agree with many of the comments here: I was used to the applied computed styles and box model being on the styles tab. Please bring the option back.

[Empty comment from Monorail migration]

[Empty comment from Monorail migration]

Just adding my voice to the many asking for the return of the computed and styles split pane view being inline ASAP. This was not a good move on your end.

Please bring the combined view back. I used that daily as a part of my my job. Thanks

[Empty comment from Monorail migration]

Same as everyone! Wish that feature came back. I was thinking maybe be able to right-click the second pane and have an option to "Open to the side". Or shift/ctrl/alt + click to tab title to open to the side, this could toggle that pane.

Hope this gets fixed soon!

[Comment Deleted]

I personally use the combined view at all times, and I was very dismayed to find it gone.
I propose that a setting be added to either consistently combine or consistently separate these tabs.
This will hopefully be the best of both worlds:
1. Developers can choose their preference, and it will stick.
2. There will be no unexpected shifting of tabs based on window size, which should solve the performance issue in question.
(If the content doesn't fit side-by-side at small window sizes, a horizontal scrollbar can simply be used, and if the user doesn't like scrolling, they can switch the setting to use separate tabs.)

Is there any kind of ETA as to when this might be kicked to Canary?

Felt the need to also voice my dismay about the new design. Really hoping it gets reverted or becomes optional/configurable in some way.

2020 has been rough enough  😬

[Empty comment from Monorail migration]

This change is stealing so much time over a working day. The amount of toing and froing and clicking is creating so much friction and reducing QOL at the moment. I still love Chrome and will wait for the fix but for now the solution for me is Firefox.

Seriously...
Moving away one of the most important things developers need to have visible all the time when the styles tab is selected...
The box model is one of the key pillars of layout development.
I will wait in firefox until this feature is back in the right place.

[Empty comment from Monorail migration]

I also want to add my voice to the list of users to much preferred how it was and hope this gets resolved soon

This forced change is horrible. Please at least give us the option to not show the computed tab and allow us to have the split panel like before. What a cumbersome update. Sheesh!

I'm very disappointed at some of the comments above. You are complaining about a change that was made with good intentions, to a free product, and solutions to address this issue are planned. I expect some understanding rather than passive-aggressive comments.

If you are eager to give feedback, I'd like you to consider to use Chrome's Canary channel to be able to experience changes to the product earlier.

Please also refer to Chromium's code of conduct. I'd like to keep discussions civil and constructive.

https://chromium.googlesource.com/chromium/src/+/master/CODE_OF_CONDUCT.md

Can you please provide a clear ETA?

It is clear that this little fix is having unforeseen effects. This is why most people are asking for a revert.

I can't emphasise enough how destructive this has been to my development workflow while still being respectful. You have added multiple clicks to something that needed none.

I don't know if this matters, I'm new to the forums, but this is the first time in years I'm having to work with other browsers.

Everyone, we hear your feedback, and we have repeatedly stated we’re working on addressing it. Please refrain from leaving “+1” comments that add no new information — it only slows us down at this point.

Re: https://crbug.com/chromium/1073899#c61, the best way to get updates on the progress is to star this bug. Thank you!

The following revision refers to this bug:
  https://chromium.googlesource.com/devtools/devtools-frontend/+/7b61e9210b440c6133758f9adcccbe460bd99808

commit 7b61e9210b440c6133758f9adcccbe460bd99808
Author: Changhao Han <changhaohan@chromium.org>
Date: Wed Sep 23 14:22:34 2020

Add collapsable Computed pane into Styles pane

This CL adds a collapable Computed sidebar pane to the right side of
the Styles pane. This sidebar pane is separate from the existing
standalone Computed pane, and is controlled by user clicks.
It will be collapsed by default, and will remember user choice across
DevTools sessions.

screencast: https://imgur.com/a/EkMCfMb

Bug: chromium:1073899
Change-Id: Id3a4d55ccb996935aa7093edc83d0cc4965a7310
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2422957
Reviewed-by: Alex Rudenko <alexrudenko@chromium.org>
Commit-Queue: Changhao Han <changhaohan@chromium.org>

[modify] https://crrev.com/7b61e9210b440c6133758f9adcccbe460bd99808/front_end/elements/elements_strings.grdp
[modify] https://crrev.com/7b61e9210b440c6133758f9adcccbe460bd99808/front_end/elements/StylesSidebarPane.js
[modify] https://crrev.com/7b61e9210b440c6133758f9adcccbe460bd99808/front_end/elements/ElementsPanel.js

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/b724fc6cbf205824c863e97fe437b54fbe54b983

commit b724fc6cbf205824c863e97fe437b54fbe54b983
Author: chromium-autoroll <chromium-autoroll@skia-public.iam.gserviceaccount.com>
Date: Wed Sep 23 20:08:11 2020

Roll DevTools Frontend from 2daeda990573 to 8134d1f70669 (5 revisions)

https://chromium.googlesource.com/devtools/devtools-frontend.git/+log/2daeda990573..8134d1f70669

2020-09-23 tvanderlippe@chromium.org Cleanup _loadModules in Runtime
2020-09-23 tvanderlippe@chromium.org Add back + button for style insertion of stylesheets
2020-09-23 jacktfranklin@chromium.org Ensure that data setters in components take an interface
2020-09-23 changhaohan@chromium.org Add collapsable Computed pane into Styles pane
2020-09-23 tvanderlippe@chromium.org Typecheck network/NetworkLogView.js with TypeScript

If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/devtools-frontend-chromium
Please CC devtools-waterfall-sheriff-onduty@grotations.appspotmail.com on the revert to ensure that a human
is aware of the problem.

To report a problem with the AutoRoller itself, please file a bug:
https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug

Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+doc/master/autoroll/README.md

Bug: chromium:1011811,chromium:1073899,chromium:1129881,chromium:1131500
Tbr: devtools-waterfall-sheriff-onduty@grotations.appspotmail.com
Change-Id: I9b8bcc22d80630824168c320162d7ce2e438b648
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2426804
Reviewed-by: chromium-autoroll <chromium-autoroll@skia-public.iam.gserviceaccount.com>
Commit-Queue: chromium-autoroll <chromium-autoroll@skia-public.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#809920}

[modify] https://crrev.com/b724fc6cbf205824c863e97fe437b54fbe54b983/DEPS

Just a heads-up: the long-requested Computed-pane-alongside-Styles-pane feature is now in Canary. The splitting behavior is now completely up to developers.

Would it make sense to get this back merged by one milestone so that folks don't have to wait as long for this fix?

I think so. I'll back-merge this tomorrow. Thanks for the suggestion :)

[Empty comment from Monorail migration]

This bug requires manual review: We are only 10 days from stable.
Before a merge request will be considered, the following information is required to be added to this bug:

1. Does your merge fit within the Merge Decision Guidelines?
- Chrome: https://chromium.googlesource.com/chromium/src.git/+/master/docs/process/merge_request.md#when-to-request-a-merge
- Chrome OS: https://goto.google.com/cros-release-branch-merge-guidelines
2. Links to the CLs you are requesting to merge.
3. Has the change landed and been verified on master/ToT?
4. Why are these changes required in this milestone after branch?
5. Is this a new feature?
6. If it is a new feature, is it behind a flag using finch?

Please contact the milestone owner if you have questions.
Owners: govind@(Android), bindusuvarna@(iOS), geohsu@(ChromeOS),  pbommana@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

1. yes
2. https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2422957
3. yes
4. it addresses a critical UX regression many users vocally demand
5. no
6. n/a

Approving merge to M86 branch 4240, please merge ASAP. Thank you.

[Comment Deleted]

The following revision refers to this bug:
  https://chromium.googlesource.com/devtools/devtools-frontend/+/71440668aa4222ef663149d22423b80895a973c4

commit 71440668aa4222ef663149d22423b80895a973c4
Author: Changhao Han <changhaohan@chromium.org>
Date: Mon Sep 28 21:41:51 2020

Add collapsable Computed pane into Styles pane

This CL adds a collapable Computed sidebar pane to the right side of
the Styles pane. This sidebar pane is separate from the existing
standalone Computed pane, and is controlled by user clicks.
It will be collapsed by default, and will remember user choice across
DevTools sessions.

screencast: https://imgur.com/a/EkMCfMb

Bug: chromium:1073899
Change-Id: Id3a4d55ccb996935aa7093edc83d0cc4965a7310
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2422957
Reviewed-by: Alex Rudenko <alexrudenko@chromium.org>
Commit-Queue: Changhao Han <changhaohan@chromium.org>
(cherry picked from commit 7b61e9210b440c6133758f9adcccbe460bd99808)
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2434524
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Auto-Submit: Changhao Han <changhaohan@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>

[modify] https://crrev.com/71440668aa4222ef663149d22423b80895a973c4/front_end/elements/elements_strings.grdp
[modify] https://crrev.com/71440668aa4222ef663149d22423b80895a973c4/front_end/elements/StylesSidebarPane.js
[modify] https://crrev.com/71440668aa4222ef663149d22423b80895a973c4/front_end/elements/ElementsPanel.js

[Comment Deleted]

Original behavior is correct and how the original developers intended it.

Hi guys,

I just checked the new collapsable layout in canary. The split option works fine for me and solves the last irritations :-)=)

One point to mention in actual canary Version 87.0.4279.0 (Offizieller Build) canary (64-Bit):

I see some flickering in the right panel (computed) during view updates when resizing the device simulation viewport on the left hand. Don't remember if this occured in the old layout too ?! This also applies to the 'standalone' computed tab.

I guess the reason ist, that the computed tab view now continuously updates in an unexpected manner.

If the list of computed styles is to long and exceeds the view box you can scroll down to the last styles in the list. But if you now resize the vieport simulation and the computed tab updates its view, the styles list is scrolled to the top again (scrollTop=0). Even if the number of list items remains the same.

With this behaviour you can't continuously monitor computed styles at the end of the list. You have to scroll down again after each tab view update. I guess this 'scroll jumping' is the reason for the flickering. To loose the scrolloffset of the styles list is not so funny :-|

In actual production release Version 85.0.4183.121 (Offizieller Build) (64-Bit) the computed tab does not flicker and keeps its scrolloffset until the number of style items really change (e.g. if a @media rule kicks in at a specific viewport size and alters the number of items in the styles list). The computed view should try to keep its scrolloffset as long as possible. This is how it should behave at the end.

Nevertheless - thanks for your work !

@cutterguide@gmail.com: thanks for reporting this. There's already an issue filed for it: https://bugs.chromium.org/p/chromium/issues/detail?id=1125060, but you bring up an interesting use case that will make me prioritize a workaround for this. Meanwhile you could see the details in that issue link to get more context on why this happens. Thanks!

[Empty comment from Monorail migration]

[Comment Deleted]

It would be totally great if we can have a "keyboard shortcut" to toggle the computed styles panel. Is it possible to have the kb shortcut to have it released in chrome 87. In-fact I was thinking if it's possible to have keyboard shortcuts for Styles and computed sub-panels. I think it would be totally awesome for designers & developers to have it.

IMHO, majority of my usage as far as elements panel is in the styles or computed panel (which I also think is true for many many more developers as well) and no keyboard shortcut support is ultimately hindering developer experience.

thanks

Please file a new feature request for that.

I just updated to 87.
I am reassured that David can still be heard by Goliath.
I can finally work again in good conditions,
Thank you

[Empty comment from Monorail migration]

This issue was migrated from crbug.com/chromium/1073899?no_tracker_redirect=1

[Multiple monorail components: Platform>DevTools>Authoring, Platform>DevTools>UX]
[Monorail blocking: crbug.com/chromium/1106251, crbug.com/chromium/1121497]
[Monorail mergedwith: crbug.com/chromium/1027856, crbug.com/chromium/1121497, crbug.com/chromium/1121919, crbug.com/chromium/1125104, crbug.com/chromium/1125124, crbug.com/chromium/1125167, crbug.com/chromium/1125529, crbug.com/chromium/1125912, crbug.com/chromium/1128130, crbug.com/chromium/1129503, crbug.com/chromium/1130010, crbug.com/chromium/1144859]
[Monorail components added to Component Tags custom field.]