Devtools splitters now have a clickable area on both sides of the splitter.
The previous layout provided a 3px clickable area (2px empty content + 1px
visible border).
The new layout uses invisible borders on both sides and a visible (clipped)
content. New draggable areas:
- side splitters : 1px left + 1px splitter + 4px right
- horizontal splitters : 2 px top + 1px splitter + 2px bottom
Variables are defined in splitters.css to adjust these settings.
Modified two test helpers opening context menus: the click should be
performed with a slight offset in order to avoid clicking on the splitter.
MozReview-Commit-ID: 94uFZoIBL7B
--HG--
extra : rebase_source : 55e6cb0f8f2ecbe1ae27ef9490925edfab7d62ce
extra : source : 4d5b0cdb72fe52f843c61a5df8f6b8ed35758be8
Devtools splitters now have a clickable area on both sides of the splitter.
The previous layout provided a 3px clickable area (2px empty content + 1px
visible border).
The new layout uses invisible borders on both sides and a visible (clipped)
content. New draggable areas:
- side splitters : 1px left + 1px splitter + 4px right
- horizontal splitters : 2 px top + 1px splitter + 2px bottom
Variables are defined in splitters.css to adjust these settings.
Modified two test helpers opening context menus: the click should be
performed with a slight offset in order to avoid clicking on the splitter.
MozReview-Commit-ID: 94uFZoIBL7B
--HG--
extra : rebase_source : 8683e8700c83feae6bddc869cacda03b156a9f91
extra : amend_source : 10cdeed511c02a907e99b74295fe25a3ad623030
All the other methods use the style
{
myMethod() { ... }
}
while these two methods use
{
myMethod: function () { ... }
}
For consistency, we should use the common style here.
MozReview-Commit-ID: 5rg8uPoULyN
Adds a keydown listener on the memory panel window. Select previous/next snapshot
when user presses UP/DOWN with the accelKey modifier (metaKey on OSX, ctrlKey on
windows).
Keydown events with modifiers are no longer listened to by the tree node elements.
Updated tree node test.
Added new mochitest to test the new keyboard navigation on the census view. )
Adds a keydown listener on the memory panel window. Select previous/next snapshot
when user presses UP/DOWN with the accelKey modifier (metaKey on OSX, ctrlKey on
windows).
Keydown events with modifiers are no longer listened to by the tree node elements.
Updated tree node test.
Added new mochitest to test the new keyboard navigation on the census view. )
--HG--
extra : commitid : 20wu80BaRXB
Only visible table rows are rendered, therefore we
cannot rely on :nth-child(2) to create background stripes.
This commit adds the source index to the treeNode props.
Using this index, the treeNode can add a "tree-node-odd"
className to its element.
In css, tree-node-odd is then used to add the alternate
background color to a row,
--HG--
extra : rebase_source : 9ce30781c0e7a2197486a7e0271283f87fc8dff5
This patch overhauls the memory tool's frontend from being in a state of viewing
a snapshot's census (the implicit default) or viewing a census diff (a special
cased kind of thing) to one of three recognized view states: (1) census, (2)
diffing, or (3) dominator tree. The logic surrounding our current view is more
explicit now. View option (3) is the new one, whose introduction required those
clean ups.
Dominator trees are too large to render in full, all at once. Instead, we
eagerly load and render a few levels deep and then incrementally fetch further
subtrees as their parents are expanded in the UI. This means that we get new
Tree component instances across incremental fetches. Before this commit, the
Tree component stored a bunch of state internally (in this.state rather than
this.props) and we would lose focus and expansion state across incremental
fetches. This internal state has been pulled out and made as explicit props,
which are now managed by actions and reducers just like the rest of the state.
--HG--
rename : devtools/client/memory/components/tree-item.js => devtools/client/memory/components/census-tree-item.js
In practice, we filter trees off-main-thread in a worker and the tree that we
pass to the Tree component is already filtered, which is a better architecture
anyways. Additionally, we lack any kind of tests for the Tree component's
built-in filtering. And finally, there isn't even a single user of the built-in
filtering functionality.
Dead it!
