Closed Bug 1686739 Opened 3 years ago Closed 2 years ago

Several additional non-ascii characters are displayed in preview instead of the Search label on phonak.com

Categories

(Web Compatibility :: Site Reports, defect)

defect

Tracking

(firefox84 affected, firefox85 affected, firefox86 affected, firefox104 affected)

RESOLVED INVALID
Tracking Status
firefox84 --- affected
firefox85 --- affected
firefox86 --- affected
firefox104 --- affected

People

(Reporter: asoncutean, Unassigned)

Details

(Keywords: webcompat:site-wait)

Attachments

(1 file)

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

  1. Go to https://www.phonak.com/us/en/hearing-aids/lyric-invisible-hearing-aids/cost-and-subscription.html
  2. Scroll down to the middle of the page and select some content, including the search button
  3. 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
Has STR: --- → yes

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.

Component: Print Preview → Desktop
Product: Core → Web Compatibility

Headquartered in Zurich, so their WebDev department is probably in my timezone and language scope. ni? myself for outreach.

Flags: needinfo?(dschubert)

Reached out to them via mail. Will update this thread if I hear back.

Flags: needinfo?(dschubert)

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

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:

  1. Reproducible regardless of the status of ETP.
  2. Reproducible on the latest build of Firefox Nightly and Release.
  3. Works as expected using Edge

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.

No longer blocks: 133787, 1658287
Flags: needinfo?(dschubert)
Whiteboard: [print2021_v86] [old-ui+]

(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.

Status: NEW → RESOLVED
Closed: 2 years ago
Flags: needinfo?(dschubert)
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: