Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
This is what Bartik looks like in an iPhone simulator:
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.
Comment | File | Size | Author |
---|---|---|---|
#27 | element-invisible-1973456-27.patch | 1.17 KB | echoz |
#27 | seven-skipto-before.png | 5.6 KB | echoz |
#27 | seven-skipto-after.png | 5.5 KB | echoz |
#23 | Screen Shot 2013-04-19 at 9.42.24 PM.png | 42.57 KB | webchick |
#22 | bartik-skip-to.png | 5.55 KB | echoz |
Comments
Comment #1
webchickEeeenteresting. Seems to only happen on the front page?
Tagging VDC, since it may be related.
Comment #2
hmartens CreditAttribution: hmartens commentedI'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?
Comment #3
nod_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.
Comment #4
hmartens CreditAttribution: hmartens commented*facepalm* ...sorry :)
Comment #5
webchickWell, but here's a screenshot of node 1, not having this problem:
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.
Comment #6
webchickToolbar, Contextual, *and* Edit module turned off. :) Running out of ideas. :)
Comment #7
Pat Redmond CreditAttribution: Pat Redmond commentedInterestingly, I get this when I log in on most of the simulators, but not if I'm logged out.
Comment #8
Pat Redmond CreditAttribution: Pat Redmond commentedThe 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...
Comment #9
echoz CreditAttribution: echoz commentedI 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.
Comment #10
Pat Redmond CreditAttribution: Pat Redmond commentedNo 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.
Comment #11
echoz CreditAttribution: echoz commentedThanks 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 :-)
Comment #12
echoz CreditAttribution: echoz commentedComment #13
dvessel CreditAttribution: dvessel commentedI 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.
Comment #14
webchickechoz's patch totally worked for me! (I'm using the native iPhone simulator in XCode.)
I don't know enough about CSS to RTBC this myself though. :)
Comment #15
echoz CreditAttribution: echoz commentedFor 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.
Comment #16
RoloDMonkey CreditAttribution: RoloDMonkey commentedI don't know if it helps, but I fixed a very similar problem recently. The parent theme had this:
For whatever reason, this made the document 2.5% larger than the screen width. I fixed it in the child theme with this:
This was very difficult to find because it wasn't something you could inspect in the browser.
Comment #17
Pat Redmond CreditAttribution: Pat Redmond commentedHmm, 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.
Comment #18
echoz CreditAttribution: echoz commentedSorry 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.
Comment #19
echoz CreditAttribution: echoz commentedComment #20
Pat Redmond CreditAttribution: Pat Redmond commentedSo then we should also include
and
?
Comment #21
webchickHm. We try to never use ! in these CSS files, and we don't care about IE 6 and 7 in D8.
Comment #22
echoz CreditAttribution: echoz commented.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:
Bartik's fixed "Skip to..." after patch
Comment #23
webchickHm. Is this the same problem in Seven theme as well?
(Found on admin/structure/block, which also hides some columns with element-invisible.)
Comment #24
tim.plunkettThe change to .element-invisible is correct. I can't vouch for the inline-block change, or why Seven looks broken in #23.
Comment #25
echoz CreditAttribution: echoz commentedIn #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.
Comment #26
webchickOk, roger that. Opened #1975352: Wide table can push table wider than viewport as a separate issue.
Comment #27
echoz CreditAttribution: echoz commentedoh noes! Seven too!
Seven uses the position: absolute; styling for it's Skip to link as well. Patched to include same fix for Seven.
Comment #28
echoz CreditAttribution: echoz commented@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).
Comment #29
webchickNope I'm cool fixing it all here. I just can't RTBC myself, since I wouldn't know my overflows from my inline-blocks. :\
Comment #30
dvessel CreditAttribution: dvessel commentedBartik 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
Comment #31
dvessel CreditAttribution: dvessel commentedThis 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.
Comment #32
dvessel CreditAttribution: dvessel commentedComment #33
dvessel CreditAttribution: dvessel commentedRe: #31
Never mind that, inline-block is needed. Wasn't paying attention but #30 still applies.
Comment #34
dvessel CreditAttribution: dvessel commentedSorry 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.
Comment #35
echoz CreditAttribution: echoz commented@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?
Comment #36
echoz CreditAttribution: echoz commentedcross post, thank!
Comment #37
webchickAwesome, thank you! :D
Committed and pushed to 8.x!
Comment #39
AdamPS CreditAttribution: AdamPS commentedI 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.
Comment #40
mgifford@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?
Comment #41
AdamPS CreditAttribution: AdamPS commented@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.