Several additional non-ascii characters are displayed in preview instead of the Search label on phonak.com
Categories
(Web Compatibility :: Site Reports, defect)
Tracking
(firefox84 affected, firefox85 affected, firefox86 affected, firefox104 affected)
People
(Reporter: asoncutean, Unassigned)
Details
(Keywords: webcompat:site-wait)
Attachments
(1 file)
79.08 KB,
image/png
|
Details |
Affected versions
- 85.0b8
- 86.0a1 (2021-01-13)
Affected platforms
- Windows 7
- macOS 10.15
Unaffected platforms
- Windows 10
- Ubuntu 20.04
Steps to reproduce
- Go to https://www.phonak.com/us/en/hearing-aids/lyric-invisible-hearing-aids/cost-and-subscription.html
- Scroll down to the middle of the page and select some content, including the search button
- Hit Ctrl + P and observe the print preview
Expected result
- Search label is displayed, without any additional characters
Actual result
- Several non-ascii characters are displayed in preview
Regression range
- Not a regression, reproducible way back to Fx 54.0a1; on even older builds the page is only partially visible
Additional notes
- Not reproducible on Chrome (see screenshot)
- Reproducible with the old UI as well
Reporter | ||
Updated•3 years ago
|
Comment 1•3 years ago
|
||
This looks like a site error. The "Search" button is not really a <button>
element, it's actually <a href="/us/en/find-a-Lyric-hearing-care-specialist.html?lyric" class="button round primary" title="Search">Search</a>
which gets styled to look like a button.
The site's CSS then provides a stylesheet (https://www.phonak.com/etc/designs/phonak/clientlibs_base/merged/layout-ltr.w02.4_4_25_2.css.versioned) that includes print-specific rules, including
@media print {
...
a[href]:after {
content:" (" attr(href) ")"
}
...
i.e. after the link, it inserts the destination path as extra text (for print only).
So far, so good: we'd therefore expect the "Search" button to be followed by text (in the print output) showing the destination of the link.
Unfortunately, they also have
.button.primary:after {
font-family:icomoon;
speak:none;
font-style:normal;
font-weight:400;
font-variant:normal;
text-transform:none;
line-height:1
}
which also applies here, and therefore the generated text of the link destination is rendered with the Icomoon icon font (except for characters that aren't present in the icon font, for which we get a fallback font -- hence a few legible letters in the path).
FWIW, this does reproduce for me on Ubuntu and Win10 as well as macOS, and also in Chrome (tried on both Win10 and macOS). It's really not a Firefox bug, it's a poorly-written site.
Moving to Webcompat, in case we want to reach out and suggest they fix things; otherwise, I guess this is simply Invalid.
Comment 2•3 years ago
|
||
Headquartered in Zurich, so their WebDev department is probably in my timezone and language scope. ni? myself for outreach.
Comment 3•3 years ago
|
||
Reached out to them via mail. Will update this thread if I hear back.
Comment 4•2 years ago
|
||
The issue is now reproducible both in Firefox and Chrome, but works in Microsoft Edge.
https://prnt.sc/wri0jqRTw9EA
https://prnt.sc/FFDXlK0tIm__
Tested with:
Browser / Version: Firefox Nightly 104.0a1 (2022-06-28)
Operating System: Windows 10 Pro
Comment 5•2 years ago
•
|
||
Reproducible on macOS devices as well, as observed in comment 4
https://prnt.sc/BFR4Ar863-xv
Tested with:
Browser / Version: Firefox Release 102.0 (64-bit)/ Firefox Nightly 104.0a1 (2022-06-28) (64-bit) / Chrome Version Version 103.0.5060.66 (Official Build) (64-bit) /Microsoft Edge Version 103.0.1264.37 (Official build) (64-bit)
Operating System: Mac OSX Catalina 10.15.7
Notes:
- Reproducible regardless of the status of ETP.
- Reproducible on the latest build of Firefox Nightly and Release.
- Works as expected using Edge
Comment 6•2 years ago
•
|
||
It reproduces for me in all browsers, including MS Edge on Windows and Safari on macOS, as well as Chrome and Firefox. As described in comment 1, this is not a browser bug, it's a site error. The only cases where it wouldn't occur are things like if the browser fails to load the icomoon webfont for some reason, or fails to apply the site's @media print
rules.
Removing the "Blocks" references, as this doesn't really have anything to do with the new Print panel. The same "problem" would have occurred in the old preview, or in actual printed output.
Dennis, I guess you never got any response from the site? If they can't be bothered with it, I'd be inclined to just close this as INVALID.
Comment 7•2 years ago
|
||
(In reply to Jonathan Kew (:jfkthame) from comment #6)
Dennis, I guess you never got any response from the site? If they can't be bothered with it, I'd be inclined to just close this as INVALID.
Sadly, no response. I sent them a ping, but I agree with you, let's close this.
Description
•