Hi folks

What have I do?
i created a content view with fields and add a normal image field from a normal content type. I set the image formatter to Responsive Image and select a Responsive Image style. After saving, the views shows the image in original size use not the Responsive Image style. But if I go to the Manage display option in the content type area and i select also the Responsive Image in the format settings, the Responsive Image displayed correctly in the default node view. So there the Responsive Image is working properly.

also interesting: if I set the image field in the same views to hidden, and insert a global text field where i put in the image field with {{ field_image }}, the views only shows me the fallback image from the Responsive Image style.


handkerchief created an issue. See original summary.

cilefen’s picture

Version: 8.0.5 » 8.1.x-dev
Component: responsive_image.module » views.module

I am moving this to Views.

xjm’s picture

Thanks @handkerchief for the issue report.

@alexpott, @dawehner, @tim.plunkett, and I discussed this issue and agreed to defer triaging it on a more thorough understanding of the bug. A great next step would be for a contributor to confirm @handkerchief's report and document the exact steps to reproduce it, probably including some screenshots to illustrate the problem. This could be a good novice task.

Once we have steps documented for the scenarios that work and do not work (with screenshots), it could also be helpful to look in the page source to see if this is more a theme layer bug or a Views bug (i.e. are the media queries output but just not working?).

nmillin’s picture

I can confirm.

Steps to recreate:

  1. Enable Responsive Images module and create presets/breakpoints/etc.
  2. Add an Image field and have it display as a Responsive Image.
  3. Create a view to show: fields
  4. Add your image field and have the formatter be Responsive Image
  5. Add a Global: Custom Text
  6. Add your image field using the replacement text (ex: {{ field_slideshow_image }} )

I'll attach screenshots and bug show this to XJM.

PS - Classes added to markup to make it easier to see the bug in the HTML.

nmillin’s picture

Found a way to fix this by adding picture & source to the $adminTags variable on core/lib/Drupal/Component/Utility/Xss.php. Attaching patch and screenshot showing new markup with patch.

xjm’s picture

Title: Responsive Image not working in Views » Responsive Image not working in Views due to XSS filtering
Priority: Major » Normal
Issue tags: -Needs triage for D8 major current state, -D8 major triage deferred, -Needs steps to reproduce, -Needs screenshots, -Novice
Related issues: +#853880: Views: Rewrite field, strips some HTML tags (SOLUTION/WORKAROUND FOUND FOR STYLE TAG)

Nice, thanks @nmillin!

So #5 demonstrates that this is indeed related to XSS filtering. (@nmillin and I discussed that the change/hack above was just to confirm the issue; it's not actually a correct fix to allow these tags across the board because it opens security holes.)

I think this is a situation where the best fix might actually be to work around this and not use Views rewriting to render the field.

xjm’s picture

Title: Responsive Image not working in Views due to XSS filtering » Responsive Image not working in rewritten Views field due to XSS filtering
xjm’s picture

Issue summary: View changes
61.22 KB

Maybe this would be a situation to use the rendered entity plugin for a global field? Make an entity display that is just that field, and then use that area handler on the view. In the center column of the Views admin UI, header, footer, no results behavior etc. Click add and search for "rendered entity":

nmillin’s picture

Hmmmm... That wouldn't help my use case of adding custom markup. I would still need to use TWIG templates to do what I want. Screenshot:
Screenshot of custom markup

Is it worth checking if/what issues picture & source elements would have for XSS? Googling around, I found https://html5sec.org/#142, but that is more for image tags which already have filters in Drupal. I tried some onload XSS attack vectors and they were stripped by Drupal.

xjm’s picture

Well, hypothetically speaking, I would create my custom display mode for my entity type/bundle, and provide a Twig template in my module or theme for the configured entity display that included the desired markup around the field. But I have not actually tried to do this so there may be flaws in this suggestion. :)

xjm’s picture

Title: Responsive Image not working in rewritten Views field due to XSS filtering » Responsive Image not working in rewritten Views field/area due to XSS filtering
xjm’s picture

I should note that the decision we made in D8 to automatically Xss::filterAdmin() various things is not without flaws, and rewritten Views fields might be an example of that. But ideally as much markup as possible ends up in actual Twig template files and thus avoids the unwanted filtering issue.

nmillin’s picture

What security issues does adding picture and source to $adminTags add?

It looks like $adminTags hasn't been updated in 3+ years (https://github.com/drupal/drupal/commits/8.2.x/core/lib/Drupal/Component...). Should $adminTags be reviewed to see if there are other HTML5 elements besides picture and source that should be included or is this list taken from a XSS security website? I'm confused where the list came from and I couldn't find anything searching online. Am I missing something simple here?

