Ed's Odd scrolling issue

jfaerber172 · Feb 16, 2014

Why, you can't find pages on the web with fixed headers that behave as
expected in current FF versions? They're not rare.

Neil

I still don't understand the FF issue with Ed's page and your discussion.
just wanted to add this http://solutions.trendsmap.com/
that page uses a different speed for a background image in the middle
but yes, I heard recently complains about FF on linux ubuntu -
the scripts didn't work as expected after an update

dorayme · Feb 16, 2014

I still don't understand the FF issue with Ed's page and your discussion.

Roughly this, it started with that the latest FF browsers only partly
knew that there was a fixed header (and perhaps footer but let's keep
it simple). It knew in that it displayed the HTML/CSS as the author
intended, it also knew in that when a user used the Page Down command
(e.g. on a keyboard), the content at the bottom of the content would
scroll to the top of the content.

It did not know in that when a user gets a mouse pointer on the
scrollbars and clicks under the bottom handler (an alternative Page
Down action in FF as with some other browsers) it made the bottom of
the content disappear under the header.

FF does have algorithms for getting Page Down as is wanted in some
circumstances. The browser can detect that the header is fixed *and*
completely across the viewport (as when e.g. width is specified to be
100% when there are no side borders or paddings in the direct BODY
containing element) and probably is of a modest height.

But, to the consternation of the OP, it does not apply this or a
functionally equivalent algorithm to the Click Under Scrollbar
handlers.

The wider issue was that many browsers people use don't even do Page
Down as is wanted with fixed headers. Other issues were to do with
there being no respected standards on all this, that it was
complicated in that there are other sorts of fixed header designs
where content from the bottom is wanted to scroll to the top of the
viewport.

Gus Richter · Feb 17, 2014

Roughly this, ..........

In a past posting here, I suggested to use the approach I would take (of
which I gave a demo):

+--------------+
| fixed header |
+--------------+
+--------------+
| |
| scrollable |
| |
| section |
+--------------+

I believe the OP indicated that it resolved his problem.

Instead of the OP's method of placing a fixed item within a scrollable
section:

+---------------+
|+-------------+|
|| fixed header||
|+-------------+|
| |
| scrollable |
| |
| section |
+---------------+

I can understand why a browser would have trouble with this, or why
anyone would wish to use this method.

Gus Richter · Feb 17, 2014

Gus, I always appreciate your posts. But, I'm not getting what you're
suggesting here.
What are you saying that I'm doing that is causing the problem?

I'm not saying that you're doing something wrong. I'm suggesting to use
a different approach, that of not embedding the fixed div within the
scrollable div, but to have two distinctly separate divs. It's the way I
would do it (see the demo I provided in another thread). The fixed one
within a scrollable one seems to me to be contradictory and could cause
problems (apparently it does?), although the fixed one is removed out of
flow - as in absolutely positioned.

dorayme · Feb 17, 2014

....

Your example, when generalised, seems to suffer the same glitch in FF
that was pointed out in the first place. Even Page Down does not work
as you would want in other browsers.

Is there something significant and crucially relevant in your proposal
different to

<http://dorayme.netweaver.com.au/fixedHeaders/fixedHeader_gr.html>

which fails to address Ed's concern.

Gus Richter · Feb 18, 2014

In my pages the header is the first <div> immediately below the <body>.
The rest of the page contents are in <p> tags.

Just to get our reference right, we're talking about:

Even placing the rest
of the page in a single <div> of its own changes nothing.

If you mean immediately after your:

</div>

up to just before:
</body>

and then applying/moving the styles required for this div as applicable
from body { ..... } ?
This would fit the first ascii drawing as I suggest.

Am I understanding you correctly?

I believe so.
I remind you of my demo:
<http://codepen.io/anon/pen/FwAdr>
and since I was unsure as to your problem, I asked, "Does it relate and
help?" to which you replied, "Definitely relates. I can see that what
you've done results in the phenomenon going away. I must confess I
don't understand why!"

Gus Richter · Feb 18, 2014

Your example, when generalised, seems to suffer the same glitch in FF
that was pointed out in the first place. Even Page Down does not work
as you would want in other browsers.

Is there something significant and crucially relevant in your proposal
different to

<http://dorayme.netweaver.com.au/fixedHeaders/fixedHeader_gr.html>

which fails to address Ed's concern.

OK, so I recall that I originally did not contribute to the thread re.
his "problem". The reason was that I did not think it a coding problem
but something nitpicking on the client side and it did not interest me
and to be honest, I did not understand the "problem" since I could not
see it.

