I've had an intermittent problem that I thought was due to un-cleared floats. What happens in Chrome (my main development browser) is the vertical scrollbar will lock in the top position and I cannot scroll down the page. Initially when the page starts to load it will allow you to scroll and then when the page is loaded it will jump back to the beginning and lock itself.
I've just been ripping apart my pages looking for un-cleared floats and missing tags and finally found out that it is due to a URL having a # at the end (which gets programatically added and remains when I refresh the page).
This issue only happens in chrome - does not appear to happen in other webkit browsers.
I assume its looking for an anchor and not finding it and then giving up. Its definitely a bug but was wondering about a workaround, or why it is only doing it on my site - I can't duplicate it for instance here.
Shift click the URL to open in new browser:
URL that will lock : /faq#
URL that doesn't lock (same but without the #): /faq
For me, the solution was in a popup div's style: I had to make sure a div with a z-index and no float but surrounded by floating divs was given the style float:none and an explicit width (floating this was not needed as it was absolutely positioned). I have a thread working through this here.
Related
My Ionic1 app displays a list of items that can be collapsed/expanded, so the vertical length of the content can increase significantly when an element is expanded (the way I do it is through ng-show directives).
My issue is that when this happens, I cannot scroll down to see the new content. Actually, if I drag my finger from bottom to top, I can see the new content appear in the bottom, but as soon as I release my finger, some elasticity brings back the top of the content.
However, strangely enough, after a few seconds, the scrolling mechanics is updated correctly and I can scroll normally.
It looks like the Ionic framework takes some time to figure out that the content length has changed and needs some update in the scrolling mechanics... I would like to tell him immediately once it is needed. I tried to call $apply from the onClick call back of the Expand buttons, but I get an error saying I am already in a digest cycle.
Any clue to fix this please? Many thanks!
You can avoid $apply approach because every $scope.$apply is rebind in the page. So you can follow the ionic scroll concept.
ionic scroll
Thanks! this helped me fix the problem, by adding a call to $ionicScrollDelegate.resize() whenever some item is collapsed/expanded.
You can check the issue with this fiddle: quickly expand groups 7/8/9 and try to scroll down:
http://jsfiddle.net/shengoo/6b0y3tar/
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({}, '', './');
}
});
HELP, this is a very unique problem and I can't for the life of me figure it out.
My flash content is overlapping the HTML above it.
This only happens if I've just launched IE after being restarted and goes away once I refresh the page. I even added a jQuery $(document).ready function that sets a margin between the html and the flash content to add 1px of space when the page is loaded. It's so hard to figure out, because once I refresh the page, it goes away.
Any input GREATLY appreciated.
Here is the site.
http://www.californiaremodels.com
(This only happens in IE)
here is a screen shot of the problem.
########### SOLVED ###################### SOLVED
I set the flash output as a javascript var (actually json_encoded PHP output) and on document load inserted the object into the "flashContent" div with the jQuery.(document).ready event.
Thank you to Andy Shellam!!
Have you tried loading your flash content using jQuery? I.e. set your div width/height in your HTML with a "this requires javascript/flash" placeholder, then have jQuery load the OBJECT into the div on page load. This way cures IE7's annoying "click here to activate this control" issue - may be a similar issue.
It may be due to the fact that you're floating that DIV that holds the flash content. It shouldn't matter, but sometimes IE gets hinky about such things. Try taking off the float and see if that cures the problem. If it does, create a non-floating workaround.
looks like it is the -4px of margin top you have that is creating the problem
I have a forum page that displays a tree view of messages below the currently selected message. When you click on a message in the tree the new message body is loaded into a div near the top of the page using AJAX and then the following code is run:
window.location.hash = "page_top";
Of course "page_top" is an anchor element near the top of the page, so the newly loaded message body scrolls into view.
This works fine on all the browsers, except Safari. On Safari (tested on PC and iPhone) it only works the first time you set location.hash. If you set it again the page does not scroll.
The end result is that the newly loaded message body does not scroll into view in Safari and you have to scroll back to the top of the page every time you pick a new message from the tree.
Why does Safari not like this and is there anything I can do to fix it ?
Edit:
I'm guessing this is related to a bug that you can find by Googling about location.hash and Safari. It seems Safari used to have a bug where if you set the hash to the same value twice it would cause it to reload the page. I'm guessing when they fixed that bug they fixed it a little too thoroughly and stopped it doing anything when you set hash to the same value again.
http://www.howtocreate.co.uk/safari/locationHashBug.html
You could reset it first:
window.location.hash = "";
window.location.hash = "page_top";
I needed to add:
<div><a name="page_top"></a></div>
<div><a name="page_topnot"></a></div>
Using "a name" instead of "a href". Works great!
Answering my own question. Gumbo was on the right track, but not quite there.
Safari doesn't like location.hash being set to a blank value. Instead you need to set it to a real anchor value.
So along at the top of the page I now have:
<div></div>
<div></div>
I found that I needed the divs around the anchors otherwise Safari was scrolling to an unpredictable part of the page rather than to the anchors.
Then to scroll to the top of the page I have to do:
window.location.hash = "page_topnot";
window.location.hash = "page_top";
With that in place Safari will scroll to top of the page every time.
I had the same problem as you had and this solution worked - the only thing I noticed was that in IE, I could hear two clicks - So I did a variation of yours and just put one anchor and it worked as well (ie, call twice, the first time, a non-existent anchor, the second time the real one)
On top, my anchor:
(tag a)name="top" id="top"(end of tag a)
Within javascript, the two calls:
window.location.hash ="topnot";
window.location.hash ="top";
Thanks for your help!
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 :)