Closed Bug 1275069 Opened 5 years ago Closed 3 years ago

Neil deGrasse Tyson is blurry: BuzzFeed blurred preview photos are not shown and then not unblurred


(Web Compatibility :: Desktop, defect)

Not set


(firefox46 unaffected, firefox47 unaffected, firefox48 unaffected, firefox49 fix-optional)

Tracking Status
firefox46 --- unaffected
firefox47 --- unaffected
firefox48 --- unaffected
firefox49 --- fix-optional


(Reporter: cpeterson, Assigned: adamopenweb)




(Keywords: regression, Whiteboard: [sitewait])

@ Daniel: is this a website bug or a browser bug?

This is a regression from bug 1236506. I can repro this bug in Nightly 49 and Aurora 48, but not Beta 47 or earlier. I had a hard time bisecting this regression because Nightly 47 and 48 were affected, even though Beta 47 and Aurora 48 are not.

1. Load
2. Scroll down to photo #1 (Neil deGrasse Tyson) and click the "Click to reveal" button.


* PROBLEM #1: Before you click the "Click to reveal" button, there is a blurred preview photo behind the button in Chrome, Safari, IE11, and Edge but not in Firefox.

* PROBLEM #2: After you click the button, the blurred photo is replaced with a clear photo in Chrome, Safari, IE11, and Edge. In Firefox, the "Click to reveal" button is replaced with a blurred photo.
Flags: needinfo?(dholbert)
There's some UA sniffing involved here. See this.set_box_blur @

If we disabled the filter style on the img element, I can see the expected blurry photo.

<img style="filter: url(&quot;;);" src="" rel:bf_image_src="" class="bf_dom graphic_image box_blur" rel:bf_bucket="progload" alt="Neil deGrasse Tyson lounging sensuously OR a fish with a hook in its mouth?" height="596" width="625">

Still digging in...
(Before digging in too deeply, if I spoof as Chrome this site gets EXPECTED results with layout.css.prefixes.webkit=true.)
OK, so Problem 1:

In set_box_blur linked from Comment #1, 

} else if (_) {
  t.setAttribute("style", "filter:url(" + c + ");")

_ here means Gecko. c ends up as, which is cross-origin. CORS failure?
Simple test showing that they need to serve CORS headers with their filter: (or they can just remove the Gecko sniff and codepath).
For Problem 2, in the b click handler of set_box_blur from Comment #1:

If you're Chrome, the `graphic_image` class gets removed (which contains the -webkit-filter style). If you're Firefox, instead the blur.svg inline style gets removed (which was being blocked due to SOP violation) -- and now the browser can render the `graphic_image` style. Now that we support the -webkit-filter alias, the image is blurred instead of clear.

So, this is partially a regression and partially Tech Evangelism. I think the best thing to do here is try for us to get them to remove the extra _/Gecko codepath and everything should just work.™

(You'll notice if you set layout.css.prefixes.webkit to false, there is no blurry image at all. It's still broken but it's less obvious how because you just see the "Click to reveal" text:

IMO, I think we should move this to Tech Evangelism, but let's let dholbert give his opinion first.
To fix this site, Buzzfeed can do the following:

In, add an unprefixed `filter: blur(30px)` to the end of the .graphic_image style:

.sub_buzz_content .graphic_image {
  top: -67px; position: relative; 
  -webkit-transform: translate3d(0, 0, 0); 
  -webkit-filter: blur(30px); 
  -moz-filter: blur(30px); 
  -o-filter: blur(30px); 
  -ms-filter: blur(30px);
  filter: blur(30px);

(they could remove a bunch of those prefixes, but that's less important)

And in the this.set_box_blur method of,

They can change u = Prototype.Browser.WebKit && !isSafari5() || isIE9() -> u = Prototype.Browser.WebKit && !isSafari5() || isIE9() || Prototype.Browser.Gecko and then they can remove the Gecko-specific codepaths (_ = Prototype.Browser.Gecko && !isIE11(), etc.)
Thanks Chris for filing, & thanks Mike for the analysis! I agree with the decision in comment 5 -- let's move this to Tech Evang and see if we can get Buzzfeed to fix this up.
Component: CSS Parsing and Computation → Desktop
Flags: needinfo?(dholbert)
Product: Core → Tech Evangelism
Version: unspecified → Trunk
Assignee: nobody → astevenson
Whiteboard: [contactready]
Reaching out to the author of the article by email:
Whiteboard: [contactready] → [sitewait]
Received a response "I will flag it to our Post Experience team. Thanks for the heads up!"
At some point I think the site was being updated but currently it is still broken in Nightly and Dev edition.
ni? myself to try to find some alternate contacts here. might be a better route than the article author.

(also changing 48 to unaffected since the change in question won't hit 48 release bc webkit stuff is tied to EARLY_BETA_OR_EARLIER in 48)
Flags: needinfo?(miket)
Moving ni? to Adam, just spoke with him and he's going to reach out again.
Flags: needinfo?(miket) → needinfo?(astevenson)
No response from my last follow up. Might be worth seeing if we can find a developer over there.
Flags: needinfo?(astevenson)
Marking this as fix-optional to get this of our regression triage list, since this is tech evang.
Still an issue, sadly. Also, found this better URL for testing:
There's three public emails assosciated with the buzzfeed org on github:, might be good to email them.
Thanks Mike! Reaching out to Gerard Orozco by email.
This has been fixed it seems.
Closed: 3 years ago
Resolution: --- → FIXED
Product: Tech Evangelism → Web Compatibility
You need to log in before you can comment on or make changes to this bug.