I often encounter this issue when refreshing and browsing my asp.net website.
(I covered some of the information that was visible in the pictures below.)
Before Refreshing:
After refreshing:
This also happens when I navigate to a new page, but just like I mentioned before, it doesn't happen all the time but it does happen regularly.
I've added some Jquery to try and fix this but the problem remains.
$(window).bind("resize", function () {
$("#content").width($(window).width() - 16);
});
Also tried this code just to make sure the DOM is ready.
$(document).ready(function() {
$(window).bind("resize", function () {
$("#content").width($(window).width() - 16);
});
});
UPDATE:
I've fixed the content div by setting it's max-width to 980 pixels, the navigation menu is still leaving it's intended position. If anyone can provide an answer as to why this happened it would be appreciated, this max-width thing seems like a bit of a lazy hack because although it fixes the div's width it's a solution for a problem which shouldn't be happening in the first place.
These two pictures show the current problem.
Before refreshing:
After refreshing:
Related
I have an iframe in which the pushState is triggered in order to provide the user with the ability to browse back and forward.
This iframe has some transform applied to it, and the parent window responds to mouse move updating the perspective-origin.
See the page in question.
All is fine in Safari, but when browsing back in history with Chrome, the layout of the parent breaks horribly. This sounds crazy to me, as the iframe contents shouldn't ever influence the layout of the parent window.
To test you can browse a few tabs inside the iframe, then click the back button in the browser.
Also note how if you go to "People" tab, and open any of the persons with a picture, the "Back" button in the top left calls the same function bound to pop state (furnax.goBack), without affecting the parent window.
Either this is a bug, or browsing back the history does more than I think.
I hope anyone has some insight.
Popstate handler:
$(window).on("popstate", function () {
if (furnax.popStoryEnabled) furnax.goBack();
});
goBack function:
goBack: function () {
var myHistory = tempDb.getItem("prev").split(",");
var to = "";
if (myHistory != "") {
to = "#" + document.getElementById(myHistory[myHistory.length - 1]).id;
} else {
to = "#" + $(".view").first().attr("id");
}
furnax.load(to, "pushright", true);
myHistory.pop();
tempDb.setItem("prev", myHistory.toString());
},
This is happening for me in both Chrome 41 and Safari 8 on OS X 10.10.2. I don't think the issue is with pushState. I believe what's happening is that when you change the URL in the iframe, the browser sets focus on the iframe and auto-scrolls the document to show the full iframe.
I believe it's similar to a bug I'm experiencing with focusing on inputs inside a CSS transformed iframe. Webkit bug #143100, Chromium bug #470891.
I'm not sure if your situation qualifies as a bug, as I believe it's intended behavior for browsers to do everything they possibly can to show focused elements, even if that means scrolling an overflow:hidden element. Then again, I'm not positive the iframe is actually receiving focus, it might be a different issue that just has some overlap.
One thing I would try is to make the pop state handler move the "iPhone" to the center of the window, and only change its URL after it has finished animating. If that doesn't work, maybe you can take a look at the example page I reference in my bug reports. It might give you some additional insight into the nature of the automatic scrolling.
I'm running into something really weird with my HTML/CSS.
When I reload the page sometimes one of my elements ends up positioned where it's supposed to be (centered vertically) and sometimes it ends up out of the viewport (something like 700px above the top of the page).
That the page acts differently on different page loads is only half of the weirdness. If I remove body's height: 100% property and re-add it in the web inspector everything magically fixes itself. (body is this element's direct parent.)
My instinct tells me that the answer to the first part of the weirdness is that there's some race condition going on causing things to happen in a different order randomly. But I'm not sure what that might be or why it's affecting things.
What could cause removing and re-adding an identical CSS attribute from an element to cause the page layout to change?
I can't reproduce in a jsfiddle unfortunately but here's a gif of this in action:
Edit: A new piece of the puzzle. I've discovered that this only happens in Chrome and appears to happen only if the page is loaded with an empty hash on the URL.
http://myurl.com works
http://myurl.com/#foo works
http://myurl.com/# intermittently has issues
There was a workaround to trigger a re-flow posted by #Huangism below but there are some caveats (some complications with timing when exactly to trigger a re-flow and also triggering a re-flow on a working page causes a flash of the content).
I think this is a weird bug with chrome, try this
After the content is shown, using jquery - hide the div that contains that content, check it's height and show it
Assuming $el is your jquery div element
$el.hide().height();
$el.show();
Try it and see if it fixes the issue or not
Try setting the height using js or jquery.
It looks like when you reload the page your CSS attributes are set to your body tag via style="" and then quickly removed. Its likely something in your js
Good grief this is hacky. Would still love an explanation for exactly what's going on and the proper way to deal with it but...
After figuring out that somehow an empty hash being appended to the URL was part of the issue an acceptable workaround seems to be completely removing an empty hash if present by using the html5 history API.
My code looks something like this:
// when the page is ready...
$(function() {
// if the url ends with a "#" (and the browser supports it...)
if(window.location.href && window.location.href.indexOf('#') == window.location.href.length - 1 && window.history) {
// clear the darn empty hash using the html5 history API
window.history.replaceState({}, '', './');
}
});
I'm having a problem with CSS Bootstrap on images that overlap on each others. The problem is also that sometimes it happens, sometimes it doesn't so it's very inconsistent.
I also noticed that if I click on F12 Dev tools, the images automatically get spaced properly.
I tried refreshing the cache pressing CTRL+F5 but the problem remains.
This is the website http://www.sdhealthy.com/productssnacks.html
and this is a sample of images overlapping (picture).
Anybody can please point me to what's wrong on the CSS code??
I've had a look through your code and you are using the isotope jquery plugin to position and animate the divs with 'isotope-item class'.
I suspect that you need to add this part of your jquery...
$(".isotope-w").isotope({
itemSelector: '.item',
layoutMode: 'fitRows'
});
to a $(document).ready function.
This is because the isotope plugin is calculating heights of the divs before the images have finished downloading.
A "workaround" would be to manually add the height attribute to each of the images but I woould try and correct your jquery.
Firebug is also reporting an error:
ReferenceError: $ is not defined: $(document).ready(function () {
http://www.sdhealthy.com/productssnacks.html
Line 29
If your isotope code is already supposed to run on document ready, this error will prevent it from running.
Im using The HTML Mobile Bolierplate and im trying to get the URL Address bar to hide using:
<script src="/static/js/helper.js"></script>
<script>
MBP.hideUrlBar();
</script>
But it's not working, the helper.js loads okay. Anyone know where I'm going wrong?
Thanks
Waiting until the DOM's load event is fired is always a good practice before running UI manipulating code.
For novice users:
jQuery:
jQuery(function() {
MBP.hideUrlBar();
});
Zepto:
Zepto(function() {
MBP.hideUrlBar();
});
For guys coming from Google, I think the MBP.hideUrlBar() function needs a little bit explanation on how to use it. I took time to make it works on Android (native browser only, Chrome can't hide his address bar) and iOS :
First, your page NEEDS to have a scrollbar (it means that your website must NOT be html,body height:100%)
If you want your website to be 100% (which was my case) you will need to calculate manually the height to add to html,body to be sufficient to hide entirely the scrollbar (this mean that we need to know the height of the address bar...)
If you want the MBP function to works on load event, use MBP.hideUrlBarOnLoad(). Beware, it will only works on load event, not on every resize (orientation changes). You will have something like that in your resize function :
function resize(){
firstLoadOfThePage ? MBP.hideUrlBarOnLoad() : MBP.hideUrlBar()
}
(assuming that firstLoadOfThePage is a tag to know when it is the first load of the page (first call of resize function)
Hope it will help.
You can try:
window.scrollTo(0, 1);
to hide the address bar.
On an HTML page, a link like this:
Location on Page
...should navigate to this spot on the page:
<a name="pagelocation">
But in my experience, it sometimes misses - especially when linking from another page (like <a href="somepage.html#pagelocation">). By "misses," I mean it scrolls to the wrong spot on the page - maybe close, maybe not.
Normally, the target location ends up at the top of the screen. I know this can fail if there's not enough room below the anchor to scroll it to the top of the screen.
Why else would it fail? Does it depend on layout at all? How can I fix it?
(I'm keeping this general because I'd like a catch-all reference answer.)
Update 1
Thanks for the pointers so far about non-explicit image sizes. But what about on a page where all the elements have explicit size? (I'm dealing with one now.)
Quite often the scrolling can occur before the page has finished loading. If you have images without widths and heights, the page will jump, then load the image and re-layout itself, making the place you previously jumped to seem wrong.
Edit: Anything else that can change page layout should also be considered with suspicion... this include javascript and CSS that's not loaded in the <head> (never mind that all CSS should be loaded in the head; it isn't always).
If the page is bounced through a redirect, I believe IE will scroll the end page but Firefox won't.
JS Solution
Run this function on document ready.
function goToAnchor() {
hash = document.location.hash;
if (hash !="") {
setTimeout(function() {
if (location.hash) {
window.scrollTo(0, 0);
window.location.href = hash;
}
}, 1);
}
else {
return false;
}
}
I believe the behavior you are seeing is the result of the browser locating to that spot on the page before all images have finished loading. Once the images finish loading, then the layout of the page has changed (the page is likely longer vertically, for example), causing the location of where the anchor should be to have changed - but the browser still thinks it has already navigated to that anchor.
As mentioned above, this is probably due to images being rendered late and 'adjusting' the layout as they load.
If you can specify the size of the images then that much room can be allocated before they render, which should prevent the problem.
As a side note I've had this problem before in the form of using forward/back between enough pages that the images needed reloading, causing me to end up in the wrong place after they had rendered.
I have also seen this happen when JavaScript creates a drop-down menu at the top of a page. Then, once the menu has been finished, it is hidden, scrolling up the content below.
In the meantime, the browser has already set the target location at the top of the window. Hiding the menu a the very top of the page moves the target location up off the top of the window.
Note that you can add id="pagelocation" to just about any HTML element, for the same result, which saves you adding the additional anchors for link destinations.
OK. I think this is new. Using HTML5's autofocus will cause a misfire, as will jQuery's focus() method. Took 90 minutes of trial and error to discover this because I thought the issue was image related :)