This is what Bartik looks like in an iPhone simulator:

Weird white gap on the side of Bartik

Seven doesn't seem to have this problem.

Since this makes Drupal look crappy on a major mobile device out of the box, marking as a major bug.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

webchick’s picture

Issue tags: +VDC

Eeeenteresting. Seems to only happen on the front page?

Tagging VDC, since it may be related.

hmartens’s picture

I've seen this problem before but it was because I changed things in the css and it was spanning over all the way and not being responsive...but out of the box with no changes to the css I haven't seen this problem...yet.

Maybe one of the modules you've added are not playing nicely with responsive?

nod_’s picture

If you're here from twitter: it's drupal 8 core, so that shouldn't happen :)

What happens when you disable the toolbar? it does things with the scrollbar, i'm suspecting that's the issue.

hmartens’s picture

*facepalm* ...sorry :)

webchick’s picture

Well, but here's a screenshot of node 1, not having this problem:

Toolbar + body spans full width of viewport

Same modules enabled, so I'd think if it were toolbar, it'd be consistent everywhere.

I'll try turning things off until it goes away. ATM I suspect contextual links, though, since the frontpage view has overlapping contextual links which have an offset to prevent overlap.

webchick’s picture

Toolbar, Contextual, *and* Edit module turned off. :) Running out of ideas. :)

Persistent little gap...

Pat Redmond’s picture

Interestingly, I get this when I log in on most of the simulators, but not if I'm logged out.

Pat Redmond’s picture

The same issue is appearing in Chrome when you make the screen skinny.
Adding "overflow-x: hidden" to the body fixes this in both the iphone emulator and Chrome. There is probably a better way of doing it though...

echoz’s picture

Status: Active » Needs review
FileSize
844 bytes

I can't test in a simulator but there is a horizontal scrollbar, from an incorrect adjustment to .element-invisible in #1905362: Skip to Main Squished to long one character line. In that patch, instead of getting rid of width: 1px; for .element-invisible, we needed to cancel it out with width: auto; for the .element-focusable ruleset following. Then I fixed the bartik "skip to content" issue in another way.

See if this fixes your issue, because .element-invisible and .element-focusable on the contextual links is suspect.

Edit: actually my (fixed) horizontal scrollbar is from a Read more link, which has .element-invisible on the extra text, and it is only at the right edge of the viewport when logged in.

Pat Redmond’s picture

No change for me when I apply that patch.
Note that you don't need to test in a simulator - if you make the window as narrow as you can, you should see the same thing.
If you don't have a simulator, you can use http://www.testiphone.com/ or http://iphone4simulator.com/ - they will allow you to see localhost too.

echoz’s picture

Status: Needs review » Active

Thanks Pat, I wasn't getting the issue on a web based emulator, and I don't get my local installations on my phone, which has proven to not always be the same as the web tests. @webchick, if this doesn't fix your thing, I'll need to open another issue for it, because it's a real thing, even if a different thing :-)

echoz’s picture

Status: Active » Needs review
dvessel’s picture

I can't reproduce it but for anyone who can who is using the iOS emulator, you can open up Safari and look inside the Debug menu.

It should list the device so you can see the web inspector where you can debug it.

webchick’s picture

echoz's patch totally worked for me! (I'm using the native iPhone simulator in XCode.)

No more white gap!

I don't know enough about CSS to RTBC this myself though. :)

echoz’s picture

For reference, the .element-invisible code is built from http://snook.ca/archives/html_and_css/hiding-content-for-accessibility and is what we use in Zen.

RoloDMonkey’s picture

I don't know if it helps, but I fixed a very similar problem recently. The parent theme had this:

body.front #region-content:after { right: -2.5%; }

For whatever reason, this made the document 2.5% larger than the screen width. I fixed it in the child theme with this:

body.front #region-content:after { right: auto; }

This was very difficult to find because it wasn't something you could inspect in the browser.

Pat Redmond’s picture

