Tooltips using React DOM #364

gregtatum · 2017-06-05T17:55:24Z

This adds a styled Tooltip component. Tooltips are surprisingly difficult, because a Tooltip component wants to be controlled and instantiated from some arbitrary point in the DOM and component hierarchy. However, tooltips DOM elements need to be created outside of that point to avoid clipping and placement issues with the current stacking context. React does not have a good built-in metaphor to do this.

Approaches

React DOM (Currently implemented)

With this implementation it's nice because each Tooltip component can be local to where it is created, but it doesn't create any DOM nodes until it's actually used. The React metaphor is maintained when actually using Tooltip component, as tooltips can be created locally by individual components. However the actual implementation has some funkiness where it re-renders manually on props changes using React DOM. I don't foresee any way this is brittle at the moment, as it works similarly to how any component manually editing the DOM would work, but uses the React DOM render method.

Using redux:

I evaluated placing the tooltip into the Redux store, but I was afraid of the performance impacts of constantly updating tooltip positions on mousemove.

Shared react component

This implementation would create a separate Tooltip mounted at startup, and existing for the lifetime of the application. It would then be passed somehow (either manually through props, globally, or through a connected component) and those components could set and unset the text.

React Context

Another approach could be to use a React context, but the docs make it sound like we can't guarantee on this feature continuing to exist. The pros would be a pretty clear abstraction for how the Tooltip works, but then the cons is trusting on a React API with an unclear future.

In conclusion

I'm fine with this current ReactDOM approach, but would listen to feedback if anyone feels strongly against it.

gregtatum · 2017-06-05T17:58:13Z

Oh and two other things, I'll squash out my first commit here on merge as it was my original implementation attempt, and this would be a good follow-up to test after merging the testing snapshot PR #353.

codecov-io · 2017-06-05T18:00:43Z

Codecov Report

Merging #364 into master will decrease coverage by 0.38%.
The diff coverage is 15.45%.

@@            Coverage Diff             @@
##           master     #364      +/-   ##
==========================================
- Coverage   36.46%   36.08%   -0.39%     
==========================================
  Files         123      124       +1     
  Lines        5953     6038      +85     
  Branches     1238     1262      +24     
==========================================
+ Hits         2171     2179       +8     
- Misses       3240     3303      +63     
- Partials      542      556      +14

Impacted Files	Coverage Δ
src/test/store/fixtures/profiles.js	`100% <ø> (ø)`	⬆️
src/content/components/TimelineViewport.js	`24.74% <ø> (ø)`	⬆️
src/content/components/FlameChartCanvas.js	`0% <0%> (ø)`	⬆️
src/content/components/IntervalMarkerOverview.js	`0% <0%> (ø)`	⬆️
src/content/containers/ProfileViewerHeader.js	`0% <0%> (ø)`	⬆️
src/content/profile-data.js	`65.58% <100%> (+0.16%)`	⬆️
src/content/components/TimelineMarkerCanvas.js	`44% <11.11%> (-1.84%)`	⬇️
src/content/components/Tooltip.js	`4% <4%> (ø)`
src/content/components/TimelineCanvas.js	`58.51% <80%> (+0.55%)`	⬆️
... and 1 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 242a901...86294f6. Read the comment docs.

julienw · 2017-06-06T10:11:58Z

One quick comment about However, tooltips DOM elements need to be created outside of that point to avoid clipping and placement issues with the current stacking context is that if you use the CSS position: fixed it should always be relative to the viewport (unlike position: absolute), and we should be able to position the tooltip using the click's MouseEvent clientX and clientY properties.

I'm especially worried about the accessibility of putting a DOM element somewhere not related.

julienw

I really like the behavior ! It feels really great ! There is one caveat: there is no way to copy the text that's inside the tooltip because it's disappearing too quick. This is not a regression because we can't do it in current master either, so we can discuss this later. I don't have a good idea to allow it anyway.

My main comment is to use position: fixed to position the tooltip. But otherwise I like it out of the app in a separate DOM element (like you did).
Another concern is how you use the state in the Tooltip component.

otherwise: nits, comments, and something about accessibility.

julienw · 2017-06-06T13:02:59Z

res/style.css

+  /* Create a stacking context so that tooltips can be placed over the root element. */
+  position: relative;
+  z-index: 0;
+}


I think you don't need this if you use position: fixed for the tooltip element.

I'm not convinced fixed would be a better implementation for this behavior. I like the explicitness of creating a stacking context and controlling the structure of the parent containers. I'm a little scared of the implicit stacking behavior of fixed position things, mainly because I can't find great documentation on it, especially since the behavior changed ~2012 from looking into it.

