Open Bug 959765 Opened 10 years ago Updated 2 years ago

DevTools - Image tooltip shows with non-image urls

Categories

(DevTools :: Inspector, defect, P3)

29 Branch
defect

Tracking

(Not tracked)

REOPENED

People

(Reporter: ntim, Unassigned)

Details

Seems understandable this way.
Flags: needinfo?(pbrosset)
Tim, detailed STR would be nice.

STR:
- Open the Browser Toolbox
- Switch to the inspector
- Locate and select the element with ID="titlebar"
- See in the rule-view that the #titlebar{} selector has a -moz-binding: url('...'); declaration
- Hover over the URL part
=> A tooltip is displayed with "could not load image"
=> No image tooltip should be shown.

Our image URL detection mechanism should be made smarter.
Flags: needinfo?(pbrosset)
The way the image tooltip is attached to URIs in the rule-view today works with mouse-move.
If the hovered target is found to have class "theme-link" and its parent has "ruleview-propertyvalue", then we attach a tooltip.

So it obviously doesn't check if the resource is indeed an image.

I don't see any way, on the client-side, of checking if the URI provided is an image type or not. So one option would be to maintain a black list of CSS properties that should never receive an image tooltip, and then, on top of checking the 2 classNames mentioned earlier, we would also check the property name against this list.

Another option, which avoids having to maintain a list, is to fix bug 932896. With this approach, the client side would remain the same, simply attaching the tooltip to anything that resembles a URI, but then, at mouse-over time, when the image is indeed loaded, the server-side would check the resource type and only return the preview if it is an image.

I think option 2 makes more sense.
Paul? What do you think?
Flags: needinfo?(paul)
Confirmed comment 1 in 29.0a1 (2014-01-21), win 7 x64.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Another type of URL were this is a problem: filter: url('#f5');
(In reply to Patrick Brosset [:pbrosset] [:patrick] from comment #2)
> The way the image tooltip is attached to URIs in the rule-view today works
> with mouse-move.
> If the hovered target is found to have class "theme-link" and its parent has
> "ruleview-propertyvalue", then we attach a tooltip.
> 
> So it obviously doesn't check if the resource is indeed an image.
> 
> I don't see any way, on the client-side, of checking if the URI provided is
> an image type or not. So one option would be to maintain a black list of CSS
> properties that should never receive an image tooltip, and then, on top of
> checking the 2 classNames mentioned earlier, we would also check the
> property name against this list.
> 
> Another option, which avoids having to maintain a list, is to fix bug
> 932896. With this approach, the client side would remain the same, simply
> attaching the tooltip to anything that resembles a URI, but then, at
> mouse-over time, when the image is indeed loaded, the server-side would
> check the resource type and only return the preview if it is an image.
> 
> I think option 2 makes more sense.
> Paul? What do you think?

You fixed bug 932896, so I guess option 2 :)
Flags: needinfo?(paul)
Priority: -- → P3
Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INACTIVE
Status: RESOLVED → REOPENED
Resolution: INACTIVE → ---
Product: Firefox → DevTools

Given that ‑moz‑binding is being removed in bug 1566221, and this applies to other non‑image URLs, I’m changing this to have a more generic summary.

Summary: DevTools - Image tooltip shows with -moz-binding urls → DevTools - Image tooltip shows with non-image urls
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.