Step to reproduce:
1. Go to /admin/structure/views
2. See on the DISPLAYS column.

Proposed resolution

It seems this is due to this rule

ul {
    margin: 0.25em 0 0.25em 1.5em;

If you change to

ul {
    margin: 0.24em 0 0.24em 1.5em;

That all works elegantly on all the width screens I've seen. Although I do not know why.

Remaining tasks

User interface changes

API changes

Data model changes

Members fund testing for the Drupal project. Drupal Association Learn more


vaplas created an issue. See original summary.

mohit1604’s picture

Assigned: Unassigned » mohit1604
mohit1604’s picture

Assigned: mohit1604 » Unassigned
Status: Active » Needs review
440 bytes

@vaplas, Thanks for the issue. Uploading required patch, please review it :)

vaplas’s picture

Status: Needs review » Reviewed & tested by the community

@Mohit Malik, thanks for super quick help with it! After the #3 patch, it seems like everything look good. So, RTBC.

I also tried to find some regression after patch, because this css rule is too broad and affects all ul in seven theme. But did not find it. Although this does not mean that the regression did not occur :)

Perhaps more experienced developers will be asked about more specific rule, like td.views-ui-view-displays ul to ensure that nothing degrades, maybe not.

Also I want to pay attention that in other cases, we using wrapper 'item-list' (with margin:0). Example:

  • /admin/config/content/formats (ROLES column)
  • /admin/people (ROLES column)

But it is not appropriate here, because it violates the design.

alexpott’s picture

Status: Reviewed & tested by the community » Needs work

Given that we already have CSS targeting this td directly i.e. .views-ui-view-displays ul in views_ui.admin.theme.css we should do that in Seven's CSS rather than making a more risky change. We can just do:

.views-ui-view-displays ul {
  margin: 0;

Not entirely sure of where best to add this - I'll ping a frontend maintainer.

joelpittet’s picture

Status: Needs work » Postponed (maintainer needs more info)

I tried this in the latest Firefox and Chrome and can't reproduce the bug.

The only way I could see something like that was Chrome and I had the zoom up at 110%, can you confirm your zoom is at 100%? Firefox zoom didn't break this line.

vaplas’s picture

Without problem:
FireFox (58.0.1)
Chromium (49.0.2623.110)
Edge (38.14393.0.0)
Safari (5.1.7)

With problem (it seems they have one WebKit engine):
Chrome (64.0.3282.167)
Yandex.Browser (
Opera (51.0.2830.26)
In these browsers I have a persistent problem with "1 pixel shift" with zoom 100%. If I start to change the zoom, it disappears (but after the page refreshes it appears again).

It looks like a bug of the browser (or WebKit engine series).

In problem browsers:

  • height DISPLAY column: 67.5 px.
  • height other column: 68 px.

In correct browsers:

  • height all columns: 67.5 px.
joelpittet’s picture

Status: Postponed (maintainer needs more info) » Closed (works as designed)

Much of this comes down to how the drop-buttons are made with the position absolute and min-height combo.

It may be worth redoing the markup and CSS for the dropbuttons in general but this fix just masks a browser issue.

Let me know if you'd be interested in reworking the dropbuttons and we can create a more focused issue for that.