Selected text on washingtonpost.com shows up as double

NEW
Unassigned

Status

()

P3
normal
a year ago
a year ago

People

(Reporter: Ehsan, Unassigned)

Tracking

unspecified
Points:
---

Firefox Tracking Flags

(firefox55- fix-optional, firefox56 affected)

Details

Attachments

(4 attachments, 1 obsolete attachment)

What does "shows up as double" mean? I don't see a problem with the screenshot.
(In reply to Timothy Nikkel (:tnikkel) from comment #1)
> What does "shows up as double" mean? I don't see a problem with the
> screenshot.

You may need to zoom in closely, it looks like a second copy of the text is overlaid on top but nudged up by a few pixels inside the selection.

Comment 3

a year ago
Probably, selected text looks like bold.
And seems duptication of Bug 857924.
I'm guessing that's because the text has the rule text-shadow: 0 1px 0 #FFF;

When I select the test I get black text with a white textshadow. But the screenshot has white text (with a white text shadow).
https://www.washingtonpost.com/pb/gr/p/default/r0oLDgVmaWOdlq/style.css?_=9d250

.pb-f-article-article-body .article-body {
	color: #111;
	text-shadow: 0 1px 0 #FFF;
}

Chrome has the same problem (it looks even worse there to me).

In both Nightly and Chrome the selection has blue background with white text
when the browser window is focused (on Linux).
Maybe Ehsan's screenshot was taken with the window not having focus?

Anyway, looks like a site issue to me.
I investigated this issue a bit and here are my results:
- on latest Nightly, I tried to find other websites that have this problem, but I couldn't find any (tested on CNN, Wikipedia, Britannica, Ebay, Youtube etc). Only the Washington Post website seems to be affected.
- I also tested this using an older Nightly build 20.0a1 (2013-01-04) and the results were the same as above: only the Washington Post website was affected.

Also, please note that the issue is visible with both focused and unfocused Firefox.
(Reporter)

Comment 7

a year ago
Created attachment 8875050 [details]
Chrome Screenshot

Thanks for the investigations everyone!

The reason why I filed this was that I was not seeing the same issue in Chrome.  I checked again and the text looks nice and crisp in Chrome for me!  And they are served the same style...
(Reporter)

Comment 8

a year ago
Created attachment 8875051 [details]
Firefox Screenshot

Here is a better screenshot from Firefox with the Window being active, for comparison.
Attachment #8873555 - Attachment is obsolete: true
From comment 6 it sounds like this isn't a regression?  Setting fix-optional for 55, though if a fix comes in we can still uplift to beta.
status-firefox55: affected → fix-optional
status-firefox56: --- → affected
tracking-firefox55: ? → -
> From comment 6 it sounds like this isn't a regression?

Right, I don't think it's a regression in Firefox.  It's probably a regression
in the stylesheet on the site.  IOW, a recent change *they* did.

> The reason why I filed this was that I was not seeing the same issue in Chrome.

OK, I guess it varies per platform.  I definitely see the same problem in Chrome
on Linux.

I still think this is an Evangelism issue more than anything else.
We're rendering what the site asked for.
Created attachment 8875959 [details]
washingtonpost.jpg

This is the comparison in between the 3 browsers on macosx. 
I would even say that it's not really a matter of evangelism, but just (bad?) design choice. 

What Ehsan might be refering too is when you select the text and unfocus the window. I'll put another screenshot for this.
Created attachment 8875961 [details]
firefox, safari, opera

From left to right: firefox, safari, opera
unfocused windows.

I still maintain that **for me** it's something to close.
You can still send an email to the washingtonpost.
Keywords: regression, regressionwindow-wanted
(Reporter)

Comment 13

a year ago
Sorry I keep responding to this bug with a super long delay because I currently have a multi-month long backlog of bugs I haven't had a chance to look at yet...  :-(

I think this issue is definitely platform dependent in one aspect.  If you pay attention to the screenshots I posted vs the ones Karl posted from OSX you will see that on Linux we use white color to paint the selected text whereas on OSX we use black to paint text.  It is not very surprising that their white text shadow looks very nice when we paint the main text in black.

But if you note the difference in the rendering between my screenshots from Chrome and Firefox on Linux (both from a selected window BTW, this bug isn't about when a window is deactivated) there is a very visible difference in how Gecko and Blink are handling painting some white text with white text shadow.  Gecko seems to create a non-blurred shadow of the text, creating this "ghost" effect which results in the text turning out pretty unreadable, but Blink seems to use some kind of blurring if my eyes see this correctly which it applies to the text shadow which creates a much nicer effect which leads to text that remains legible, even with washingtonpost's questionable design aesthetics here...
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.