STEPS TO REPRODUCE: * Open up the styles sidebar. * Show computed or rules subsection * Opt-click on one of the property names. This takes you to the definition. * Click the back button in the content browser's nav bar. EXPECTED: * Should take you back to the content view + styles sidebar where the link was clicked ACTUAL: * It will navigate backwards in the tab-specific history, and not restore the styles sidebar
<rdar://problem/23774848>
This would have been the case pre-tabs. But now I'd say this is behaves correctly. I think doing this would be a confusing, slippery slope.
(In reply to comment #2) > This would have been the case pre-tabs. But now I'd say this is behaves > correctly. I think doing this would be a confusing, slippery slope. From an implementation or a UX standpoint? I found it very confusing to be dumped into the middle of a CSS file with no way to get back to the Elements tab. Especially if I option-click and don't know what it does.
From a UX standpoint. Back buttons in most (all?) apps including Safari don't switch containers (tabs). The Elements tab does not have back/forward buttons, but would you need to add them there so forward could take you "back" to the Resource you just came back from? The only UI analogous to this idea that I know of would be iOS 9's app back button that shows up in the status bar. Which is a different affordance, not connected to the content browser back/forward buttons.
(In reply to comment #4) > From a UX standpoint. Back buttons in most (all?) apps including Safari > don't switch containers (tabs). The Elements tab does not have back/forward > buttons, but would you need to add them there so forward could take you > "back" to the Resource you just came back from? > > The only UI analogous to this idea that I know of would be iOS 9's app back > button that shows up in the status bar. Which is a different affordance, not > connected to the content browser back/forward buttons. I guess it's just a consequence of treating each tab as its own content browser. This makes more sense to me in Safari than in Web Inspector, since our content views have lots of entangled state (most notably, breakpoints) while Safari tabs are completely independent. I guess I'll close this as WONTFIX since it would mean a bigger change to how we keep app state history. That said, I run into similar disorientation in resources vs debugger tab, so we maybe should revisit this design at some point.
For example, we could add breadcrumbs like those that are used for deep links on iOS. In some sense, what I proposed is a kind of deep link.
Yes, a breadcrumb back button separate from the content browser is what I was getting at. Something in the toolbar or dashboard.