In ios 10, in all browser (safari, chrome, firefox) I noticed that when a <select> tag is active, the rest of the page is fixed.
This conflict with elements having css property position:fixed or position:stickywhile they are fixed, resulting a progressive disapearing related to the scrolling position of the page.
This appear only for <select> tag that have a native rendering. I could not reproduce the issue with <select> having custom rendering due to some plugin.
Did you see this issue ? Maybe in other case ?
Is there any css property available to avoid this ?
EDIT : webkit bugzilla
Related
I'm having an issue with getting Googlebot to correctly render my webpage(s).
It's rendering the header and one "row" of my page (just the page's top background picture), and then failing to render anything beyond that, not even the footer, missing about 3/4 of the page.
My site is www.runparis.fr and screenshots of the rendered fetch are attached.
Other potentially relevant information includes:
The code that was fetched is missing nothing
The fetch status is complete (no missing resources)
The problem is site-wide; it happens on all my pages
When I check the cache the whole page is rendered perfectly
Fetch as Google (mobile) renders the site perfectly
The site looks fine in any of my browsers
There's nothing funky going on in my page; It's just background images and text. Easy stuff.
My questions are:
Will google's inability to render the page have an impact on how Google ranks it?
Is there any advice for solving the problem and having google render the page correctly?
Thanks for any help or advice anyone can offer!
Googlebot render 2
Edit:
I've done another Fetch as Google and render for a test page and found that Googlebot will stop rendering after it has rendered any background images that I've set to "full height" in my page builder in my Wordpress installation; that is, any image that is set to take up the full height of the browser window kills the render.
So, it will render everything until it hits this image, renders that, and then stops.
As stated before, my page isn't fancy; It's just simple background images and text. It surprises me that Googlebot has trouble rendering what any browser can render perfectly, especially given the simplicity of the pages!!
So, my questions are:
Will Google not being able to render my page impact the way Google ranks my site? (given that what's in the cache renders fine on my browser)
And, Is this a common problem? Are there any fixes that will let Google render my pages correctly?
Some new information supplied by an external source:
"validator.w3.org/nu/?doc=http%3A%2F%2Frunparis.fr%2F"
"jigsaw.w3.org/css-validator/validator?uri=http%3A%2F%2Frunparis.fr%2F&profile=css3&usermedium=all&warning=1&vextwarning=&lang=en"
The various errors and warnings might explain why rendering is hampered in some tools such as Google Fetch and render.
Browsers are much more forgiving than all these validation and rendering tools.
I'm guessing that in Google's rendering tool the css rules that set the background image(s) and foreground image(s) and text content are being applied in the wrong order so background stuff ends up on top of foreground.
Does this new information help anyone understand why Googlebot would be having trouble to render the page?
I have experienced the same problem, the only viewable thing on the renderer was the hero section, and it was caused with defining height:100vh; for the hero section.This problem occur when using vh css units, or in some cases height:100%;
Here is the thread and discussion that really helped me out to understand the issue:
I believe that the google bot is doing this:
1. Looking at your website with a 1024x768 viewport.
2. Checks how tall the window.scrollHeight is
3. Resizes it's virtual browser to be the same height as the window.scrollHeight
4. Takes a screenshot and
5. Checks to see what elements are visible, and tallies SE score as appropriate. (Dinging content that is not visible.)
I partially solved this issue with inserting extra rules into mediaqueries: So for resolutions around 1024px width, I put max-height:800px; (rule height:100vh; stayed active) on my hero section, and on mediaquery for rules around 1280px width and up, I set max-height:none; (rule height:100vh; is active).
I'm still loosing around 30px of height in the renderer, but that's being cut off at the end of the page, with no text and any meaningfull content.
I have the similar issue with (Google Mobile-Friendly) tool and (Fetch as Google) mobile version is broken because Googlebot is not loading my style.css and affect my rankings
so I output my stlye.css code for mobile manually
add_action('wp_head','load_mobile_styles');
function load_mobile_styles () {
if( wp_is_mobile() )
{
ob_start(); ?>
<style>
enter code here
</style>
<style>
enter code here
</style>
<?php
echo ob_ob_get_clean();
}
}
I also have this issue. I am using Ubuntu and just completed the Hello world tutorial. I wrote some more text and I am unable to scroll. I can see where the words keep going but nothing I have tried lets it scroll. I have not made any HTML/CSS edits. I have only added more text to the <p> tag.
There is some default CSS applied for chrome packaged apps. Putting the following in your CSS should re-enable scrolling:
html {
overflow-y:scroll;
}
Someone is putting together a cool guide which might have some more tips. See https://gist.github.com/maicki/7622137#scrolling
Chrome apps have a default stylesheet applied to them, to help the web "page" be more of an "app" by default.
For Chrome Apps on Mobile, we also include this (well, a nearly identical) default stylesheet.
So that is the reason for that behavior. Scrolling is absolutely useful in very many contexts, and is absolutely supported in any DOM element by adding overflow-y: auto;.
It was simply deemed to be the wrong default for packaged apps which live inside a dedicated window of set bounds and where we encourage not having full page content overflow (very much the opposite of the web). Most apps usually surround a main scrolling element with fixed navigational elements (but not always).
FYI, there is also another open issue for Chrome Apps on Mobile to replicate yet more of the Chrome for Desktop default styles.
Thanks to Firefox's 3D View I detected an empty <div> far outside the boundaries of my GWT 2.5.1 app's screens. Here's a screenshot:
You can see the main app screen below, a couple of outsider <div>s on top of it (which I attribute to the inner workings of layout panels) and above them all, the unexplained <div>. It is represented by the following doc element (copied from Firefox's own dev tools):
<div style="position: absolute; z-index: -32767; top: -20cm; width: 10cm; height: 10cm; visibility: hidden;" aria-hidden="true"> … </div>
The <div> precedes the RootLayoutPanel element (used ensureDebugId to find out). The problem is that it is this <div> that causes an undesired right margin in the app's mobile views (which have limited width). Removing this <div> using dev tools eliminates the problem.
Does anyone know the origin of this <div> and what could get rid of it?
P.S.: I tested the issue on mobile Firefox to test a theory that this might be due to one of my add-ons. Alas, also happens on the mobile Firefox 21 which has none of my add-ons installed.
Update
A GWT project member commented on the issue, not recommending the use of layout panels in mobile applications. I switched from using the RootLayoutPanel to using the RootPanel and the problem indeed went away.
As a work around use this in your CSS. I have not tested it with use of aria in widgets in the app.
div[aria-hidden="true"] {
right: 0cm;
}
But it will remove the horizontal scroll bar on mobile apps on iPhone and such.
All these divs are attributable to layout panels; they are "rulers" to detect changes in "relative units" (em and ex to detect font change –there's one such div per layout widget–; and cm to detect zooming –there's only one such div for the whole application–), because you can mix units when you position your "layers" in a LayoutPanel.
I think the fixedRuler (for cms) should be positioned not only at top:-20cm but also left:-20cm (or possibly right:-20cm in RTL). Would you mind filing a bug at https://code.google.com/p/google-web-toolkit/issues/entry ? (and possibly even providing the patch: http://www.gwtproject.org/makinggwtbetter.html)
Going to try my best to explain this as I don't have a working example at the moment.
I've found now with two sites, both using twitter bootstrap as a framework, an odd occurrence regarding the form placeholder element.
Take this theme for example, and note the newsletter form in the footer.
Theme
It uses the placeholder form attribute to label the name and email elements.
Now when viewing on an iPad/iPhone these display fine. Switch the orientation, and it will adjust fine, but then switch the orientation back, (i.e. portrait>landscape>portrait) and it throws the page off and knocks it off to the left. The layout is no longer fixed to the width.
I cannot understand why this is?
Any ideas?
This is a bug with iOS6, resolved in iOS7. Setting overflow: hidden; on the parent element of the input element (for example the form) fixes the problem.
One of my designers sliced up a PSD & for some reason the page isn't rendering on iPhones or iPads. The div that contains a feedback link is the only thing that is visible. I've spent some time on the issue, but can't seem to find the issue. Have a look here: http://bit.ly/jNcJ47
I get the same problem in Safari on my Mac. I messed around with the Web Inspector for a few minutes and found out that when I disable the sidebar1 element's height: attribute, the content appears.
that's because the width occupied by the sidebar1 div is making the rest drop to the bottom! and since your container div has the overflow hidden, it doesn't even show the other floatted divs that dropped.
I advise positioning that div absolutelly and you're done.