Font URL tooltip is massive for base64 URLs
Categories
(DevTools :: Inspector, defect, P3)
Tracking
(firefox71 fixed)
| Tracking | Status | |
|---|---|---|
| firefox71 | --- | fixed |
People
(Reporter: fvsch, Assigned: fvsch)
References
Details
Attachments
(3 files)
inspector-fonts-base64-tooltip.png
We put the full URL in the title attribute for .font-origin .url. If the URL happens to be very long, e.g. with a base64 value, this can produce problematic results. See the attached screenshot.
We should probably cut the string off at something like 500 or 1000 characters.
A test case: https://codepen.io/mutoo/pen/MvZzjX
|
Assignee | |
Comment 1•5 years ago
|
||
|
|
Assignee | |
Comment 2•5 years ago
|
||
I tried clipping at 1000 characters but it still felt a bit long, so I used 600 in my patch.
I'm wondering if we should use the same clipped string for the text content as well, not just for the title.
One advantage of using the full URL in the text content is that if you double-click the text to select it and hit Cmd+C, Firefox actually copies the full URL; but that's probably a somewhat niche use case.
|
||
Updated•5 years ago
|
|
|
||
Updated•5 years ago
|
|
|
Assignee | |
Comment 3•5 years ago
|
||
Changed the max length to 512 for geeky reasons, and also because that's what Internet Explorer uses according to the good people of stack overflow (and in my tests it felt like a decent length). Chrome seems to use 1024, and Firefox seems to clip at 3000+.
|
|
Assignee | |
Comment 5•5 years ago
|
||
Copying some interesting UX discussion from Phabricator:
rcaliman: Given that data URIs are meaningless as title attributes, what do you think of a conditional to check and use a plain string to label it? The 600 character limit is arbitrary and doesn't really solve the aesthetic problem of the exaggerated tooltip.
fvsch: I'm not sure about the UX of showing "Data URL" as a tooltip. We're already showing the start of the data URL as the span's textContent, so the information that it's a data URL is maybe clear already?
fvsch: If we decide to not have a title for data URLs, or have a title that says "Data URL" only, I worry that it could train users to think that they can't get the full information via the tooltip, and would end up ignoring it in the future (even for non-data URLs).
rcaliman: A base64 string as the title doesn't provide any meaningful information to a human other than the fact that it is a Data URL. That's why I suggested to simplify it by making it explicit (perhaps also helping users unaware of this so they know what term to Google for if confused).
rcaliman: The suggestion to replace the data URL title with a fixed string was meant to solve the problem at hand: the exaggerated size of the tooltip. The arbitrary 600 char limit doesn't really mitigate it.
I still went with clipping at an arbitrary limit because:
- I find the idea of just showing "Data URL" or some other short information (probably localized?) interesting but I'm not fully convinced it would work out well.
- In my tests the 512 or 600 limit does mitigate the extreme macOS situation in attachment 9089622 [details].
So I'm going with the clipping fix for now.
|
||
Comment 6•5 years ago
|
||
| bugherder | ||
|
||
Comment 7•5 years ago
|
||
Hi guys, tried reproducing and verifying this issue, the patch seems to do it's job, but in both cases (reproduced and fixed) the tooltip will be offset (see the attachment). Any idea? This happened on Windows 10.
|
|
Assignee | |
Comment 8•5 years ago
•
|
||
Seems like an unrelated issue. The patch in this bug trims the text content tooltip but does not control the tooltip position or rendering, since it's using a HTML title attribute.
Might be worth reporting as a new bug in the Inspector component, and see if this is related to how DevTools manages its frames (I know we changed that recently and it had a handful of side effects) or if it's a more general Gecko/Windows integration issue.
Note: can't reproduce on macOS, so it might be Windows-specific.
|
||
Updated•4 years ago
|
Description
•