1266448 - Create a HTML Tooltip to display image previews

Status: VERIFIED FIXED

(DevTools :: Framework, enhancement, P1)

Description

[Julian Descottes [:jdescottes]]

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.

Comment 1

[Julian Descottes [:jdescottes]]

See https://bugzilla.mozilla.org/attachment.cgi?id=8748624 for a first implementation prototype.

Comment 2

[Julian Descottes [:jdescottes]]

Attachment: bug1266448.part1.v1.patch

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.

Comment 3

[Julian Descottes [:jdescottes]]

Attachment: bug1266448.part2.v1.patch

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.

Comment 4

[Alexandre Poirot [:ochameau]]

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."

Comment 5

[Alexandre Poirot [:ochameau]]

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?

Comment 6

[Julian Descottes [:jdescottes]]

Attachment: bug1266448.part3.wip.patch

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.

Comment 7

[Julian Descottes [:jdescottes]]

Attachment: 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?

Comment 8

[Alexandre Poirot [:ochameau]]

(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 "]

Comment 9

[Alexandre Poirot [:ochameau]]

Here is some css applied to xul:tooltip
On OSX:
http://mxr.mozilla.org/mozilla-central/source/toolkit/themes/osx/global/popup.css#109
On Windows:
http://mxr.mozilla.org/mozilla-central/source/toolkit/themes/windows/global/popup.css#134

Comment 10

[Alexandre Poirot [:ochameau]]

Do you have a test url for broken image tooltip?

Comment 11

[Alexandre Poirot [:ochameau]]

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.

Comment 12

[Helen V. Holmes (:helenvholmes) (:✨)]

(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.

Comment 13

[Julian Descottes [:jdescottes]]

(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!

Comment 14

[Julian Descottes [:jdescottes]]

Attachment: bug1266448.part1.v2.patch

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+.

Comment 15

[Julian Descottes [:jdescottes]]

Attachment: bug1266448.part2.v2.patch

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.

Comment 16

[Julian Descottes [:jdescottes]]

Attachment: bug1266448.part3.v1.patch

Thanks for the feedback! Tried to address all the issues you raised here.

Comment 17

[Julian Descottes [:jdescottes]]

(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?

Comment 18

[Alexandre Poirot [:ochameau]]

(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!

Comment 19

[Alexandre Poirot [:ochameau]]

(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 20

[Alexandre Poirot [:ochameau]]

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".

Comment 21

[Julian Descottes [:jdescottes]]

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

Comment 22

[Julian Descottes [:jdescottes]]

Attachment: bug1266448.part1.v3.patch

Rebased, carry over r+.

Comment 23

[Julian Descottes [:jdescottes]]

Attachment: bug1266448.part2.v3.patch

Rebased, carry over r+.

Comment 24

[Julian Descottes [:jdescottes]]

Attachment: bug1266448.part3.v2.patch

Rebased, carry over r+.

Comment 25

[Julian Descottes [:jdescottes]]

Try is green, except for unrelated clipboard failures on Windows 7, landing.

Comment 26

[Pulsebot]

https://hg.mozilla.org/integration/fx-team/rev/5b57f1df523a
https://hg.mozilla.org/integration/fx-team/rev/036722f3eb04
https://hg.mozilla.org/integration/fx-team/rev/a41f8a55229c

Comment 27

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/5b57f1df523a
https://hg.mozilla.org/mozilla-central/rev/036722f3eb04
https://hg.mozilla.org/mozilla-central/rev/a41f8a55229c

Comment 28

[Ada [:adalucinet]]

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?

Comment 29

[Julian Descottes [: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))

Comment 30

[Ada [:adalucinet]]

(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.