Later due to the numerous posts, I thought it was related to another
problem I was involved with and questioned if it related - a demo
included. Ed stated that it worked.

Based on his response, I tried much later (now) to explain, since the
perception on my part was that there was a misunderstanding as to what I
was saying.

Now you say (with understanding of what I've been saying) that it does
not work, so I've carefully read Ed's problem:
"If I click in the vertical scroll bar below the handle the page
scrolls down more than one full screen."
I've now checked his original page and your demo on several browsers and
find the following:
1. I've misunderstood the "problem".
2. All other browsers (webkit & IE) except for FF scroll down, every
time, exactly one screen no matter where I click past the vertical
scroll handle.
3. FF scrolls down proportionally. So, just past the handle, one
screen. Half way down, FF scrolls half way down the page, three quarters
down it scrolls down three quarters down the page/doc., etc.

The bottom line, as I see it, is that it is a matter of browser design.
I kind of like that I don't have to click several times to get to a
point beyond several screen full, although I don't use this "feature"
very much. A FF user should be aware of this feature and recognize that
it is not a failing, but an added "feature". It could be said that all
other browsers should have this "feature".

My initial thought on this thread is hereby confirmed to me and I'm
sorry that I joined in, although I remain firm on my layout suggestion
even though the questionable (to me) one works. Beyond this, I'm out of
this thread. Sorry for the confusion I caused.

dorayme · Feb 18, 2014

Gus Richter said:
OK, so I recall that I originally did not contribute to the thread re.
his "problem". The reason was that I did not think it a coding problem
but something nitpicking on the client side and it did not interest me
and to be honest, I did not understand the "problem" since I could not
see it.

Later due to the numerous posts, I thought it was related to another
problem I was involved with and questioned if it related - a demo
included. Ed stated that it worked.

Based on his response, I tried much later (now) to explain, since the
perception on my part was that there was a misunderstanding as to what I
was saying.

Now you say (with understanding of what I've been saying) that it does
not work, so I've carefully read Ed's problem:
"If I click in the vertical scroll bar below the handle the page
scrolls down more than one full screen."
I've now checked his original page and your demo on several browsers and
find the following:
1. I've misunderstood the "problem".
2. All other browsers (webkit & IE) except for FF scroll down, every
time, exactly one screen no matter where I click past the vertical
scroll handle.
3. FF scrolls down proportionally. So, just past the handle, one
screen. Half way down, FF scrolls half way down the page, three quarters
down it scrolls down three quarters down the page/doc., etc.

The bottom line, as I see it, is that it is a matter of browser design.
I kind of like that I don't have to click several times to get to a
point beyond several screen full, although I don't use this "feature"
very much. A FF user should be aware of this feature and recognize that
it is not a failing, but an added "feature". It could be said that all
other browsers should have this "feature".

My initial thought on this thread is hereby confirmed to me and I'm
sorry that I joined in, although I remain firm on my layout suggestion
even though the questionable (to me) one works. Beyond this, I'm out of
this thread. Sorry for the confusion I caused.

You have not caused any undue confusion. This is a usenet thread and
it is important for one's sanity not to have very high expectations.

* The main problem that OP saw was that Page Down worked as he
expected with his pages but Click Under Scrollbar handler did not in
FF.

* Some fixed header designs can seem to operate well in very limited
conditions (the particular viewport size of a user, the text size, the
height of the header etc). But flex these as is the case in the real
world and things often do not work so well.

* It is a browser problem insofar as OP's concern (his intense and
unshakeable focus was Mozilla and the difference between Page Down and
Click Under Scrollbar handler (this is to all intents and purposes the
same functional command, just differently delivered (keyboard vs
mouse).

* The problem is wider than this and affects other browsers, it is not
just a Mozilla thing, notwithstanding your experience with a site you
helped someone on (not even Page Down works on the URL I gave of the
essentials of your url in my Safari, to take just one webkit browser).

* FF is a bit of a tease in all this in that it sets up expectations
that are easily dashed. It tries and often can succeed in making Page
Down (the keyboard command) work in fixed header situations where
other browsers quite fail.

BootNic · Feb 18, 2014

[snip]

3. FF scrolls down proportionally. So, just past the handle, one
screen. Half way down, FF scrolls half way down the page, three
quarters down it scrolls down three quarters down the page/doc., etc.

The bottom line, as I see it, is that it is a matter of browser design.
I kind of like that I don't have to click several times to get to a
point beyond several screen full, although I don't use this "feature"
very much. A FF user should be aware of this feature and recognize that
it is not a failing, but an added "feature". It could be said that all
other browsers should have this "feature".

about:config ui.scrollToClick default is 0

by default firefox will page up/down when the page up/down part of
the scrollbar is clicked.

Some browsers will scroll to click with SHIFT + CLICK on the page
up/down parts of the srollbar

--
BootNic Tue Feb 18, 2014 09:17 am
Behind every successful woman...is a substantial amount of coffee.
*Stephanie Piro*

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAlMDa4kACgkQOcdbyBqMFBEESwCgh5iwKt97LuqVDW2k61HC+YhW
Tn4AoOAa/RgYvioylg4fG4eVSM8JWHDW
=Rexf
-----END PGP SIGNATURE-----

dorayme · Feb 18, 2014

Ed Mullen said:
Nice summation of the issue. A couple of points.

1. Google Chrome does NOT exhibit this behavior

Not even Page Down works as you would want on my Chrome (send a bug
report to Chrome), and it does not work under my Windows in Virtual
Box either - not under different user text settings and viewport
settings that you might not be expecting. Will you send a bug report
to them ("Dear Chrome, not everyone in the world ...")?

2. Opera /almost/ gets it right

Send a bug report to Opera said:
3. Safari on Windows does NOT exhibit the issue

I should take your word on this, but my experience so far on this
business makes me doubtful. No offence intended. I will try to take a
look on my Virtual Box (but I am on XP Pro there).

4. IE 11 on Win 7 does NOT have the problem

I will test this when I get my hands on a capable machine for it.

5. Test case:
<http://dorayme.netweaver.com.au/fixedHeaders/fixedHeader_gr.html>
6. Test case: <file:///G:/edmullen.net/test/scroll_test.html>

I have filed a bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=973361

Do me a favour Ed, take out an ad in The New York Times so you get all
the browsers at once. That should get you some letters back from the
browser makers explaining how it is not exactly as easy as slicing
butter with a hot knife.

dorayme · Feb 19, 2014

Ed Mullen said:
....

I'm using Chrome in its native environment, Windows 7. So, if your
envron isn't doing what I say then I think YOU need to tell Google about
it, not me.

It is not me who is worried about this business, I am happy to use the
mouse wheel scroll or Page Down (where it works) and I am less likely
to use fixed headers and if I did, less likely to worry about how
people scroll. So you better get cracking: write to Chrome, Safari,

Tiny market share, not my job. My original post detailed that I got
interested in this because a Mozilla user mentioned it to me, no other
reason. So, little interest in helping Opera figure out their issues.

I guess it is wrong to assume that you are interested in your visitors
using any browser other than FF (many of which fail in Page Down,
never mind Click Under) in all sorts of OS environments

But, Virtual Box is not a native environ which is what I'm commenting on
and using.

Native, schmative, it is what some people use to browse some things.
The fact is that visitors to web pages use all manner of ways to
access your pages and if you are worried about a failure in FF over a
matter, it seems surprising you are so dismissive of failure on the
same score in other browsers and OS's and environments.

btw, I have since looked at Safari on Windows since and it fails to do
what you want in respect to fixed headers and scrolling.

dorayme · Feb 19, 2014

Ed Mullen said:
There is some routine that is called when a Page Down event is
triggered. All they need to do is call the same event when a
click-in-scroll-bar happens.

I will say it again, your type of fixed header design (as many others)
also fails in FF with respect to Page Down (to take FF's strongest
card) under some user text size, zooming choices, viewport
configurations. This routine is no magic god.

In the meantime, it's a conundrum that I've stopped obsessing over. It
still annoys me that I can't figure it out

Don't be hard on yourself, why should you be expected to *figure out*
something that browsers don't or can't do?

....

dorayme · Feb 19, 2014

Ed Mullen said:
I have noticed your saying that. I've zoomed and changed viewport size
and Moz browsers work the same regarding Page Down: That is, correctly.

It is unclear what you are doing exactly and with what URL? I made an
Ed type test case, gave the url to it and it does not work at large
text sizes in narrow but not silly narrow viewports on Zoom Text Only
on my FF 27.01. I am looking at it not working as you would want right
this minute. And that is just FF. There are other browsers too where
it does not quite do what you want.

Because of two things:

1. Some fixed header pages other than mine don't have the problem

So you say? Which ones? Maybe if you limit the height of the fixed to
a fixed small px count, if you give a min-width to it, you will get
the result you want in some browsers whose algorithms can handle very
restricted conditions.

2. I'm naturally curious.

You have been curious about a very focussed matter to do with very
narrow conditions. In the hands of the general public this sort of
concentration can be blown wide open. What am I saying? I am saying
there are wider issues to do with *robust* design that puts a page
safer out of reach of the evil forces in the real world that would do
bird like things on it from a great height.

Ray_Net · Feb 20, 2014

Nice summation of the issue. A couple of points.

1. Google Chrome does NOT exhibit this behavior
2. Opera /almost/ gets it right
3. Safari on Windows does NOT exhibit the issue
4. IE 11 on Win 7 does NOT have the problem
5. Test case:
<http://dorayme.netweaver.com.au/fixedHeaders/fixedHeader_gr.html>
6. Test case: <file:///G:/edmullen.net/test/scroll_test.html>

I have filed a bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=973361

No action yet.

Every, yes i say "EVERY", bug i reported against SM .... never end with a correction.

dorayme · Feb 20, 2014

Ed Mullen said:
But, I do believe it is a bug. It's been a long time since I did any
coding but I'm betting that if they changed the core so that a
click-in-scrollbar invoked the same sub-routine as Page Down, then the
problem would be fixed. Should be pretty damned simple.

And what would it be in browsers where neither Page Down nor Click
Under work as you would want? A general failure, an inadequacy? What
if FF just did something special for Page Down but never got around to
doing something you want for Click Under? Would the bit that they
failed to do be less of a bug and more of what other browsers fail to
do, a lack of a possible action.

It might be a bug if somehow it *always* worked in the past with both
Page Down and Click Under, then in some upgrade something rather
obscure went wrong with the code that was intended to work with the
Click Under.

All this without going into the assumption that even Moz Page Down
always worked well with fixed headers.

I feel like some sort of cynical gala perched on a branch snapping at
people passing under. Please forgive me. <g>

dorayme · Feb 20, 2014

Ed Mullen said:
I think it is reasonable to expect that both would produce the same result.

It might be reasonable to expect that Click Down works as Page Down
works. But is this relevant to the question of whether it is a bug if
it does not?

Not sure why you're reducing this to something I want. Is it
unreasonable to expect the program to do this?

It is not unreasonable and maybe you are right. We are focussed here
on you thinking a bug is at issue. It is hardly a bug issue with other
browsers that fail to do what is wanted with certain fixed header
designs. They just don't cater for such a complexity. Maybe the FF
people have not got around to addressing the Click Under effect in
fixed header situations. That does not *make it* a bug.

Nonsense. Examine the condition regardless of past performance. It is
what it is now.

Why is this nonsense? I reread my words and they make eminent sense -
perhaps I am biased! <g>. If a piece of software has two commands (one
from a keyboard, the other from a mouse) that result in exactly the
same effect for years and years and suddenly a new version has
different effects for these two same commands, then something has
changed. There needs to be an argument that it is *a bug*. Maybe it
is, maybe not.

If a piece of software *now* - forget about the past - does something
you want in one command but not in another command where it is
reasonable to expect the same in effect, there needs to be an argument
that it is a bug. A bug is more than that someone has not bothered to
do something. It might be the result of this, but it is not identical
to it.

Don't care how it worked in any previous version. The issue is what it
is NOW.

Fine. How it is now is that it is not even totally reliable in Page
Down in the way we might expect where an author designs with fixed
headers but in a way that allows great flexibility in user viewport
width and text size.

Ray_Net · Feb 20, 2014

I didn't say I expected anything positive to happen. :-D

And I filed the bug as Firefox, which might actually get some attention
as it's a much larger project than SM.

But, I do believe it is a bug. It's been a long time since I did any
coding but I'm betting that if they changed the core so that a
click-in-scrollbar invoked the same sub-routine as Page Down, then the
problem would be fixed. Should be pretty damned simple.

It's not because it's pretty damned simple that the developers will do it. They
prefer play with new gadgets instead of correcting their bugS.

Problem with android and scrolling with <input textarea	5	May 18, 2022
Issue with unused constants - wanting them to be used	0	Dec 5, 2024
iframe scrolling	5	Aug 6, 2009
Need assistance finetuning HTML, CSS, Javascript - sticky header issue	3	Feb 25, 2022
I need some help on a format issue that should be simple for someone here (but not me!)	0	Jul 6, 2023
Odd character display / UTF issue ?	5	Oct 15, 2007
Scrolling Issue	0	Sep 8, 2008
Re: Frameset scrolling	4	Apr 20, 2004

Ed's Odd scrolling issue

jfaerber172

dorayme

Gus Richter

Gus Richter

dorayme

Gus Richter

Gus Richter

dorayme

BootNic

dorayme

dorayme

dorayme

dorayme

Ray_Net

dorayme

dorayme

Ray_Net

Ask a Question

Similar Threads

Members online

Forum statistics

Latest Threads