Your custom display mode in #10 is sort of what I ended up doing. I show: content and then use 3 twig template files to add some custom divs. Totally possible to do, but overkill for what I was trying to do. Related to that, I read https://www.drupal.org/node/2665694 that you linked to. As a site builder I'm cringing inside. Views won't be as useful to me in the future I guess.

xjm’s picture

(What part of "with feature parity for site builders" continues to worry people?) Anyway. Updating our XSS filtering APIs needs care, but I do agree it's worth posting a separate issue to consider whether there are additional tags that need to be allowed (like picture). Edit: I'd have thought there would be an issue for that already somewhere.

I think we should keep this issue scoped as is to sort out whether Views' XSS filtering here makes sense as it is currently implemented, or if there's a simpler way to accomplish this. Three template files does sound like a lot to display one little element.

xjm’s picture

Issue tags: +Twig

Maybe the theme team can offer some insight here.

nmillin’s picture

I looked for an existing issue, but I couldn't find one. I created https://www.drupal.org/node/2776667 to review the $adminTags variable. Please let me know if there is anything else I can do to advance this. Thanks XJM!

nmillin’s picture

I found https://www.drupal.org/node/732992 which is where the $adminTags array came from (same HTML elements). Adding as a related issue since it is an old issue and was hard for me to find.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

ABaier’s picture

+1, I can confirm this behavior

ABaier’s picture

I think it would be really essential for responsive images to work in views as expected. I am rewriting fields in views for various use cases on a regular base. Sometimes you really have to use the field display instead of content using view modes to have the individual fields for filtering or sorting purposes. Speaking of two core modules, I think they should work together well. I was rather surprised, that this behavior happened, after finishing many many views including the corresponding styles, trying to implement the responsive images as basically last instance. Now I have bit of a problem … Any news on this?

nghai’s picture

I totally agreed with @toni4i. There is certain requirement to use responsive images with views fields rewrite or custom text options. Upto some extend I can try manage the views by showing direct image field display but in case of Entity Reference fields where we want the image to link to the referred entity node in that case there is no solution other than doing something via views results alterations.

There is definite need to have solution for this problem. Is there any update on this ?

nmillin’s picture

I created https://www.drupal.org/node/2776667 to fix the root issue (adding picture and source to $adminTags so they are filtered out), but there hasn't been any movement on that issue.

I'm not sure how to get core contributors to review that issue. #frustrating

Until there is a solution, I'm patching my sites (https://www.drupal.org/node/2776667#comment-11460577). This patch allows for picture and source html elements to be displayed and not stripped out.

nghai’s picture

@nmillin Thanks very much for the quick response!

I have tried applying that patch and that allows the &
tags now in views rewrite options. But now the problem is the media attribute for the tag which is not coming fine (see below)

Current: <source srcset="/sites/default/files/styles/640x320/public/2016-11/15483349-illustration-of-little-boy-Stock-Vector-boy-cartoon-student.jpg?itok=pTok5Eyn 1x" media=" 960px)" type="image/jpeg">

<source srcset="/sites/default/files/styles/themen_highlights_tablet_960x480_/public/2016-11/15483349-illustration-of-little-boy-Stock-Vector-boy-cartoon-student.jpg?itok=HOZeBMCP 1x" media="all and (min-width: 560px) and (max-width: 959px)" type="image/jpeg">

Due to which Responsive image switching is not working. Do you have any idea on this ? Any help would be much appreciated.

ABaier’s picture

I can confirm the problem described in #23 … Picture and Source are now visible, but the media tag unfortunately does not get printed correctly – only the last value and a colon will be included.

    <source srcset="/sites/default/files/styles/crop_4_3_mobile/public/2016-09/Meeting.jpg?itok=9CJWX_Bg 1x" media=" 45em)" type="image/jpeg">
    <source srcset="/sites/default/files/styles/crop_4_3_tablet/public/2016-09/Meeting.jpg?itok=xBmUUm43 1x" media=" 60em)" type="image/jpeg">
    <source srcset="/sites/default/files/styles/crop_4_3_wide/public/2016-09/Meeting.jpg?itok=12S6qH8p 1x" media=" 120em)" type="image/jpeg">
    <source srcset="/sites/default/files/styles/crop_4_3_wide/public/2016-09/Meeting.jpg?itok=12S6qH8p 1x" media=" 120.063em)" type="image/jpeg">
    <img srcset="/sites/default/files/styles/crop_4_3_wide/public/2016-09/Meeting.jpg?itok=12S6qH8p" alt="" typeof="Image">
spuky’s picture

ran into the same issue with "Select multiple image styles and use the sizes attribute." ant a views overwrite were the sizes attribute gets filtert... by XXS filters... and only the part after the last colon gets output...

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

e.ruiter’s picture

I can confirm #23 in 8.3.5. This issue is still not fixed