Hmm, not sure why it isn't working for me. This is what I get when I look at it in Chrome. Similar thing with http://iphone-emulator.org/
However it is working in IE and FF with that patch, as well as a few of the other online iPhone emulators.

echoz’s picture

Sorry for not specifying, as noted in snooks reference post, the horizontal scrollbar happens in webkit (and I guess Opera) only.

To summarize, .element-invisible on an element near the right edge of the viewport (for example, the span inside Bartik's Read more link) causes horizontal scrollbar in webkit. On an iPhone, you don't see the scrollbar, you see the overflow as if scrolled to the right, showing a space on the right.

echoz’s picture

Issue tags: -VDC +Accessibility
Pat Redmond’s picture

So then we should also include

position: absolute !important;

and

  clip: rect(1px 1px 1px 1px); /* IE6, IE7 */

?

webchick’s picture

Hm. We try to never use ! in these CSS files, and we don't care about IE 6 and 7 in D8.

echoz’s picture

Title: Bartik has weird white gap on side of iOS » .element-invisible on element at right causes horizontal scrollbar on desktop or right gap on phone on webkit browsers
FileSize
5.55 KB

.element-invisible had been adjusted in #1057912: Border with Google Chrome and Safari in .element-invisible in Dec to include width: 1px; but later made incomplete in #1905362: Skip to Main Squished to long one character line in Feb, removing width: 1px; to fix Bartik's "Skip to..." issue.

The #9 patch corrects .element-invisible and .element-focusable css to be complete (fixing the desktop horizontal scrollbar in webkit, and the right gap in mobile webkit browsers) and fixes Bartik's "Skip to..." which refused to read width: auto; of .element-focusable.

.element-invisible and .element-focusable css in it's entirety after patch for clarification:

/**
 * Hide elements visually, but keep them available for screen-readers.
 *
 * Used for information required for screen-reader users to understand and use
 * the site where visual display is undesirable. Information provided in this
 * manner should be kept concise, to avoid unnecessary burden on the user.
 * "!important" is used to prevent unintentional overrides.
 */
.element-invisible {
  position: absolute !important;
  clip: rect(1px, 1px, 1px, 1px);
  overflow: hidden;
  height: 1px;
  width: 1px;
}

/**
 * The .element-focusable class extends the .element-invisible class to allow
 * the element to be focusable when navigated to via the keyboard.
 */
.element-invisible.element-focusable:active,
.element-invisible.element-focusable:focus {
  position: static !important;
  clip: auto;
  overflow: visible;
  height: auto;
  width: auto;
}

Bartik's fixed "Skip to..." after patch
bartik-skip-to.png

webchick’s picture

Hm. Is this the same problem in Seven theme as well?

White gap on right side on Seven theme

(Found on admin/structure/block, which also hides some columns with element-invisible.)

tim.plunkett’s picture

The change to .element-invisible is correct. I can't vouch for the inline-block change, or why Seven looks broken in #23.

echoz’s picture

In #23 you're seeing that the blocks table (scroll down) can't reduce in width as narrow as the viewport, and is pushing out to the right to show the table.

So this is not the same issue, but Seven can show the same issue if there is an element at the right edge with .element-invisible. The issue is not unique to Bartik, it just had the right setup (it's logged in read more link) to show us.

Thanks Tim for recognizing .element-invisible css! Next I will attempt to explain Bartik's strange quirk... sigh.

Edit: adding more to Bartik fix explanation:
I posted in #9 and #22 how #1905362: Skip to Main Squished to long one character line had corrected a Bartik anomaly by removing width: 1px; which was forcing the "Skip to..." link to be 1px narrow plus it's padding, but that css is needed for webkit. I thought the solution must be instead of getting rid of width: 1px; for .element-invisible, we need to cancel it out with width: auto; for the .element-focusable ruleset following, used when tabbing to the link.

Bartik's link would not understand width: auto; while it was display: block; and I wish I could tell you why, but letting it be naturally an inline element (anchor tag) worked, and declaring inline-block allows it to retain the existing padding.

webchick’s picture

Ok, roger that. Opened #1975352: Wide table can push table wider than viewport as a separate issue.

echoz’s picture

oh noes! Seven too!
Seven uses the position: absolute; styling for it's Skip to link as well. Patched to include same fix for Seven.

seven-skipto-before.png

seven-skipto-after.png

echoz’s picture

@webchick, if you think it's cleaner, we can just patch .element-invisible here, and followup with the skip link, but correcting .element-invisible WILL break skip link in Bartik and Seven (Stark is not affected).

webchick’s picture

Nope I'm cool fixing it all here. I just can't RTBC myself, since I wouldn't know my overflows from my inline-blocks. :\

dvessel’s picture

Bartik recently removed the use of that class and recreates the rules so don't forget to apply it there as well.

#1968360: Remove per-region block markup

dvessel’s picture

Bartik's link would not understand width: auto; while it was display: block; and I wish I could tell you why, but letting it be naturally an inline element (anchor tag) worked, and declaring inline-block allows it to retain the existing padding.

This is most likely because of the duplicated rules to hide it. `.element-invisible` isn't being used directly in Bartik. I would remove the inline block property and just fix the duplicate rulesets.

dvessel’s picture

Status: Needs review » Needs work
dvessel’s picture

Re: #31

Never mind that, inline-block is needed. Wasn't paying attention but #30 still applies.

dvessel’s picture

Status: Needs work » Reviewed & tested by the community

Sorry for the noise. meh. After seeing the patch in action, it works as intended.

It would have been nice if the rules to hide were exactly the same but I doubt the changes in #1968360: Remove per-region block markup would cause the same problem.

Requiring inline-block is probably a webkit bug. The parent element is using absolute position with an auto width. It's quite ambiguous as to what auto should mean so Safari and Chrome assume the wrong thing. FF handled it just fine though.

I think this is ready.

echoz’s picture

Status: Reviewed & tested by the community » Needs review

@dvessel, #30 is about Bartik getting .element-invisible removed from block titles in header and footer, so is unrelated. This correction of .element-invisible here is in system.base.css and Bartik uses it in the relevant places (read more + skip link) in this issue.

So in #24 tim.plunkett wrote, "The change to .element-invisible is correct", and in #33 dvessel wrote, "inline-block is needed"...

Do I hear rtbc?

echoz’s picture

Status: Needs review » Reviewed & tested by the community

cross post, thank!

webchick’s picture

Status: Reviewed & tested by the community » Fixed

Awesome, thank you! :D

Committed and pushed to 8.x!

Automatically closed -- issue fixed for 2 weeks with no activity.

AdamPS’s picture

Issue summary: View changes

I am seeing a more subtle version of this on D7. The read more link isn't changing the initial appearance of the page. However it does make the page wider in the sense that you can scroll the whole page R slightly. It's a bit inelegant. The same patch solved it (I took the width 1px part - I'm not using Bartik).

I'm surprised that nobody else has noticed this before so sorry if I'm doing something daft. Is it possible this needs backport to D7? Or maybe it's too late to change D7 now because of the effect on existing sites.

I can put this fix in my own CSS so it's not a problem, but thought I would raise it here in case it was useful to anyone else.

mgifford’s picture

@AdamPS can you open up a new issue on D7 about this and link to it from here. It would be great to have a screenshot. This has been closed for almost 2 years against D8. Might be a new issue, perhaps changes with the iPhone.

What are you using?

AdamPS’s picture

@mgifford Done, see #2664214: .element-invisible on element at right increases page width to make page scrollable on webkit browsers

So far the bug seems to occur on all webkit browsers. However because it's more subtle you only see it with a responsive theme that makes the page width equal to screen width. And only if you actually try to scroll the screen - which shouldn't be possible on such a theme. So perhaps the bug has been around all this time but no one has really noticed.