Closed Bug 1305986 Opened 8 years ago Closed 7 years ago

Display the used font-name in the font preview tooltip

Categories

(DevTools :: Inspector: Rules, enhancement, P2)

enhancement

Tracking

(firefox52 wontfix)

RESOLVED DUPLICATE of bug 994559
Tracking Status
firefox52 --- wontfix

People

(Reporter: jdescottes, Assigned: jdescottes)

References

Details

Attachments

(5 files)

Enhancement for the font-preview tooltip, follow up to Bug 1302752. When hovering a font-family value such as > -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Helvetica, Arial, sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol" The preview tooltip will show a sample text using .SF NS Text (on OSX 10.11), but you have to go the Font panel to retrieve this information. It would be nice to get this information right in the preview tooltip.
See Also: → 1302752
Screenshot of a first implementation. Doing a proper implementation will actually be challenging. The only API available at the moment to get the list of used fonts needs a selection range [1], which works only on nodes inserted in the document AFAICT. The current patch I attached inserts a node in the content document in order to check the font used for a given "font-family" value. We should really avoid appending elements in the content document, so we need to find another way to do that. Looking at the current implementation of getUsedFontFaces, I feel like adding a new helper in DOMUtils to get the "used font" for a given font-family would face the same kind of issues: need to have an actual rendered node to work with. Maybe we could reuse anonymous content here. If we implement a getUsedFontFaces equivalent for nodes instead of ranges, we could use it with an anonymous content node and extend the AnonymousContent API to provide a getter getUsedFontFaceForElement. [1] DOMUtils::getUsedFontFaces and the implementation in nsRange http://searchfox.org/mozilla-central/rev/5bdd2876aeb9dc97dc619ab3e067e86083dad023/dom/base/nsRange.cpp#3064
Before investing more time into this, let's check if I'm the only one thinking this could be useful :). So to clarify, if the rule view displays something like > .container { > font-family: arial; > } > > div { > font-family: Monaco, monospace; > } > (open the attachment uploaded with this comment) I would like the preview tooltip to display that the used font family is Arial when hovering the property defined for ".container" and to display either Monaco or the default monospace font of the system when hovering on the property defined for "div". Helen, Patrick, let me know what you think.
Flags: needinfo?(pbrosset)
Flags: needinfo?(hholmes)
I agree, this sounds very useful.
Flags: needinfo?(pbrosset)
Makes sense to me! Seems like a nifty enhancement. Arguably we might not need the font panel with this sort of enhancement, which potentially was why you started work on it. I think another thing worth considering is displaying the typeface underneath the cursor. The reason I say this is this: A font stack might be applied, but perhaps not the first thing in the font stack; maybe it's the second or third. You can see the font used in the page, and you can see the font applied in the stack in the Rules area; if you can roll over the different font families within that stack, you might be able to better debug a problem by comparing those two things. Even better, if the preview used the same font-style and font-size as what's in the page, it'd be even easier to compare and make sure that the right font is being applied. But definitely: overall I approve! Seems like a good idea to me.
Flags: needinfo?(hholmes)
I'm not 100% sure if this is relevant, but when working on as-authored I found a number of old bugs about displaying fonts, and some had interesting examples showing how difficult the problem can be. This is maybe the best: https://bugzilla.mozilla.org/show_bug.cgi?id=760048#c3 This is also worth reading: https://bugzilla.mozilla.org/show_bug.cgi?id=994559#c3 (and also c4)
Thanks for the feedback! (In reply to Tom Tromey :tromey from comment #6) > I'm not 100% sure if this is relevant, but when working on as-authored I > found > a number of old bugs about displaying fonts, and some had interesting > examples > showing how difficult the problem can be. > > This is maybe the best: > https://bugzilla.mozilla.org/show_bug.cgi?id=760048#c3 > This is also worth reading: > https://bugzilla.mozilla.org/show_bug.cgi?id=994559#c3 > (and also c4) Thanks for the links, looks like I'm not the first to look into this topic :) But I think this improvement still makes sense. Right now devtools already make a decision by displaying a preview tooltip using the text "The quick brown fox jumped over the lazy dog.". The idea here is to improve the tooltip by also displaying the name of the font family that was used to display this string. Maybe "The quick brown fox jumped over the lazy dog." should not be used in all situations but I'd leave that for another bug.
(In reply to Julian Descottes [:jdescottes] from comment #7) > Maybe "The quick brown fox jumped over the lazy dog." should not be used in > all situations but I'd leave that for another bug. If you decide to continue Greeking, this works—it's the standard. There are some cuter alternatives but this one's familiar to most everybody. If you decide not to Greek, using a snippet of the paragraph they're inspecting would potentially be pretty handy for the reasons I stated above.
(In reply to Helen V. Holmes (:helenvholmes) (:✨) from comment #5) > Makes sense to me! Seems like a nifty enhancement. Arguably we might not > need the font panel with this sort of enhancement, which potentially was why > you started work on it. > > I think another thing worth considering is displaying the typeface > underneath the cursor. The reason I say this is this: > > A font stack might be applied, but perhaps not the first thing in the font > stack; maybe it's the second or third. > > You can see the font used in the page, and you can see the font applied in > the stack in the Rules area; if you can roll over the different font > families within that stack, you might be able to better debug a problem by > comparing those two things. Even better, if the preview used the same > font-style and font-size as what's in the page, it'd be even easier to > compare and make sure that the right font is being applied. > That's an interesting alternative! If we think about a value such as: "Monaco, monospace" on windows, hovering on "Monaco" would then show a preview using times new roman. Hovering on monospace would show a preview using courier new. In this case it's quite easy to compare the font used in the content page and see that it's the one for monospace that was picked. But if the two fonts are similar, wouldn't this make it harder for the user to understand which font-face is used? I'm not 100% convinced but I can try to implement it as another prototype :) > But definitely: overall I approve! Seems like a good idea to me. (In reply to Helen V. Holmes (:helenvholmes) (:✨) from comment #8) > (In reply to Julian Descottes [:jdescottes] from comment #7) > > Maybe "The quick brown fox jumped over the lazy dog." should not be used in > > all situations but I'd leave that for another bug. > > If you decide to continue Greeking, this works—it's the standard. There are > some cuter alternatives but this one's familiar to most everybody. > > If you decide not to Greek, using a snippet of the paragraph they're > inspecting would potentially be pretty handy for the reasons I stated above. That's a great suggestion, thanks! We could try to generate a preview based on the text content of the currently inspected node, if it has any. And if not, fallback on our sample text. This should improve the accuracy of the font preview tooltip for many edge cases.
(In reply to Julian Descottes [:jdescottes] from comment #9) > If we think about a value such as: "Monaco, monospace" on windows, hovering > on "Monaco" would then show a preview using times new roman. Hovering on > monospace would show a preview using courier new. In this case it's quite > easy to compare the font used in the content page and see that it's the one > for monospace that was picked. But if the two fonts are similar, wouldn't > this make it harder for the user to understand which font-face is used? Wait, would hovering on "Monaco" not show Monaco? I'm confused, haha. As for the two fonts being similar: we had an issue with the debugger recently where a fontfile wasn't being loaded, but it's fallback was really similar—but they had different x-heights, causing some layout issues in the line numbers column. It was only by typing out the numbers in Sketch and comparing them that we were able to figure out the layout issue was caused by us loading the fallback font, and not the proper font in the stack. Being able to hover and compare in the Rule view would avoid having to do something like that. It might work, it might not. Prototypes are always worth their weight in gold in comparison to comments in Bugzilla :)
(In reply to Helen V. Holmes (:helenvholmes) (:✨) from comment #10) > (In reply to Julian Descottes [:jdescottes] from comment #9) > > Wait, would hovering on "Monaco" not show Monaco? I'm confused, haha. > Not if monaco is not available. On Windows for instance, the browser will default to Times. In the debugger.html issue you mention here, the same would happen. Since the first font was not available, hovering it would also show a default font. But there's definitely value in hovering the first font and seeing it's rendered as Times. If you expected it to be available on this browser/system, you immediately see something's wrong. I'll try it out!
(In case you want to give a try to the first prototype I did earlier: https://treeherder.mozilla.org/#/jobs?repo=try&revision=447455a92f1d)
Attached image Compare the two.png
I think I might have explained myself badly— I was imagining that we would stay true to the font being loaded as you hovered over it (although now that I say it, I can imagine that this might be difficult for technical reasons), and then that the user could use the preview popup to compare two. ("See font loaded.png" attachment, then, "Compare the two.png" attachment.)
Inspector bug triage (filter on CLIMBING SHOES).
Assignee: nobody → jdescottes
Severity: normal → enhancement
Status: NEW → ASSIGNED
Priority: -- → P2
Mass wontfix for bugs affecting firefox 52.
See Also: → 994559
See Also: → 1429761
Going to close this as duplicate of 994559, I think this achieves the main purpose of this bug.
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
(In reply to Julian Descottes [:jdescottes][:julian] from comment #17) > Going to close this as duplicate of 994559, I think this achieves the main > purpose of this bug. Wait, no. The main purpose of this bug was to add the names of the used fonts within the preview tooltip. Though the tooltip contents were not changed by bug 994559. And in regard of comment 5 and bug 1429761, it makes sense to display the name of the hovered font. So, I vote for reopening this bug. Sebastian
Flags: needinfo?(jdescottes)
(In reply to Sebastian Zartner [:sebo] from comment #18) > (In reply to Julian Descottes [:jdescottes][:julian] from comment #17) > > Going to close this as duplicate of 994559, I think this achieves the main > > purpose of this bug. > > Wait, no. The main purpose of this bug was to add the names of the used > fonts within the preview tooltip. Though the tooltip contents were not > changed by bug 994559. And in regard of comment 5 and bug 1429761, it makes > sense to display the name of the hovered font. > > So, I vote for reopening this bug. > > Sebastian This bug was meant to let the user know which font was used, this is done via bug 994559. Bug 994559 introduced a matching logic to find the used font, so adding the name in the tooltip should be easy. I find the existing discussion and patches here confusing, for what should be a good first bug. A new bug would be better.
Flags: needinfo?(jdescottes)
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: