Geoff Welsh wrote:
Trane Francks wrote:
On 1/25/14 7:35 PM +0900, andré wrote:
Ed Mullen a écrit :
Ed Mullen wrote:
Okay, here's a weird one.
Someone was perusing one of my Web sites and said, to paraphrase:
"If I click in the vertical scroll bar below the handle (grippy) the
page scrolls down more than one full screen."
That is, the vast majority of pages (I've checked many) will scroll so
that the bottom of the first page is now at the top. The pages on my
site scroll up past that, so that the content of the initial screen is
above the top of the page. Meaning that the user will be missing, not
see, some content.
I cannot give a definitive example since it depends to some extent
upon
browser window size. But, try it at, for instance:
http://edmullen.net/mozilla/moz_combine.php
I only give this page as an example because it requires several
scroll-downs to see the entire page.
Then try any Amazon.com page. I haven't found one where it happens.
Oddly, having checked it in:
IE 11
Opera 18
Chrome 32
Safari (Windows) 5
Pale Moon 24 Moz-based
SeaMonkey 2 Moz-based
Firefox 26 Moz-based
only the Moz-based browsers exhibit the problem.
I'm posting here first but it may be an HTML or CSS issue. Which I
would then pursue in an appropriate Usenet group.
I have tested this on a varity of sites online and most do not exhibit
this but several do.
Any thoughts welcome.
I've done some more investigating.
The problem is that Mozilla-based browsers (at least the three I tested
above) are handling Page Down keypress and clicking in the scrollbar
area differently.
When a Web page is longer than the viewport (as in the below example
pages) the user scrolls down the page either by pressing the Page Down
keyboard key or by clicking in the blank area of the scrollbar below
the
"handle". The page should scroll down and present at the top enough of
what was previously at the bottom to give context to the user.
When a page has a fixed header at the top (using the CSS property
position: fixed;) and the user hits Page Down, the page is scrolled
properly and context-giving content is show at the page top below the
fixed header. When the user clicks in the scrollbar area the page is
scrolled based on the entire viewport length. Hence, the
context-giving
content is underneath the header and not visible to the user.
Here are example pages where you can see the problem:
<http://edmullen.net/test/scroll_test.html>
<http://www-03.ibm.com/press/us/en/pressrelease/43008.wss>
<https://googledrive.com/host/0B9Ry6ju9pHDRelRwbFhGZlhlaWs/start.html>
<http://happycog.com/>
I tested this in the seven browsers listed above and only the Moz-based
browsers exhibit this issue.
If I can figure out how I'll enter a report at Bugzilla.
Probably due to gnome changing the behavior of gtk. It affects any
gtk-based application unless overridden.
Under gtk, a regular mouse click now goes to the proportional position
in the file, instead of moving a page (up or down).
You have to do a minor click (left click if right-handed) to keep the
old behavior.
Ridiculous change in my mind. Before you could always drag the position
icon to go to a certain position in the file.
They could have kept the old behavior for a regular click, and used the
minor click for a position in the file.
The problem is reproducible under OS X, so I doubt it's a GTK problem. I
don't use Gnome. ;) Moreover, the issue isn't that clicking a position
in the scroll track moves to that relative location in the page. The
problem is that clicking in the scroll track scrolls the page based on
the full viewport area instead of the current frame region.
after finally using a keyboard with a "page down" key, I finally
understand what you guys are talking about. If he /were/ using Frames
in the page design, there likely wouldn't be an issue but he's merely
"fixing" a header DIV to the top of the entire page and, arguably,
Mozilla browsers are reacting correctly, as the whole page is rolling
up, including a part you can't see. Make the rest of the page another
DIV with a +1 Z position and you'll see it I bet.
Well, I can't agree that the Moz browsers are "correct" in handling this
situation. Having a fixed element on a page should not produce this
behavior and, as I said in my OP, other browsers are NOT doing this.
Possible solution: make the whole rest of the page another DIV and
position it (absolutely) below the Header DIV. But I haven't tried it
GW
Nope. I tried it and it really screws things up. But thanks for the
thought. :-)
--
Ed Mullen
http://edmullen.net/
And whose cruel idea was it to put an S in the word Lisp?
_______________________________________________
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey
