Open
Bug 959765
Opened 10 years ago
Updated 2 years ago
DevTools - Image tooltip shows with non-image urls
Categories
(DevTools :: Inspector, defect, P3)
Tracking
(Not tracked)
REOPENED
People
(Reporter: ntim, Unassigned)
Details
Seems understandable this way.
Reporter | ||
Updated•10 years ago
|
Flags: needinfo?(pbrosset)
Comment 1•10 years ago
|
||
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)
Comment 2•10 years ago
|
||
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)
Comment 3•10 years ago
|
||
Confirmed comment 1 in 29.0a1 (2014-01-21), win 7 x64.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 4•10 years ago
|
||
Another type of URL were this is a problem: filter: url('#f5');
Comment 5•10 years ago
|
||
(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)
Updated•8 years ago
|
Priority: -- → P3
Comment 6•6 years ago
|
||
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
Reporter | ||
Updated•6 years ago
|
Status: RESOLVED → REOPENED
Resolution: INACTIVE → ---
Updated•6 years ago
|
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
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•