Show U+ notation for characters that can't be rendered by the Inspector font
Categories
(DevTools :: Inspector, enhancement, P3)
Tracking
(Not tracked)
People
(Reporter: v+mozbug, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(4 files)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:70.0) Gecko/20100101 Firefox/70.0
Steps to reproduce:
Looked at text inside an element using DevTools Inspector
Actual results:
Some text was shown as square boxes (missing character). Square boxes are pretty useless.
Expected results:
Best: The font used in the browser to display the element should also be used in the Inspector, so that the text is readable.
OK alternate, font substitution among fonts on the page should be used so that the text is readable.
Gross alternate, missing characters should be converted to U+ notation and underlined, so text is decipherable, and the underlining would indicate the substitution.
Not quite as gross alternate, leave the square boxes, but hovering over one of them should give the U+ charcode.
Comment 1•5 years ago
|
||
Bugbug thinks this bug should belong to this component, but please revert this change in case of error.
Comment 2•5 years ago
|
||
Thank you Glenn for filing this. It would be very helpful if you could provide a test case for this problem (a simple HTML page maybe, or the address of a site where the problem exists).
Reporter | ||
Comment 3•5 years ago
|
||
Reporter | ||
Comment 4•5 years ago
|
||
Here's a test file, using the (SIL OFL open source licensed) Andika font... which is also attached. I couldn't get the test to work referencing bugzilla as a source for the font, but if you install it locally that works... well, it works to demonstrate that the variant "Z with a hook" character in Andika is not displayed in Inspector, except as a box. I've been assuming that that is because Inspector only displays characters from whatever font it is using by default, not doing font substitutions among fonts on the page being debugged to show the character. Nor any other way of showing what character it is, as outlined in the original bug report above.
Comment 5•5 years ago
|
||
Thank you Glenn.
Using the font from the page to render the text inside the inspector panel isn't really doable. First of all, loading that font in the inspector iframe would not be technically feasible for security reasons (and paid-for fonts also have mechanisms that prevent this).
The only thing we could do is render that text into an image, in the same process as the one the page runs in (using canvas APIs), and displaying that in the inspector. But not only would that be terribly slow, we can't really start rendering all content text in the inspector with whatever fonts they use in the page. We would end up, in some cases, with a very hard to read DOM tree.
I understand the problem though, showing a blank square isn't great. So I think showing the U+ notation is probably be the best thing we can do here.
Note that on my computer, with Firefox I see a square with F234 written inside it. However if I open the page on Chrome, I see an empty white square.
Reporter | ||
Comment 6•5 years ago
|
||
Not sure what kind of computer you have or what version of firefox, but in 71 Branch on my Windows 10-64-bit computer, this blank box is what I see in in FF inspector. If an F234 were crammed in that box it would be somewhat helpful, although I'm not sure it would be readable without enlarging the font somehow.
I've no idea how a font that is legal to display in FF would not be legal to display in FF-DevTools, but DRM is a pain in the neck.
I agree rendering as canvas would be slow and annoying.
But a readable U+ code, while not as friendly, would at least allow reasonable debugging.
Another idea that occurs to me is the ability to simply use a different font in Inspector, that might have coverage of the characters in use. Would that help? If it isn't a protected font, one could even potentially load the same font in Inspector? Often fonts using PUA areas don't have full coverage of other characters, though, so it would seem necessary to support multiple fonts in Inspector for such purposes: a basic font, and then one or more fonts to cover characters not found in the basic font.
You mention seeing a box containing the code... if there were a font that had such capability, with a bigger box, and don't forget about larger that 4 digit codes, that might be used. But maybe Inspector is limited to fixed-width fonts? Can they even be changed?
I suppose one could use a magnifier tool to enlarge the tiny box to read the code, but there are a limited number of pixels in the empty square box I see to hold readable-even-if-magnified 5 digits codepoint values.
Comment 7•5 years ago
|
||
(In reply to Glenn Linderman from comment #6)
Not sure what kind of computer you have or what version of firefox, but in 71 Branch on my Windows 10-64-bit computer, this blank box is what I see in in FF inspector. If an F234 were crammed in that box it would be somewhat helpful, although I'm not sure it would be readable without enlarging the font somehow.
I have a mac and was testing on Firefox 71 and 72. This is what I'm seeing.
So I guess the font used on mac has special boxes with unicodes inside of them as glyphs, which is kind of nice. But that's really small and I bet that not all characters are covered.
I've no idea how a font that is legal to display in FF would not be legal to display in FF-DevTools, but DRM is a pain in the neck.
Yeah I think you're probably right, if FF downloaded the font, then DevTools could probably use it. But since DevTools did not purchase the font like the site did, I'm just guessing that using it to render content in the inspector would not be legal.
But a readable U+ code, while not as friendly, would at least allow reasonable debugging.
Sounds good.
Another idea that occurs to me is the ability to simply use a different font in Inspector, that might have coverage of the characters in use. Would that help? If it isn't a protected font, one could even potentially load the same font in Inspector? Often fonts using PUA areas don't have full coverage of other characters, though, so it would seem necessary to support multiple fonts in Inspector for such purposes: a basic font, and then one or more fonts to cover characters not found in the basic font.
That's interesting. Using a fallback font with more coverage would definitely work. And we could make sure that font is somewhat consistent with the base font too.
I came across this interesting GNU Unicode Font project that might provide some inspiration: http://czyborra.com/unifont/
You mention seeing a box containing the code... if there were a font that had such capability, with a bigger box, and don't forget about larger that 4 digit codes, that might be used. But maybe Inspector is limited to fixed-width fonts? Can they even be changed?
Yes that can be changed. The monospace nature of the font comes from the fact that that's the type of fonts that people use in coding editors, so we wanted to be consistent with this. But using a non monospace font for certain rare cases where we fallback to another font is feasible.
Reporter | ||
Comment 8•5 years ago
|
||
(in reply to Patrick from comment #7) (I have no idea how to use Markdown to get the effect of email replies in this medium, sorry)
Patrick: I have a mac and was testing on Firefox 71 and 72. This is what I'm seeing.
So I guess the font used on mac has special boxes with unicodes inside of them as glyphs, which is kind of nice. But that's really small and I bet that not all characters are covered.
Glenn: I see that sort of number-filled box in emacs, even on Windows. Not sure if it is a font-fallback feature, maybe, for a notfound glyph. In some fonts, clearly not all.
Patrick: But since DevTools did not purchase the font like the site did, I'm just guessing that using it to render content in the inspector would not be legal.
Glenn: It's just another way of viewing the site... :)
Patrick: I came across this interesting GNU Unicode Font project that might provide some inspiration: http://czyborra.com/unifont/
You mention seeing a box containing the code... if there were a font that had such capability, with a bigger box, and don't forget about larger that 4 digit codes, that might be used. But maybe Inspector is limited to fixed-width fonts? Can they even be changed?
Yes that can be changed. The monospace nature of the font comes from the fact that that's the type of fonts that people use in coding editors, so we wanted to be consistent with this. But using a non monospace font for certain rare cases where we fallback to another font is feasible.
Glenn: Interestest project, interesting that a 1990s project had updates as recently as 2014 (from file dates).
As a default non-monospace font for fallback, maybe an auotmatically-generated font containing the codepoint in a variable width box with outline could be used... In fact, it wouldn't need to be a font at all, but just an inline box with a border, and the codepoint within. Such could be used as a "final fallback" if none of the configured fonts (nor fonts on the page, if it is decided they could be used) contained the character.
I agree that in general, the use of a monospace font is appropriate in Inspector. And some characters in fonts can be quite tall and wide... Emacs does a reasonable job of dealing with that when non-monospaced fonts are loaded into mostly monospaced text: it is a bit disruptive to the text flow, but not as disruptive as stopping and looking up codepoint values!
Updated•2 years ago
|
Description
•