julienw · 2017-06-06T13:06:14Z

src/content/components/Tooltip.js

+    this._isMounted = true;
+    // Create a DOM node outside of the normal heirarchy.
+    const el = document.createElement('div');
+    el.className = 'tooltipMount';


how about always keeping the mount element in index.html ? This could also make it easier to debug with the inspector (being able to expand it :) )

Having it dynamic means we don't have to worry about treading on someone else's Tooltip. I don't think practically that would happen, but I was still concerned about a collision with 2 tooltip instances.

Also I was debugging the Tooltips by removing the ternary in the parent element so that the tooltip would always show.

julienw · 2017-06-06T13:07:30Z

src/content/components/Tooltip.js

+  }
+
+  render() {
+    return <div/>;


you can just return null.

julienw · 2017-06-06T13:16:42Z

src/content/components/Tooltip.js

+  /**
+   * This is really ugly, but the tooltip needs to be outside of the normal
+   * DOM heirarchy so it isn't clipped by some arbitrary stacking context.
+   */


not true if we use position: fixed

I tried it locally, and I was still running into stacking issues. fixed would break out of the overflow, but would still obey some stacking context rules.

to make my mind clearer: I think it's better anyway to have the tooltip element outside of the app's DOM hierarchy, but that using the fixed positioning would make it easier to position.

but this is not really a big deal

julienw · 2017-06-06T13:17:10Z

src/content/components/Tooltip.js

+    ReactDOM.render(
+        <div className='tooltip' style={style} ref={this._getMountElement}>
+          {children}
+        </div>,


nit: indentation

julienw · 2017-06-06T14:35:26Z

src/content/components/FlameChartCanvas.css

+
+.flameChartCanvasTooltip {
+  padding: 5px;
+}


just wondering why it's different for this tooltip ? I couldn't really debug and find out, because of the disappearing tooltip :)

Please add a comment explaining why, but I'd rather have something that works for all tooltips.

julienw · 2017-06-06T14:36:25Z

src/content/components/Tooltip.css

+  overflow: hidden;
+  text-overflow: ellipsis;
+  transition: opacity 250ms;
+  box-sizing: border-box;


nit: please put box-sizing closer to max-width as they're related.

bonus points for a new line after display

julienw · 2017-06-06T14:47:28Z

src/content/components/Tooltip.css

+.tooltipLabel {
+  display: block;
+  width: 60px;
+  color: var(--theme-highlight-gray);


this is way too pale for accessibility. See https://snook.ca/technical/colour_contrast/colour.html#fg=B4BABF,bg=FFFFFF

Still too pale :)

You could use #7B747A for example.

julienw · 2017-06-06T14:50:05Z

src/content/components/FlameChartCanvas.js

+          {category.name}
+        </div>
+        {resourceOrFileName}
+      </div>


I think I'd rather see this structure handled (and enforced) by the Tooltip component, especially if we're using the CSS classes that the Tooltip component defines.

Hmm... I'm not really sure how to handle that. I'd like the Tooltip to only handle the tooltip logic. I'd like the presentation to be free-form and up to the controlling element. When I'm implementing something per-panel I'd prefer to do what I want. Placing some shared style in the Tooltip css seemed the most convenient place.

Yeah, I think we can wait until we use tooltips at other places and see what we can generalize rather than decide now.

julienw · 2017-06-06T14:51:04Z

src/content/components/Tooltip.css

+  top: 0;
+  left: 0;
+  width: 100%;
+  height: 100%;


most of it should be useless when using position: fixed for the tooltip.

mstange · 2017-06-07T20:40:41Z

position:fixed stops doing what you want as soon as there's a transform on an ancestor. Elements with transforms are containing blocks for position:fixed descendants.

gregtatum · 2017-06-07T21:06:07Z

src/content/components/Tooltip.css

@@ -67,3 +68,46 @@
  width: 60px;
  color: var(--theme-highlight-gray);
 }
+
+.tooltipTiming {


I may have rewritten my history incorrectly here. I accidentally squashed my changes on the previous commit.

gregtatum · 2017-06-07T21:06:53Z

src/content/components/Tooltip.js

@@ -22,22 +22,22 @@ export default class Tooltip extends PureComponent {

  state: {
    interiorElement: HTMLElement | null,
-    interiorElementRAF: HTMLElement | null,
+    isNewContentLaidOut: boolean,


I refactored this a bit, it still has the same logic as before, but with hopefully better words and comments.

julienw · 2017-06-08T09:07:22Z

position:fixed stops doing what you want as soon as there's a transform on an ancestor. Elements with transforms are containing blocks for position:fixed descendants.

Oh, I didn't know this. But anyway I'm still in favor of having the Tooltip DOM element quite at the top of the DOM tree, so this shouldn't get in the way. I just think this is simpler and makes more sense to use position: fixed for this type of UI component that is always laid out somewhere in the screen, where the mouse is.

julienw · 2017-06-08T13:42:24Z

You'll need to rebase, there is a conflict with latest master.

julienw

some more comments, most important to me is the accessibility for one of the color used.

I'd really like to make it work with position: fixed but it's not worth spending too much time on this either.

julienw · 2017-06-08T14:30:15Z

src/content/components/IntervalMarkerOverview.js

-                title={title}/>
+                onMouseOut={this._onMouseOut}/>
+        {
+          tooltipContents


we don't check if we're currently "selecting" here (like isDragging below). I think you can easily get this information with the boolean state profileView.selection.isModifying.

I'm fine doing it in a separate patch, please file an issue if you'd prefer this :)

julienw · 2017-06-08T14:34:19Z

src/content/components/Tooltip.css

+.tooltipLabel {
+  display: block;
+  width: 60px;
+  color: var(--theme-highlight-gray);


Still too pale :)

You could use #7B747A for example.

gregtatum · 2017-06-08T15:19:40Z

The tooltips are position fixed now, and I've rebased.

julienw · 2017-06-08T15:23:05Z

The tooltips are position fixed now, and I've rebased.

youhou, thanks !

gregtatum · 2017-06-08T15:26:31Z

Ah, I didn't see your other comments.

julienw

I still don't really like the logic where we need to render twice -- which means 2 reflows but I don't have a better idea. Maybe we'll come back at this later.

Please fix the color for accessibility, and the last nit. Also please file a bug so that the offset takes the current dpi into account.

julienw · 2017-06-09T17:13:11Z

src/content/components/Tooltip.js

+  componentWillReceiveProps(nextProps: Props) {
+    if (nextProps.children !== this.props.children) {
+      // If the children are different, allow them to do an initial lay out on the DOM.
+      this.setState({isNewContentLaidOut: false });


nit: space after {

julienw · 2017-06-09T17:18:55Z

src/content/components/Tooltip.css

+.tooltipLabel {
+  display: block;
+  width: 60px;
+  color: var(--theme-highlight-gray);


…ncTable usage

This tooltip is a little weird, as it uses ReactDOM's render method to insert a DOM component outside of the normal DOM position. This is needed because tooltips need to be outside of the stacking context of the parent elements.

gregtatum requested review from julienw and mstange June 5, 2017 17:55

julienw requested changes Jun 6, 2017

View reviewed changes

gregtatum force-pushed the tooltips-react-dom branch from 17c01cf to a220158 Compare June 7, 2017 21:03

gregtatum commented Jun 7, 2017

View reviewed changes

julienw reviewed Jun 8, 2017

View reviewed changes

gregtatum force-pushed the tooltips-react-dom branch from a220158 to 287d0de Compare June 8, 2017 15:18

julienw approved these changes Jun 9, 2017

View reviewed changes

gregtatum added 2 commits June 9, 2017 14:46

Fix incorrect FuncTable definition and collapsePlatformStackFrames fu…

ff636b7

…ncTable usage

Add a tooltip component.

86294f6

This tooltip is a little weird, as it uses ReactDOM's render method to insert a DOM component outside of the normal DOM position. This is needed because tooltips need to be outside of the stacking context of the parent elements.

gregtatum force-pushed the tooltips-react-dom branch from a2eb0d2 to 86294f6 Compare June 9, 2017 19:50

gregtatum merged commit 0108cd9 into firefox-devtools:master Jun 9, 2017

Tooltips using React DOM #364

Tooltips using React DOM #364

Conversation

gregtatum commented Jun 5, 2017

Approaches

React DOM (Currently implemented)

Using redux:

Shared react component

React Context

In conclusion

gregtatum commented Jun 5, 2017

codecov-io commented Jun 5, 2017 • edited Loading

Codecov Report

julienw commented Jun 6, 2017 • edited Loading

julienw left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mstange commented Jun 7, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

julienw commented Jun 8, 2017

julienw commented Jun 8, 2017

julienw left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gregtatum commented Jun 8, 2017

julienw commented Jun 8, 2017

gregtatum commented Jun 8, 2017

julienw left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

codecov-io commented Jun 5, 2017 •

edited

Loading

julienw commented Jun 6, 2017 •

edited

Loading