Bug 122127
| Summary: | Web Inspector: changing cluster's content view causes strange navigation history | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Brian Burg <burg> |
| Component: | Web Inspector | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW | ||
| Severity: | Normal | CC: | inspector-bugzilla-changes, webkit-bug-importer |
| Priority: | P2 | Keywords: | InRadar |
| Version: | 528+ (Nightly build) | ||
| Hardware: | All | ||
| OS: | All | ||
Brian Burg
There's a strange interaction between changing content views within a ClusterContentView and the top-level ContentBrowser's back/forward navigation buttons (goForward/goBack).
Repro steps:
1. Start by showing a FrameContentView (click on main frame tree element)
2. Navigate to some other tree elements
3. Click the back button to go back to the FrameContentView
4. Change between DOM and Source view.
5. Click the forward button to see the inserted (instead of truncated + appended) new history entry.
This causes a back-forward entry to be added to a nested ContentViewContainer, but does not splice/prune forward entries from the top-level back forward list. So, there's a strange effect where you can extend the user-facing history (i.e., how many clicks needed to make ContentBrowser.{canGoBack, canGoForward} return false) from within.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Radar WebKit Bug Importer
<rdar://problem/15115274>
Timothy Hatcher
FrameContentView, the main user of ClusterContentView, is no longer used in the tab based UI. ResourceClusterContentView remains, but is used less and also might go away with some work.