Closed Bug 1266448 Opened 4 years ago Closed 4 years ago

Create a HTML Tooltip to display image previews

Categories

(DevTools :: Framework, enhancement, P1)

enhancement

Tracking

(firefox48 affected, firefox49 verified)

VERIFIED FIXED
Firefox 49
Iteration:
49.3 - Jun 6
Tracking Status
firefox48 --- affected
firefox49 --- verified

People

(Reporter: jdescottes, Assigned: jdescottes)

References

Details

(Whiteboard: [btpp-fix-later] [devtools-html])

Attachments

(4 files, 6 obsolete files)

Come up with a HTML based replacement for creating HTML tooltips to display image previews.

Image previews are currently created using Tooltip.js helpers :
- setImageContent
- setRelativeImageContent
- setBrokenImageContent

This tooltip is currently used by the markupview, the ruleview and the netmonitor.

This bug is about implementing the popup content. Displaying and positioning the popup will use the outcome of Bug 1259834.
Depends on: 1259834
Whiteboard: [btpp-fix-later] [devtools-html]
See Also: → 1171614
Flags: qe-verify+
Priority: -- → P1
QA Contact: alexandra.lucinet
See https://bugzilla.mozilla.org/attachment.cgi?id=8748624 for a first implementation prototype.
Assignee: nobody → jdescottes
Status: NEW → ASSIGNED
Iteration: --- → 49.1 - May 9
Depends on: 1270462
Iteration: 49.1 - May 9 → 49.2 - May 23
Attached patch bug1266448.part1.v1.patch (obsolete) — Splinter Review
Bug 1266448 - part1: fix remaining TooltipToggle callback;r=ochameau

In bug 1270462 we changed the expected return value of the hover callback
used for the toggle tooltips. All callbacks were migrated except one in
markup.js. This changeset fixes this as well as a test which was depending
on it.
Attachment #8752876 - Flags: review?(poirot.alex)
Attached patch bug1266448.part2.v1.patch (obsolete) — Splinter Review
Bug 1266448 - part2: use other Tooltip instance for image preview in markup view;r=ochameau

In preparation for using the HTML Tooltip in the markup view, we use now
a different tooltip instance for the image previews.
Attachment #8752877 - Flags: review?(poirot.alex)
Comment on attachment 8752876 [details] [diff] [review]
bug1266448.part1.v1.patch

Review of attachment 8752876 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good with the comment fixed.

::: devtools/client/inspector/markup/markup.js
@@ +2402,5 @@
>     * Checks if the target is indeed something we want to have an image tooltip
>     * preview over and, if so, inserts content into the tooltip.
>     *
> +   * @return {Promise} that resolves when the tooltip content is ready. Resolves
> +   * true or a DOM node if the tooltip should be displayed, false otherwise.

Hum. It seems to only return true or false, but never a DOM Node.
Looks like it should be something like:
"Resolves true if the tooltip should be displayed, false otherwise."
Attachment #8752876 - Flags: review?(poirot.alex) → review+
Comment on attachment 8752877 [details] [diff] [review]
bug1266448.part2.v1.patch

Review of attachment 8752877 [details] [diff] [review]:
-----------------------------------------------------------------

::: devtools/client/inspector/markup/markup.js
@@ -177,2 @@
>      } else {
> -      this.tooltip.startTogglingOnHover(this._elt,

This function is only used by _buildEventTooltipContent, which relates to this.tooltip. At least that's my comprehension of this code.
You should add a tooltip parameter or do something different here.

May be while you are at it, you could name the other tooltip "eventNameTooltip" or something similar. So that we know what each are about?
Attachment #8752877 - Flags: review?(poirot.alex)
Attached patch bug1266448.part3.wip.patch (obsolete) — Splinter Review
Can probably be cleaned up a lot, but I could use some feedback on the current implementation.

For now I decided to stick to the current arrow tooltip design, but I'll attach screenshots of the current state. Then we can start discussing how to deliver this.

You need the patches in Bug 1267401 in order to get the "arrow" styling for the html tooltip.
Attachment #8752896 - Flags: feedback?(poirot.alex)
Attached image html-tooltips-demo.gif
Attaching a GIF showing the HTML tooltips for the markup view on both light and dark themes. Try builds will be available at https://treeherder.mozilla.org/#/jobs?repo=try&revision=51eee685a85c

As I said before, the visuals and UX should be very close to what we have right now with the XUL tooltips.

Known differences:
- in small toolboxes, the tooltips will have a smaller height
- the tooltips no longer try to follow their anchor when a scroll occurs. This feature is quite buggy with the XUL tooltips, but we could have a follow up to bring it back.
- the box shadow of the tooltip are the same on OSX and Windows. With the XUL panels they are different, I guess they are handled by the OS ?

Given the visual differences I listed above (or any other you may find), we need to decide if we want to land this and enable the changes for our users, of keep it hidden (not implemented, or behind a preference) until more tooltips have been migrated. 

For instance we could wait until all tooltips of the inspector have been migrated. This way the user would be less likely to spot differences.

Helen: What do you think? Mixing tooltips could be disturbing/annoying for users?
Flags: needinfo?(hholmes)
Depends on: 1267401
(In reply to Julian Descottes [:jdescottes] from comment #7)
> - the box shadow of the tooltip are the same on OSX and Windows. With the
> XUL panels they are different, I guess they are handled by the OS ?

Can't you apply the same OS specific styles?

You can apply OS specific style with these rules:
   :root[platform="win"]
   :root[platform="mac"]
   :root[platform="linux "]
Do you have a test url for broken image tooltip?
Comment on attachment 8752896 [details] [diff] [review]
bug1266448.part3.wip.patch

Review of attachment 8752896 [details] [diff] [review]:
-----------------------------------------------------------------

There isn't much things to say in these modifications.
I don't know what you would cleanup as this patch is quite small?
So I mostly have nits.

::: devtools/client/inspector/markup/markup.js
@@ +2394,5 @@
>      this.tooltipDataPromise = Task.spawn(function* () {
>        let preview = yield this.node.getImageData(maxDim);
>        let data = yield preview.data.string();
> +      let {size} = preview;
> +      size.maxDim = maxDim;

nit: Wouldn't "max" be simplier and better?
maxDim ? max dimension?
size.max translates easily to max size.

@@ +2431,5 @@
>      }
>  
>      try {
>        let {data, size} = yield this._getPreview();
>        // The preview is ready.

nit: I'm wondering if size.maxDim should be set here, in isImagePreviewTarget. As _getPreview is more about the front request to fetch data from the actor.
And especially because maxDim is really about setImageTooltip, which expect this field and we call it there.

::: devtools/client/shared/widgets/HTMLTooltip.js
@@ -233,5 @@
>      let html;
>      if (this._isXUL()) {
>        html = '<iframe class="devtools-tooltip-iframe tooltip-panel"></iframe>';
>      } else {
> -      html = '<div class="tooltip-panel theme-body"></div>';

Just wondering... why do you get rid of theme-body here and in tooltip-frame?

::: devtools/client/shared/widgets/tooltip/ImageTooltipHelper.js
@@ +10,5 @@
> +const Services = require("Services");
> +loader.lazyGetter(this, "localize", () => {
> +  return Services.strings.createBundle(
> +    "chrome://devtools/locale/inspector.properties");
> +});

If you really want to help 1266075.
You should also encapsulate GetStringFromName here.

loader.lazyGetter(this, "localize", () => {
  let bundle = Services.strings.createBundle(
    "chrome://devtools/locale/inspector.properties");
  return key => {
    return bundle.GetStringFromName(key);
  };
});

I'm not sure it is really useful to comment about this refactoring,
we use l10n all over the place!!

@@ +35,5 @@
> + */
> +function getImageDimensions(doc, imageUrl) {
> +  return new Promise(resolve => {
> +    let imgObj = new doc.defaultView.Image();
> +    imgObj.src = imageUrl;

I would set the src after the onload handler, just to be sure, in case onload fires immediately.

@@ +39,5 @@
> +    imgObj.src = imageUrl;
> +    imgObj.onload = () => {
> +      imgObj.onload = null;
> +      let {naturalHeight, naturalWidth} = imgObj;
> +      resolve({naturalHeight, naturalWidth});

nit: spaces around brackets (also we tend to refer about the width first):
({ naturalWith, naturalHeight })

@@ +58,5 @@
> + * @param {Object} options
> + *        - {Number} naturalWidth mandatory width of the image to display
> + *        - {Number} naturalHeight mandatory height of the image to display
> + *        - {Number} maxDim optional max width/height of the preview
> + *        - {Boolean} hideDimensionLabel optional pass true to hide the label

nit: I would put a `,` after madatory and optional.

@@ +72,5 @@
> +  if (imgHeight > maxDim || imgWidth > maxDim) {
> +    let scale = maxDim / Math.max(imgHeight, imgWidth);
> +    // Only allow integer values to avoid rounding errors.
> +    imgHeight = Math.floor(scale * naturalHeight);
> +    imgWidth = Math.ceil(scale * naturalWidth);

I don't follow why you are using different roundings between width and height?

@@ +101,5 @@
> +                  text-align: center;">
> +        <span class="theme-comment devtools-tooltip-caption">${label}</span>
> +      </div>`;
> +  }
> +  div.innerHTML = html;

This is out of context to this bug, but I'm a bit surprised we still deal with html strings while everyone is doing React all over the place in devtools.
Attachment #8752896 - Flags: feedback?(poirot.alex) → feedback+
(In reply to Julian Descottes [:jdescottes] from comment #7)
> Created attachment 8752936 [details]
> html-tooltips-demo.gif
> 
> Attaching a GIF showing the HTML tooltips for the markup view on both light
> and dark themes. Try builds will be available at
> https://treeherder.mozilla.org/#/jobs?repo=try&revision=51eee685a85c
> 
> As I said before, the visuals and UX should be very close to what we have
> right now with the XUL tooltips.
> 
> Known differences:
> - in small toolboxes, the tooltips will have a smaller height
> - the tooltips no longer try to follow their anchor when a scroll occurs.
> This feature is quite buggy with the XUL tooltips, but we could have a
> follow up to bring it back.
> - the box shadow of the tooltip are the same on OSX and Windows. With the
> XUL panels they are different, I guess they are handled by the OS ?
> 
> Given the visual differences I listed above (or any other you may find), we
> need to decide if we want to land this and enable the changes for our users,
> of keep it hidden (not implemented, or behind a preference) until more
> tooltips have been migrated. 
> 
> For instance we could wait until all tooltips of the inspector have been
> migrated. This way the user would be less likely to spot differences.
> 
> Helen: What do you think? Mixing tooltips could be disturbing/annoying for
> users?

These changes I think are small enough that I don't think we need to ship these behind a pref—originally I thought you meant that we were shipping tooltips with two different visual styles, but it looks like some tooltips will just go beyond the boundary of devtools while some will not.

I think it's fine to ship without all of the tooltips converted, so long as file-up bugs are logged and worked on.
Flags: needinfo?(hholmes)
(In reply to Alexandre Poirot [:ochameau] from comment #10)
> Do you have a test url for broken image tooltip?

Don't know if you still need a test page but I'm using http://juliandescottes.github.io/devtools-demos/inspector/images.html (with absolute/relative/dataURI and broken URLs)

(In reply to Alexandre Poirot [:ochameau] from comment #8)
> (In reply to Julian Descottes [:jdescottes] from comment #7)
> > - the box shadow of the tooltip are the same on OSX and Windows. With the
> > XUL panels they are different, I guess they are handled by the OS ?
> 
> Can't you apply the same OS specific styles?
> 
> You can apply OS specific style with these rules:
>    :root[platform="win"]
>    :root[platform="mac"]
>    :root[platform="linux "]

Thanks for the pointers, I will look into this!
Attached patch bug1266448.part1.v2.patch (obsolete) — Splinter Review
Thanks for the review! 

I updated the comment. The "return a DOM Node" part was coming from the fact that this callback could return a DOM Node if it wanted to change the target of the tooltip to another node than the one being hovered.

It's true that this particular implementation does not use this though.

Carrying over r+.
Attachment #8752876 - Attachment is obsolete: true
Attachment #8754064 - Flags: review+
Attached patch bug1266448.part2.v2.patch (obsolete) — Splinter Review
As suggested, I renamed the other tooltip instance as well and updated the tests accordingly. 

(In reply to Alexandre Poirot [:ochameau] from comment #5)
> Comment on attachment 8752877 [details] [diff] [review]
> bug1266448.part2.v1.patch
> 
> Review of attachment 8752877 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: devtools/client/inspector/markup/markup.js
> @@ -177,2 @@
> >      } else {
> > -      this.tooltip.startTogglingOnHover(this._elt,
> 
> This function is only used by _buildEventTooltipContent, which relates to
> this.tooltip. At least that's my comprehension of this code.
> You should add a tooltip parameter or do something different here.

When we build the event tooltip, we want to disable the image previews. So even though this is called when creating an event tooltip, this method really deals with the image preview tooltip.

This part is a bit messy, so I tried renaming the existing functions. Hopefully the new implementation should be easier to read.
Attachment #8752877 - Attachment is obsolete: true
Attachment #8754076 - Flags: review?(poirot.alex)
Attached patch bug1266448.part3.v1.patch (obsolete) — Splinter Review
Thanks for the feedback! Tried to address all the issues you raised here.
Attachment #8752896 - Attachment is obsolete: true
Attachment #8754080 - Flags: review?(poirot.alex)
(In reply to Alexandre Poirot [:ochameau] from comment #11)
> Comment on attachment 8752896 [details] [diff] [review]
> bug1266448.part3.wip.patch
> 
> Review of attachment 8752896 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> There isn't much things to say in these modifications.
> I don't know what you would cleanup as this patch is quite small?

Ok maybe cleanup is not the best word. I was just really unsure about the approach (helper creating HTML strings).

> So I mostly have nits.
> 
> ::: devtools/client/inspector/markup/markup.js
> @@ +2394,5 @@
> >      this.tooltipDataPromise = Task.spawn(function* () {
> >        let preview = yield this.node.getImageData(maxDim);
> >        let data = yield preview.data.string();
> > +      let {size} = preview;
> > +      size.maxDim = maxDim;
> 
> nit: Wouldn't "max" be simplier and better?
> maxDim ? max dimension?
> size.max translates easily to max size.
> 

Even though we have a size here, it is forwarded to setImageTooltip which expects an option object (which can also contain the hideDimensionLabel boolean).

> @@ +2431,5 @@
> >      }
> >  
> >      try {
> >        let {data, size} = yield this._getPreview();
> >        // The preview is ready.
> 
> nit: I'm wondering if size.maxDim should be set here, in
> isImagePreviewTarget. As _getPreview is more about the front request to
> fetch data from the actor.
> And especially because maxDim is really about setImageTooltip, which expect
> this field and we call it there.
> 

Thanks, done!

> ::: devtools/client/shared/widgets/HTMLTooltip.js
> @@ -233,5 @@
> >      let html;
> >      if (this._isXUL()) {
> >        html = '<iframe class="devtools-tooltip-iframe tooltip-panel"></iframe>';
> >      } else {
> > -      html = '<div class="tooltip-panel theme-body"></div>';
> 
> Just wondering... why do you get rid of theme-body here and in tooltip-frame?
> 

The theme-body has an opaque background while our "arrow" tooltips have transparent backgrounds. That being said, I should probably simply override the background-color when the tooltip type is "arrow". And this should move to the other bug, since it's not directly related to the image tooltip.

> ::: devtools/client/shared/widgets/tooltip/ImageTooltipHelper.js
> @@ +10,5 @@
> > +const Services = require("Services");
> > +loader.lazyGetter(this, "localize", () => {
> > +  return Services.strings.createBundle(
> > +    "chrome://devtools/locale/inspector.properties");
> > +});
> 
> If you really want to help 1266075.
> You should also encapsulate GetStringFromName here.
> 
> loader.lazyGetter(this, "localize", () => {
>   let bundle = Services.strings.createBundle(
>     "chrome://devtools/locale/inspector.properties");
>   return key => {
>     return bundle.GetStringFromName(key);
>   };
> });
> 
> I'm not sure it is really useful to comment about this refactoring,
> we use l10n all over the place!!
> 
> @@ +35,5 @@
> > + */
> > +function getImageDimensions(doc, imageUrl) {
> > +  return new Promise(resolve => {
> > +    let imgObj = new doc.defaultView.Image();
> > +    imgObj.src = imageUrl;
> 
> I would set the src after the onload handler, just to be sure, in case
> onload fires immediately.
> 
> @@ +39,5 @@
> > +    imgObj.src = imageUrl;
> > +    imgObj.onload = () => {
> > +      imgObj.onload = null;
> > +      let {naturalHeight, naturalWidth} = imgObj;
> > +      resolve({naturalHeight, naturalWidth});
> 
> nit: spaces around brackets (also we tend to refer about the width first):
> ({ naturalWith, naturalHeight })
> 
> @@ +58,5 @@
> > + * @param {Object} options
> > + *        - {Number} naturalWidth mandatory width of the image to display
> > + *        - {Number} naturalHeight mandatory height of the image to display
> > + *        - {Number} maxDim optional max width/height of the preview
> > + *        - {Boolean} hideDimensionLabel optional pass true to hide the label
> 
> nit: I would put a `,` after madatory and optional.
> 
> @@ +72,5 @@
> > +  if (imgHeight > maxDim || imgWidth > maxDim) {
> > +    let scale = maxDim / Math.max(imgHeight, imgWidth);
> > +    // Only allow integer values to avoid rounding errors.
> > +    imgHeight = Math.floor(scale * naturalHeight);
> > +    imgWidth = Math.ceil(scale * naturalWidth);
> 
> I don't follow why you are using different roundings between width and
> height?
> 

In the tooltip, the size of the image is only set by its height (or the max-height:100%). The width is not set, so it will just maintain the expected ratio. Even if the height is an integer, depending on the image ratio, the actual width might be a float. 
Here the ceil is to make sure we have enough width to avoid cropping the image.
Example: with 300 MAX_DIM, a 12x366 image has a scale of ~0.82. 
- 366 * scale = 300 (floor: 300, ceil: 300)
- 12 * scale = 9.83 (floor: 9, ceil: 10)

The container will be 10x300. The image width, computed from its height, will be 9.83px. 

However this simplified approach is an overkill with the other extreme: a 366x12 image.
The container will be 300x9. The image width, computed from its height, will only be 274.5px (366 * 9/12). Here I should adjust the scale after flooring the height. This would give me a container width of 275px, which is more accurate.

> @@ +101,5 @@
> > +                  text-align: center;">
> > +        <span class="theme-comment devtools-tooltip-caption">${label}</span>
> > +      </div>`;
> > +  }
> > +  div.innerHTML = html;
> 
> This is out of context to this bug, but I'm a bit surprised we still deal
> with html strings while everyone is doing React all over the place in
> devtools.

As discussed in standup, I agree. Do you mind if I deal with this in a follow up bug?
Attachment #8754076 - Flags: review?(poirot.alex) → review+
(In reply to Julian Descottes [:jdescottes] from comment #15)
> This part is a bit messy, so I tried renaming the existing functions.
> Hopefully the new implementation should be easier to read.

It is much much better!
(In reply to Julian Descottes [:jdescottes] from comment #17)
> In the tooltip, the size of the image is only set by its height (or the
> max-height:100%). The width is not set, so it will just maintain the
> expected ratio. Even if the height is an integer, depending on the image
> ratio, the actual width might be a float. 
> Here the ceil is to make sure we have enough width to avoid cropping the
> image.

Thanks for the detailed explaination!

> > This is out of context to this bug, but I'm a bit surprised we still deal
> > with html strings while everyone is doing React all over the place in
> > devtools.
> 
> As discussed in standup, I agree. Do you mind if I deal with this in a
> follow up bug?

Sure. I don't expect it to be easy!
Comment on attachment 8754080 [details] [diff] [review]
bug1266448.part3.v1.patch

Review of attachment 8754080 [details] [diff] [review]:
-----------------------------------------------------------------

That shouldn't require another review, but please ensure fixing the broken image tooltip before landing!

::: devtools/client/inspector/markup/markup.js
@@ +2394,3 @@
>      // Fetch the preview from the server.
>      this.tooltipDataPromise = Task.spawn(function* () {
> +      let maxDim = Services.prefs.getIntPref(PREVIEW_MAX_DIM_PREF);

maxDim is not longer used here.

@@ +2435,3 @@
>        // The preview is ready.
> +      let options = preview.size;
> +      options.maxDim = Services.prefs.getIntPref(PREVIEW_MAX_DIM_PREF);

nit: it may be easier to read like this:
let options = {
  size: previous.size,
  maxDim: Services.prefs...
};

::: devtools/client/shared/widgets/tooltip/ImageTooltipHelper.js
@@ +136,5 @@
> +    line-height: 30px;`;
> +
> +  let message = GetStringFromName("previewTooltip.image.brokenImage");
> +  div.textContent = message;
> +  return tooltip.setContent(div, 150, 30);

I imagine the width is too small, I only see "Could not load the".
Attachment #8754080 - Flags: review?(poirot.alex) → review+
Thanks for the reviews Alex! 

Regarding the width issue, it looks like this is another occurrence of the font being bigger on Linux than on other platforms.
I will start by adding a rule to reduce the font-size to 80% on Linux in devtools tooltips.

Ultimately, I should add a utility method to measure the size of static tooltips such as this one to avoid hardcoding the width/height.

New try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=e88fa6cf3ef3
Iteration: 49.2 - May 23 → 49.3 - Jun 6
Rebased, carry over r+.
Attachment #8754064 - Attachment is obsolete: true
Attachment #8756574 - Flags: review+
Rebased, carry over r+.
Attachment #8754076 - Attachment is obsolete: true
Attachment #8756575 - Flags: review+
Rebased, carry over r+.
Attachment #8754080 - Attachment is obsolete: true
Attachment #8756578 - Flags: review+
Try is green, except for unrelated clipboard failures on Windows 7, landing.
https://hg.mozilla.org/mozilla-central/rev/5b57f1df523a
https://hg.mozilla.org/mozilla-central/rev/036722f3eb04
https://hg.mozilla.org/mozilla-central/rev/a41f8a55229c
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 49
Found some inconsistencies while verifying that the image previews are properly displayed in Markup view, Rule view and Netmonitor - as it follows:
1. Intermittently, there is no preview for .svg → https://i.imgur.com/6VQOpHI.png
2. White image on white theme is barely visible → https://i.imgur.com/9t4lVfr.png
3. When scrolling up/down while mouse over an image, the preview is still displayed
4. No preview in Rule view for gifs/images → https://i.imgur.com/34Js6qC.png

Tested with latest 49.0a1 (from 2016-06-06), under Windows 10 64-bit, Ubuntu 16.04 64-bit and Mac OS X 10.10.5

Julian, what's your input regarding the above potential issues?
QA Whiteboard: [qe-dthtml]
Flags: needinfo?(jdescottes)
The image previews are actually not a new feature: they used to be implemented using XUL, in this bug we migrated them to HTML. However we reused/shared some of the code used for the XUL image previews, so old bugs might still be applicable to the new implementation. I think the issues you listed are existing bugs which didn't get fixed by migrating to HTML. 
 
The most important here is to check against regressions. If you can reproduce the issue with FF48 or earlier (and if we already have a bug to track the issue) then I think it's fine.

1. Reproducible with FF45, and I think this is tracked by Bug 932220
2. Reproducible with FF45, tracked by Bug 1067999 (looks like it could be fixed soon)
3. Reproducible with FF45, even though the behavior slightly changed here. The XUL Tooltip tries to follow its anchor when scrolling but it fails very quickly, the HTML tooltip simply doesn't move. We have Bug 938097 which aims to hide this tooltip on scroll. (I think I saw another bug for this but can't find it for now) 
4. Your screenshot looks correct to me: the image is a dark noisy texture, and that's what is displayed in the tooltip 

(By the way, you mentioned netmonitor in your comment, this one is still using the old XUL Tooltip (see Bug 1277264))
Flags: needinfo?(jdescottes)
(In reply to Julian Descottes [:jdescottes] from comment #29)
> The image previews are actually not a new feature: they used to be
> implemented using XUL, in this bug we migrated them to HTML. However we
> reused/shared some of the code used for the XUL image previews, so old bugs
> might still be applicable to the new implementation. I think the issues you
> listed are existing bugs which didn't get fixed by migrating to HTML. 
>  
> The most important here is to check against regressions. If you can
> reproduce the issue with FF48 or earlier (and if we already have a bug to
> track the issue) then I think it's fine.
> 
> 1. Reproducible with FF45, and I think this is tracked by Bug 932220
> 2. Reproducible with FF45, tracked by Bug 1067999 (looks like it could be
> fixed soon)
> 3. Reproducible with FF45, even though the behavior slightly changed here.
> The XUL Tooltip tries to follow its anchor when scrolling but it fails very
> quickly, the HTML tooltip simply doesn't move. We have Bug 938097 which aims
> to hide this tooltip on scroll. (I think I saw another bug for this but
> can't find it for now) 
> 4. Your screenshot looks correct to me: the image is a dark noisy texture,
> and that's what is displayed in the tooltip 

> (By the way, you mentioned netmonitor in your comment, this one is still
> using the old XUL Tooltip (see Bug 1277264))

Thanks for your prompt reply! 
Based on comment 0, I took it for granted and tested Netmonitor too :) sorry for the confusion.

Since all the mentioned issues are already tracked separately, marking here accordingly.
Status: RESOLVED → VERIFIED
Flags: qe-verify+
Depends on: 1326733
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.