Chrome scrolls too much when there is a fixed division at the top of the viewport

Question

I'm back.

When there is a fixed division at the top of the viewport, Chrome scrolls too much.

I have created a page which will allow you to text how your browser scrolls and if you have Chrome you can see how Chrome falls on its face.

THE DEMO IS AT http://thetesting.site/fixednav/scrolling.html

There are instructions as to how to use the page and how to reproduce the Chrome problem on the page itself.

I've been faulted for not providing the code of the page - here is all of it - there is no particular part of the HTML and CSS that I want help on. You have to look at the entire page.

I don't know if the snippet can be run - have never posted snippets before. Just go to the page and use it.

function resize() {
	// Get the height of the fixed-header. parseInt used to strip off the px in the value
	fixedHeight = parseInt(document.getElementById("topfixed").offsetHeight, 10);
	
	// Set the height of the fixed, scrolling, instructions division to the viewport height minus the 
	// height of the fixed-header and 20px "slop space"
	document.getElementById('instructions').style.height = (parseInt(window.innerHeight, 10)
		- fixedHeight - 20) + "px";
}

gblLastButtonClicked = 0;   // Yes, I'm using a global variable - did so because this is down and dirty.

function buttonclick(button) {
	// Set the height of the fixed-header from the value of the button just clicked. Values are 0px,
	// 10px, 20px....80px
	document.getElementById("topfixed").style.height = button.value;
	
	// Display the height in the button bar
	document.getElementById("heighttext").innerHTML = "Height is " + button.value + " ";
	
	// Set the body margin-top to the height of the fixed-header (as gotten from value of the clicked button)
	document.getElementById("body").style.marginTop = button.value;
	
	// Set the top of the Instructions division to the height of the fixed-header (from button.value)
	document.getElementById("instructions").style.marginTop = button.value;

	// Set the top of the buttonbar division to the height of the fixed-header (from button.value)
	document.getElementById("buttonBar").style.marginTop = button.value;

	// Set the previously clicked button's text to blank
	document.getElementById("button" + gblLastButtonClicked).style.color = "black";
	
	// Set the previously clicked button's font-weight to normal
	document.getElementById("button" + gblLastButtonClicked).style.fontWeight = "normal";
	
	// Set the last button clicked global variable.
	gblLastButtonClicked = parseInt(button.value, 10);
	
	// Set the text color of the button just clicked to red
	button.style.color = "red";
	
	// Set the font-weight of the button just clicked to bod
	button.style.fontWeight = "bold";
	
	// Call the resize function (defined above) to resize the fixed instuctions division
	resize();
	
	// Set the focus to the body of the page. It will be on the button just clicked and setting it to the 
	// body allows the use of the pagedown key without clicking on a part of the body - I've seen
	// some browsers which keep the focus on the button and, as a result, pagedown does not scrol the page	
	document.getElementById("content").focus();
	
	// Scroll the page to the top. We do this so the testing always starts at the same point and to save
	// the user from having to do so.
	window.scrollTo(0, 0);
	
}

function fillPage() {    // this function writes 150 lines of text into the body
	for (i = 1; i < 151; i++) {
		document.writeln("********************** Line #"  + i + "<BR>");
	}
}

	.button {
		width: 50px; 
		font-size: 12px;
	}
	.instructions {
		position: fixed ; 
		z-index: 10; 
		width: 40%; 
		overflow: auto;
		font-size: 15px;
		height:500px;
		left: 57%; 
		background-color: lightblue; 
		color: black;
		padding: 5px;
		border: 2px black solid;
		top: 0px;
	}
	.topfixed {
		background-color: yellow;
		opacity: .8;
		z-index: 1;
		position: fixed;
		left: 0;
		top: 0;
		width: 100%;
		height: 0px;	
		color: red;
		font-weight: bold;
	}
	.buttonBar {
		position: fixed;
		left: 0px;
		padding-bottom: 10px;
		background-color: green; 
		width: 100px;
		text-align: center;
		z-index: 10;
		top: 0px;
	}
	.content {
		width: 80%; 
		margin: 25px auto; 
		margin-top: 0px;
	}

function resize() {
	// Get the height of the fixed-header. parseInt used to strip off the px in the value
	fixedHeight = parseInt(document.getElementById("topfixed").offsetHeight, 10);
	
	// Set the height of the fixed, scrolling, instructions division to the viewport height minus the 
	// height of the fixed-header and 20px "slop space"
	document.getElementById('instructions').style.height = (parseInt(window.innerHeight, 10)
		- fixedHeight - 20) + "px";
}

gblLastButtonClicked = 0;   // Yes, I'm using a global variable - did so because this is down and dirty.

function buttonclick(button) {
	// Set the height of the fixed-header from the value of the button just clicked. Values are 0px,
	// 10px, 20px....80px
	document.getElementById("topfixed").style.height = button.value;
	
	// Display the height in the button bar
	document.getElementById("heighttext").innerHTML = "Height is " + button.value + " ";
	
	// Set the body margin-top to the height of the fixed-header (as gotten from value of the clicked button)
	document.getElementById("body").style.marginTop = button.value;
	
	// Set the top of the Instructions division to the height of the fixed-header (from button.value)
	document.getElementById("instructions").style.marginTop = button.value;

	// Set the top of the buttonbar division to the height of the fixed-header (from button.value)
	document.getElementById("buttonBar").style.marginTop = button.value;

	// Set the previously clicked button's text to blank
	document.getElementById("button" + gblLastButtonClicked).style.color = "black";
	
	// Set the previously clicked button's font-weight to normal
	document.getElementById("button" + gblLastButtonClicked).style.fontWeight = "normal";
	
	// Set the last button clicked global variable.
	gblLastButtonClicked = parseInt(button.value, 10);
	
	// Set the text color of the button just clicked to red
	button.style.color = "red";
	
	// Set the font-weight of the button just clicked to bod
	button.style.fontWeight = "bold";
	
	// Call the resize function (defined above) to resize the fixed instuctions division
	resize();
	
	// Set the focus to the body of the page. It will be on the button just clicked and setting it to the 
	// body allows the use of the pagedown key without clicking on a part of the body - I've seen
	// some browsers which keep the focus on the button and, as a result, pagedown does not scrol the page	
	document.getElementById("content").focus();
	
	// Scroll the page to the top. We do this so the testing always starts at the same point and to save
	// the user from having to do so.
	window.scrollTo(0, 0);
	
}

function fillPage() {    // this function writes 150 lines of text into the body
	for (i = 1; i < 151; i++) {
		document.writeln("********************** Line #"  + i + "<BR>");
	}
}

Well, take look at it and see what you think

I've only tested with Chrome and Firefox. If you have other browsers install, please try the page with the and let me know the results.

There are full instructions on the page.

EDIT - here is a page with screen captures of the demo page

EDIT - I have created a version of the demo page which has a work around for Chrome - for Chrome I unfix that fixed-header. I cannot post another link - I'm limited to two - but there is a link to the modified page on the original demo page.

EDIT - It has been seven hours since I posted the URL of the page with screen captures showing how it works and how I expect it to work and 23 hours since I posted the question.

Should I assume that this has everyone stumped?

Has anyone tried this with browsers other than Firefox and Chrome? If so, what were the results - what browser did you try and did it work like Firefox or Chrome?

I'd want to open a bug report with I'd like to first find out if it behaves the same way with Chrome with higher screen resolution than 1024 x 600.

Has anyone tried this on a screen with resolution higher than 1024 x 600 with Chrome? If so, what were the results? Does it work the same with Chrome with a higher resolution as with 1024 x 600 or does it work differently?

Should I post a step by little step at a time script for testing this? Should I spell it out step by step for Chrome and Firefox using the different height buttons?

EDIT - the last one.

Okay - I'll assume that either no one has any ideas to make it work with Chrome or no one wants to even read the question - most the "views" are probably my checking to see there has been activity.

I've reported this as a Chrome bug and will wait to see what comes of that. Has anyone actually gone to the demo page and tried it out with IE or other browser other than Chrome or Firefox?

I'll assume that this one has everyone is stumped. So much for even hearing from someone who tried a different browser of screen resolution....

Answer 1

I'm closing this out - my "answer" is that there is a problem which needs to be addressed. I've submitted a bug report to the folks at Chrome and I am pulling together a lot more documentation to aid them in evaluating the issue.

Since no one took the time to test this and get back to me, I still have not determined the extent of the matter. I have, however, had someone try it out on a screen of much higher resolution and they got the same results as I did.

As I have said, I'm using a standby system with a relatively low resolutions screen, and the issue could be related to some combination of things specific to this system - but, again, I don't have any detailed feedback from any one as to the results of any testing they did.

The issue, simply stated, is that if there is a fixed division at the top of the viewport, depending on the height of the fixed division, Chrome will scroll one or more of the next lines on the next "page" underneath the fixed division when you "page down" The reverse happens when you :page up" except the lines are scroll "off" the bottom of the viewport. I call this "losing lines."

One person said that it is not important, that the fixed divisions get over used, in short - you shouldn't do it and this is not really a bug. They said it is something you can "fix" with code; that it was no big deal and sort of like the chicken and egg thing - I don't quite get that one.

The comments were more in the vein of defending the problem rather than discussing it or sharing testing results.

I've encounter this bug on Yahoo pages and while no one is perfect - even myself - Yahoo has a good reputation for web design and function and, yet, they are using fixed divisions - are they commenting an error in having that fixed division on their pages? Are they sinning?

If the thought is that a fixed division takes up valuable screen space, well, given the physical size and resolution of new screens, that is hardly a consideration. Sure, you can over do it but there are times, if not a lot of times, when you'd like to keep controls available at the top of the viewport.

I've seen a trend, not away from fixed divisions but towards them, most especially fixed divisions which scroll with the page - for awhile. They don't go to the top and get "fixed" until you scroll down to the point that the information in the division would scroll off the top of the viewport.

Many pages now do this and people are wanting to duplicate it. I've seen a lot of questions as how to do "float the bar and then fix it when needed" here on StackOverFlow.

The first time I encountered such a bar, I thought - Oh, that's cute, but what is the point other than to show "hey, look what I can do?"

As with any tool or facility, you can over use fixed divisions or use them poorly. Whether or not the occurs is what separates computing professionals from the "unwashed masses. :-)

Just to stir things up - remember frames? How they are considered inherently evil? They are not evil, they simply have a couple of issues that caused problems. The most cited one being that when you bookmarked a "page" you really got a bookmark to the frameset, not the content. There is a very simple way to fix that - very simple - and that need not stop anyone from using frames.

You pick the what you think is the best tool for the job and if it has limitations, you either work around them or you reach for a different tool.

One last thing and I'll close this out.

I was discussing computers with a non-technical person and I was searching for a way to explain that computer programming entails far - FAR - more than just learning a programing language and I came up with the best analogy I've thought of so far.

You have three people. One is Spanish, one is Russian, and one is American and they are all three fluent in their native languages. Each of these people aspire to being an author.

Being fluent in a language does not mean you know how to write. Writing, good writing, is about far more than being able to put words together to make grammatically correct sentences. Writing is an art you must learn and constantly refine.

So it is which computer programming and all the ancillary processes which it entails.