[DOM] window.onscroll and element.onscroll don't fire

RESOLVED FIXED in mozilla1.3beta

Status

()

Core
DOM: CSS Object Model
P1
normal
RESOLVED FIXED
17 years ago
3 years ago

People

(Reporter: Martin Honnen, Assigned: Brian Ryner (not reading))

Tracking

({dom2, testcase, topembed+})

Trunk
mozilla1.3beta
dom2, testcase, topembed+
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [adt3 RTM])

Attachments

(5 attachments, 5 obsolete attachments)

(Reporter)

Description

17 years ago
DOM level 2 mentions the scroll event as an HTML event. I neither get
  window.onscroll
to fire nor
  <DIV ONSCROLL

Example (works fine for both cases with IE5):

<HTML>
<HEAD>

<SCRIPT>
window.onscroll = 
  function (evt) {
    alert('window ' + (evt ? evt.type : event.type))
  };

</SCRIPT>
</HEAD>
<BODY>

<DIV STYLE="overflow: auto;
            width: 200px;
            height: 200px;
            background-color: orange;"
     ONSCROLL="alert(this.id + ' ' + event.type);"
>
<SCRIPT>
for (var i = 0; i < 30; i++)
  document.write(i + ': Kibology<BR>');
</SCRIPT>
</DIV>
<SCRIPT>
for (var i = 0; i < 300; i++)
  document.write(i + ': Kibology<BR>');
</SCRIPT>
            
</BODY>
</HTML>

I am not sure whether DOM level 2 suggests onscroll for abritrary page elements 
as it just talks about
  The scroll event occurs when a document view is scrolled.
but I think it is a very useful handler that should be supported not only when 
the document view is scrolled but a page element too.
(Reporter)

Comment 1

17 years ago
Created attachment 7344 [details]
bug demo (scroll the page or the div and an alert should occur)
Tom, wanna have a look at this?
Assignee: jst → joki

Comment 3

17 years ago
I'm really down with this bug getting fixed. onscroll is mighty useful.  Ok 
that's my 2 cents ;)

Comment 4

17 years ago
Adding [DOM] prefix to bugs related to DOM Level 0, 1, or 2 
compatibility/compliance.
Status: NEW → ASSIGNED

Updated

17 years ago
Summary: window.onscroll and element.onscroll don't fire → [DOM] window.onscroll and element.onscroll don't fire

Comment 5

17 years ago
This bug has been marked "future" because the original netscape engineer working
on this is over-burdened. If you feel this is an error, that you or another
known resource will be working on this bug,or if it blocks your work in some way
-- please attach your concern to the bug for reconsideration.
Target Milestone: --- → Future
*** Bug 49672 has been marked as a duplicate of this bug. ***

Comment 7

17 years ago
*** Bug 62332 has been marked as a duplicate of this bug. ***
(Reporter)

Updated

17 years ago
Blocks: 62536
Keywords: dom2
Component: DOM Level 2 → DOM Style
Taking QA Contact on all open or unverified DOM Style bugs...
QA Contact: vidur → ian

Comment 9

16 years ago
does this bug have any relation to bug 52599 (<xul:srollbar>s should generate
onscroll events)?

Comment 10

16 years ago
I would like this bug fixed pretty soon. By default, when a document is resized 
the scroll position is kept the same. If the document contains text that wraps 
then this means that the document location moves when the width is changed. 
This is most undesirable for some applications.

With IE5 we record the first visible element each time the document is 
scrolled. Whenever the document is resized we then navigate the scroll position 
to the recorded first visible element. This cannot be done with Mozilla due to 
this bug.
*** Bug 87251 has been marked as a duplicate of this bug. ***

Comment 12

16 years ago
*** Bug 99919 has been marked as a duplicate of this bug. ***

Comment 13

16 years ago
Since this bug is not going to be fixed soon (joki hasn't even commented on it
since last summer), is there a known workaround if you want to do some action
when a frame is scrolled?

Comment 14

16 years ago
There isn't really a workaround but this isn't too hard to fix, its just 
been low priority for a while.  Based on a couple of requests, setting milestone 
for this bug to 0.9.6.  
Priority: P3 → P1
Target Milestone: Future → mozilla0.9.6
Looks like this won't make it in for 0.9.6.

Comment 16

16 years ago
0.9.6 has passed, moving to 0.9.7.  Load balancing 0.9.7 list shortly
Target Milestone: mozilla0.9.6 → mozilla0.9.7

Comment 17

16 years ago
Note this bug is strongly related to 52599 and 62536.

Comment 18

16 years ago
Moving bugs from 0.9.7 for triaging in 0.9.8
Target Milestone: mozilla0.9.7 → mozilla0.9.8

Updated

16 years ago
Target Milestone: mozilla0.9.8 → mozilla0.9.9

Comment 19

16 years ago
joki i'd really like to escalate this bug... it's one of the few remaining bugs
that we really need to fix to achieve acceptable IE-compatiblity. If you think
you won't have time to do it before mozilla1.0, I'll be glad to do it if you
give me instructions :-)
Keywords: mozilla1.0

Comment 20

16 years ago
->moz1.1 (dumping ground) per ADT triage
Target Milestone: mozilla0.9.9 → mozilla1.1

Comment 21

16 years ago
yo yo that won't cut it... I'm offering to implement this but last time I tried
I stumbled on some problems (the event worked microsoft'ish, i.e. it fired when
I didn't want it to and crashed), so I will need help. Sending this to
mozilla1.1 is definitely not the way to go. Requesting reevaluation please.

Comment 22

16 years ago
I second Fabian's opinion. When I got the mail about this (the Moz1.1 target 
milestone) I could not believe my eyes. This is not acceptable.

If there is anything I can do to make the process easier I'll gladly help you. 
Any test cases that you need?
Unsetting taget milestone, this should indeed be fixed for mozilla1.0. Joki,
could you shead some light on this for fabian?
OS: Windows 98 → All
Hardware: PC → All
Target Milestone: mozilla1.1 → ---

Comment 24

16 years ago
Okay, I'll retarget this to 1.0 and try to look at it in the next couple of days
to see what the implementation situation is.

Target Milestone: --- → mozilla1.0

Updated

16 years ago
Keywords: topembed
Taking from joki, per my discussion with him. 
Assignee: joki → radha
Status: ASSIGNED → NEW
Created attachment 74841 [details] [diff] [review]
Initial patch v 1.0

This patch triggers the onScroll event. But there are few bugs in it.

1) It always triggers the window.onScroll event,  even though you scroll in the
DIV.
2) The event is often triggered multiple times (and the page is scrolled that
many times) in the testcase attached. For example, if you do a pagedown on the
window or the Div, you will see multiple dialogs come up that says "Window
Scroll" and the page will scroll down that many times, even though you pressed
pagedowned only once. 
3) If you do a line scroll, you get into a  infinite loop. ie., the dialogs
just keep coming and the page continues to scroll down indefinitely. 
4) However, if I modify the testcase a little bit and change the alert() call
to a dump(), I	see that the event is triggered only once ie., you will see the
dump statement on the command prompt once and the page will also scroll only
once. The infinite loop with line scroll also goes away if I use a dump().
Created attachment 74842 [details] [diff] [review]
Initial patch v 1.0

This patch triggers the onScroll event. But there are few bugs in it.

1) It always triggers the window.onScroll event,  even though you scroll in the
DIV.
2) The event is often triggered multiple times (and the page is scrolled that
many times) in the testcase attached. For example, if you do a pagedown on the
window or the Div, you will see multiple dialogs come up that says "Window
Scroll" and the page will scroll down that many times, even though you pressed
pagedowned only once. 
3) If you do a line scroll, you get into a  infinite loop. ie., the dialogs
just keep coming and the page continues to scroll down indefinitely. 
4) However, if I modify the testcase a little bit and change the alert() call
to a dump(), I	see that the event is triggered only once ie., you will see the
dump statement on the command prompt once and the page will also scroll only
once. The infinite loop with line scroll also goes away if I use a dump().5)
The event fires for pagedown, line scroll, pagedown key event and mouse roll
event. 

I do not know DOM or JS enough to debug this further. I would like some
pointers on debugging the above problems.
Look at how NS_IMAGE_LOAD events are dealt with in
nsGenericElement::HandleDOMEvent() and nsXULElement::HandleDOMEvent(), you need
to stop them from going up the tree. Doing that should fix problem 1.

Try fixing that and report back what problems remain and we'll look deeper...

Comment 29

15 years ago
The scroll event should also fire when the element is resized and the scrollTop 
value is changed due to this.

An example. If you scroll all the way down on an element and resize it the 
scrollTop value changes and therefore the scroll event should be fired.

I'm not sure whether an event should fire if an element was resized and only 
the scrollHeight changed due to the resize.

The same applies to scrollLeft of course.

Comment 30

15 years ago
Comment #27 might be related to bug #112294

Comment 31

15 years ago
EDT: topembed- because we don't think it is critical to an embedding release,
but it does seem like a good thing to get done. Perhaps mozilla1.0+ is the
correct nomination?
Keywords: topembed → topembed-
Created attachment 75644 [details] [diff] [review]
Patch v1.1

Slightly better patch.	With this patch,

a) the document's onScroll handler is fired if the scrolling happens inside the
DIV. But after firing document's onhandler, it still walks up the hierarchy and
fires the handler at the window level. This should be fixed so that if the
event was handled at the Document level, we do not propagate further up the
hierarchy.

b) The window.onScroll is properly fired if the scrolling happened outside the
DIV.

c) I think bug 112294 deals with the problem I had described with multiple
firings. Multiple firing does not happen if I  replace	the alert() witha 
dump().
Attachment #74841 - Attachment is obsolete: true
Attachment #74842 - Attachment is obsolete: true
Created attachment 76633 [details] [diff] [review]
Cleaned up patch.
Attachment #75644 - Attachment is obsolete: true

Comment 34

15 years ago
Comment on attachment 76633 [details] [diff] [review]
Cleaned up patch. 

Looks great! Thanks for doing it! If I have time I will test this patch this
week.
Hopefully we can get it into 1.0.

>Index: nsGfxScrollFrame.cpp
>===================================================================
>RCS file: /cvsroot/mozilla/layout/html/base/src/nsGfxScrollFrame.cpp,v
>+     nsIFrame  * targetFrame = nsnull;

Could you please fix this to be |nsIFrame* targetFrame = nsnull|?

Comment 35

15 years ago
Ok after a little testing here's what I found:
1) Seems to work fine!
2) the event bubbles (don't know if it's good or not). For example if the
scrollbar of a div is moved, the body gets the onscroll event as well. Since
Radha described it in his last comment I'm guessing you have a handle on this one.

So, I'd say go for it! Not sure if I can review it since me and layout code
don't go along too well :-)

Comment 36

15 years ago
Scroll events should not bubble and should not use capture to be compatible 
with IE. If you for some other reason want them to bubble I'd like to hear 
your arguments for that.

If it bubbles when the developer does not expect it to, it will lead into a 
lot of confusion.
(Reporter)

Comment 37

15 years ago
The DOM specs clearly say:

scroll
    The scroll event occurs when a document view is scrolled.

        * Bubbles: Yes
        * Cancelable: No
        * Context Info: None

so the scroll event should bubble.
(http://www.w3.org/TR/2000/REC-DOM-Level-2-Events-20001113/events.html#Events-eventgroupings-htmlevents)

I don't think IE's implementation should be the aim, implement a scroll event
for Mozilla that is comliant with the specs and thereby fits into the W3C event
model. 

Comment 38

15 years ago
Once again the specs are not clear. It says "document view" and not element 
view. I wonder when the W3C plan to revise all their standards to include the 
notion of an element view and not only a document view.

Still since the W3C says that document.onscroll should bubble it might make 
sense to use bubbling for element.onscroll as well.

It is just too bad that the specs where not designed to follow the real world 
where such cases already existed. A lot of confusion will rise from this.

Comment 39

15 years ago
Radha did you send a request for review to anyone? I'd do it but I don't know
layout well enough. If you find nobody else I'll do it though. We really need to
get it on the trunk to for everyone to test so it can be put in 1.0 branch.
Hmm, I'm kinda leaning towards not bubbling these scroll events, mainly since
they don't in IE. The spec does say that the document scroll event does bubble,
but that doesn't really make sense, since there's nothing to bubble it to, the
document is where events stop as far as the DOM specs are concerned (we have our
own issues with bubbling them to the window object though), we might even be
able to convince the DOM WG to change the spec since it doesn't really change
any implementations that follow the spec in the first place.

Thoughts?
jst, If the document has no handler, IE does not bubble it to the window. But we
do. I talked to joki about this. He seems to think that our behavior is more
appropriate and he wishes to differ from IE in this case. 

Anyways, I asked joki to review the patch. But I think he is busy preparing for
the trip to Mtn View. Can someone else who knows this code well do a review for
me? Thanks.
Status: NEW → ASSIGNED

Comment 42

15 years ago
Hi, when approximately that fix will be available in build?
Regards.
This is the current status of this bug. With the attached patch, the onScroll
event bubbles even after being dealt by the target. ie., in this example, if you
scroll in the DIV, you will see the handler invoked at the DIV as well as the
one in the window. I understand that this is not the behavior we want. We would
like to behave like IE where, the handler will be invoked at the target only and
the event would stop bubbling after that.  

In order to achieve that behavior, I played  around in nsGenericElement.cpp and
nsXULElement.cpp. I tried passing the NS_EVENT_FLAG_CANT_BUBBLE flag, as
suggested by joki. But that completely shut out all the handler invocations,
ie., no handler was ever getting called when I scroll the page. I also tried
stopping the bubbling process for NS_SCROLL_EVENT in
nsGenericElement.cpp::HandleDOMEvent() (just like NS_IMAGE_LOAD does).  When I
did that, we achieve the behavior we want for the DIV, (ie., only the handler in
the DIV is invoked) but when any scrolling happens outside the DIV, the
window.onScroll handler does not get called.  

I think, one way to achieve the behavior we want is to stop the bubbling after
we know that the event has been processed by the target and any handler if found
at the target has been called. But I'm kinda lost on how and if it is possible
to do that. Would appreciate pointers on that.

Comment 44

15 years ago
What is the status of this? It is targeted for 1.0 but and there is a patch 
available.

According to comment #43 there seems to be a minor issue left. It seems like 
this issue could easily be dealt with by someone who knows the internal of the 
event system.

Comment 45

15 years ago
Since this is a [DOM] standards bug, shouldn't it be fixed asap?
1.0 is comming up...

Comment 46

15 years ago
Hi,
priority for this bug is 1, target v1.0.
In all sense this bug is blocking release, but release party already scheduled,
What do you gonna do, move target to 1.1 or fix the bug?

Comment 47

15 years ago
I would very much like to see onscroll fixed for 1.0

I contribute to the DOMAPI project - www.domapi.com - and would hate to have to
continue support for the interval timer work around.

I'm glad to see that this bug hasn't been left to the wayside. If there is any
chance that this will not be finished for 1.0 I'm willing to sponsor it, if that
helps. I don't have much money but could probably sponsor the bug for about $500
USD, if that is what it takes to get it finished for 1.0

Mark
This will unfortunately not make it into Mozilla 1.0 :-( Let's hope it makes it
into Mozilla 1.0.1.
Target Milestone: mozilla1.0 → mozilla1.0.1
Created attachment 85505 [details] [diff] [review]
Yet another patch

I think this patch gives the preferred behavior for this testcase. With this
patch, when you click on the Scrollbar of the DIV, the onScroll event is sent
only to the DIV. The event does not propagate further to the window. When you
click on the main window's scrollbar, the event is sent to the window only. 

This is what the patch does.

1) All scroll events were triggered only during the bubbling stage. So
processing of scroll events during the capture stage is avoided by adding 
(aEvent->message == NS_SCROLL_EVENT)  to
http://lxr.mozilla.org/seamonkey/source/content/base/src/nsGenericElement.cpp#1809


2) During the bubbling stage, after the event is handled at the local  stage,
it is not allowed to bubble further by adding, 
    if (aEvent->message == NS_SCROLL_EVENT && aFlags == NS_EVENT_FLAG_BUBBLE)
      aEvent->flags = NS_EVENT_FLAG_CANT_BUBBLE; 

at
http://lxr.mozilla.org/seamonkey/source/content/base/src/nsGenericElement.cpp#1837

and by adding,
aEvent->message == NS_SCROLL_EVENT && aEvent->flags !=
NS_EVENT_FLAG_CANT_BUBBLE at
http://lxr.mozilla.org/seamonkey/source/content/base/src/nsGenericElement.cpp#1850


3) This enables the proper propagation of the scroll event when it happens
outside the DIV and blockage of the scroll event when it happens inside the
DIV.

4) However, if the DIV has no event handler and the scroll event happens inside
the DIV, the event still gets propagated to the window. I'm not sure if we
should be avoiding this. 

5) I'm presuming that this will work for iframes too. But I haven't tested yet.

jst, joki, Please look through the patch and let me know what you think. I will
try to test it with other situations too and post the result soon.
Attachment #76633 - Attachment is obsolete: true
Stepping through the debugger, it looks like  it will be difficult to take care
of the situation #4 described above in the code.  But I think developers can
prevent event bubbling by adding, event.stopPropagation().
Comment on attachment 85505 [details] [diff] [review]
Yet another patch

I had a look at this and I'd say that this is ready for some testing on the
trunk... sr=jst
Attachment #85505 - Flags: superreview+

Comment 52

15 years ago
Sorry for the delay on the review.  I agree that there might still be a couple
of issues with this but that we should get it out there for testing and see what
people think.  We can modify it more if need be.

r=joki.
Attachment #85505 - Flags: review+
Fixed in the trunk. 
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Keywords: adt1.0.1
Resolution: --- → FIXED

Comment 54

15 years ago
Reopening. The checkin for this bug caused a number of problems on the trunk:
context-menu (right-click), ctrl+key (e.g. ctrl+t, ctrl+u) and page-up/down to
scroll no longer worked. I've backed this out so we can get verification done in
time tomorrow. The problem seems to lie in the changes to nsGenericElement.cpp,
my guess is that it's this chunk:

@@ -1849,7 +1854,8 @@
   //Bubbling stage
   if (NS_EVENT_FLAG_CAPTURE != aFlags && mDocument &&
       aEvent->message != NS_PAGE_LOAD && aEvent->message != NS_SCRIPT_LOAD &&
-      aEvent->message != NS_IMAGE_ERROR && aEvent->message != NS_IMAGE_LOAD) {
+      aEvent->message != NS_IMAGE_ERROR && aEvent->message != NS_IMAGE_LOAD &&
+      (aEvent->message == NS_SCROLL_EVENT && aEvent->flags !=
NS_EVENT_FLAG_CANT_BUBBLE)) {
     if (parent) {
       /*
        * If there's a parent we pass the event to the parent...

The logic there seems a little odd, since you're saying "well, if the message
isn't A, B or C, and if the message is D, then do this". That would mean that
you could completely remove the check for the message not being A, B or C, since
that's mutually exclusive with the message being D.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
This is also cause bug 152859

Updated

15 years ago
Depends on: 152810

Comment 56

15 years ago
what benefit would be derived by a user if this was checked in? are any top
sites using this fuction?
Whiteboard: [adt3 RTM]
Created attachment 88380 [details] [diff] [review]
Well-behaving patch

This patch takes care of the regression caused with key events and continues to
send the onscroll event appropriately.
Attachment #85505 - Attachment is obsolete: true

Comment 58

15 years ago
Comment on attachment 88380 [details] [diff] [review]
Well-behaving patch

sr=kin@netscape.com

To save reviewers time, the only difference between this patch and the previous
one is that this:

-      aEvent->message != NS_IMAGE_ERROR && aEvent->message != NS_IMAGE_LOAD) {
+      aEvent->message != NS_IMAGE_ERROR && aEvent->message != NS_IMAGE_LOAD &&
+      (aEvent->message == NS_SCROLL_EVENT && aEvent->flags !=
NS_EVENT_FLAG_CANT_BUBBLE)) {


was changed to:


-      aEvent->message != NS_IMAGE_ERROR && aEvent->message != NS_IMAGE_LOAD) {
+      aEvent->message != NS_IMAGE_ERROR && aEvent->message != NS_IMAGE_LOAD &&
+      !(aEvent->message == NS_SCROLL_EVENT && aEvent->flags ==
NS_EVENT_FLAG_CANT_BUBBLE)) {
Attachment #88380 - Flags: superreview+

Updated

15 years ago
Attachment #88380 - Flags: review+
Comment on attachment 88380 [details] [diff] [review]
Well-behaving patch

r=jst
A better patch checked into the trunk. ADT, please consider taking this into the
branch on Monday. 

This fix will benefit web developers a lot. It is also a DOM  compatibility
issue. There are several comments in the bug ( including #46, #47  ) indicating
that developers  are really waiting for this fix. The bug # itself is a
indication that it is a long pending issue. People have offered me money
privately thro' email (no kidding) to get this bug fixed. 
Status: REOPENED → RESOLVED
Last Resolved: 15 years ago15 years ago
Resolution: --- → FIXED
I have also been offerd money in private email for fixing this bug... Web
developers really want this fix.

Comment 62

15 years ago
ian/paw - can we get someone to verify this one on the trunk? thanks!
Testcase: http://www.hixie.ch/tests/adhoc/dom/level0/001.html
I can't test it right now since I don't have a recent enough build.
ok, windows.onscroll: VERIFIED

I take it element.onscroll should fire on elements with 'overflow' set to values
other than 'visible'? If so, I'll verify that later today once I have a testcase.
Please note that the patch that got checked in is just a first step towards
fixing all problems related to onscroll events (which was not even fired until
now). 
VERIFIED on trunk using
   http://www.hixie.ch/tests/adhoc/dom/level0/001.html (window.onscroll)
   http://www.hixie.ch/tests/adhoc/dom/level0/002.html (element.onscroll)
Status: RESOLVED → VERIFIED

Comment 67

15 years ago
marking adt1.0.1- per ADT.
Keywords: adt1.0.1 → adt1.0.1-

Comment 68

15 years ago
please checkin to the 1.0.1 branch. once there, remove the "mozilla1.0.1+"
keyword and add the "fixed1.0.1" keyword.
Keywords: mozilla1.0 → mozilla1.0.1+

Updated

15 years ago
Attachment #88380 - Flags: approval+
Keywords: mozilla1.0.1+ → fixed1.0.1, mozilla1.0.1

Comment 69

15 years ago
Looking at 

  http://www.hixie.ch/tests/adhoc/dom/level0/001.html

We get onscroll events even when a scroll hasn't happened.  For example, drag
the vertical scrollbar up beyond its bounds.  The event counter keeps
incrementing.  In IE6, the counter only increments if an actual scroll occurs.

Comment 70

15 years ago
Created attachment 90436 [details]
Problems with updating pageX/YOffset values in case xul:scroll and xul:slider are involved.

When the pageXOffset value show 0, try the following: click on xul:slider of
the horizontal bar, the horizontal scrollbar will advance but the pageXOffset
value will remain 0. Now, click on the xul:slider of the vertical bar: you'll
see that the pageXOffet value will update in the table form but the pageYOffset
will still remain 0. The same phenomenon is observed when one clicks on the
xul:scroll elements. The scrolling happens but the values get updated only on
the next click. Always reproducible. Windows XP Pro. Mozilla 1.1a+ 20020707
I don't understand how the problem described in the previous comment is related
to firing the onscroll events. Did the patch to this bug cause this regression?

Comment 72

15 years ago
Filed bug 156312 to address comment 69.

Comment 73

15 years ago
I do not know if the problems with updating pageX/YOffset values are related to
the firing of the onscroll event. They might not and, at first glance, they
should not. I don't know for sure if these problems are related to the patch.
I'll file another bug on these problems.
Re comment #69: trying to drag the xul:thumb beyond its limits inside the
scrollbar causes the onscroll event to be fired, even outside the area occupied
by the whole browser application. Loading a document fires the onscroll event 6
to 10 times: MSIE 6 does not do that.

Comment 74

15 years ago
I am experiencing the same problem described in comment #70. Basically, what is
happening is the onscroll event is being fired prior to the page offsets being
updated. I was able to workaround this by handling the scroll event in a
subsequent event (via setTimeout with a wait of 0). I am guessing the event
should probably fire with the new positions (like the way IE handles the event).

Comment 75

15 years ago
following the two testcases supplied by Ian in comment 66, I've verified on
Win2K 1.0.1 branch.

I don't know the implications of comment 73 or 74.  If necessary, pls reopen
this bug or file a new one.
Keywords: fixed1.0.1 → verified1.0.1

Comment 76

15 years ago
I'm asking that this bug be reopened. When I scroll down/up a page thanks to
<CTRL>+End/Home, the xul:thumb moves down/up, the document is scrolled for sure
but no scroll event is fired as you can see with the demo cases
- http://www.hixie.ch/tests/adhoc/dom/level0/001.html
- attachment 90436 [details] 

Comment 77

15 years ago
Speaking of the devil, it seems that all key (arrows, PgUp/Dn) causing a
document view to scroll do not fire the scroll event.

XP Pro SP1, using 2002101015

Comment 78

15 years ago
I don't get any scroll events for scrolls caused by the mouse weel either.
Is this a regression? I think page-up/down and mouse scroll worked when the fix
was checked in. 
*** Bug 175301 has been marked as a duplicate of this bug. ***
I'm reopening this bug (also from the comments in this bug), I duped a bug to
this, where this behaviour was descriped. Information from this:
"When the document is scrolled with the mouse wheel or the keyboard, the onscroll
event for the body element does not fire as it does when the document is
scrolled using mouse dragging the scrollbar."

I also now added another testcase from the duped bug, that doesn't generate so
much error-boxes, it only shows some message in the left corner of the
browser-window (when a OnScroll-Event is fired)(it shows a div-element) for 2
seconds and then it disappears again.
Has also anyone a idea, when this stopped working, Comment 79 says it first
worked after the ckeckin of the patch (testing some older versions of Mozilla,
looking for checkins that could be releated to this)?   
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Created attachment 103366 [details]
Another testcase without annoying JS alerts :-)
Also the Target Milestone has now to be changed...
Keywords: testcase
.
Target Milestone: mozilla1.0.1 → ---

Comment 85

15 years ago
I wonder if this is at the root of why the mouse pointer to the hand doesn't
update when you scroll and stop over a link.  See bug 78765 and bug 98114.
hm, bug 78765 could have something to do with this bug, at bug 98114 i'm not
really sure, because that bug is over mouseover-state.
Ths is only some guess from me (i'm not a good programmer at c++ and not
familiar with Mozilla-Code), but look at this:
In http://lxr.mozilla.org/seamonkey/source/widget/src/gtk/nsWindow.cpp#2513
(where with normal scrolling with cursor keys, mousewheel no event seems to be
fired)
there is only some
2513 PRBool nsWindow::OnScroll(nsScrollbarEvent &aEvent, PRUint32 cPos)
2514 {
2515   return PR_FALSE;
2516 }

but at
http://lxr.mozilla.org/seamonkey/source/widget/src/gtk/nsScrollbar.cpp#344 (this
is the scrollbar where the onscroll-event seems to be fired) there seems to be a
fully impleantatation:
339 //-------------------------------------------------------------------------
340 //
341 // Deal with scrollbar messages (actually implemented only in nsScrollbar)
342 //
343 //-------------------------------------------------------------------------
344 PRBool nsScrollbar::OnScroll (nsScrollbarEvent & aEvent, PRUint32 cPos)
345 {
346   PRBool result = PR_TRUE;
347   float newPosition;
    [....]

Can some people who understand the Mozillacode say something to my guess?
Ok, when i'm seeing this right in
http://lxr.mozilla.org/seamonkey/source/layout/html/base/src/nsGfxScrollFrame.cpp#992
there gets a NS_SCROLLBAR_EVENT fired.
(Assignee)

Comment 89

15 years ago
Dean: no, that's because I don't fire a mouse enter event after a mousewheel
scroll finishes.

Comment 90

15 years ago
Marking this as topembed+ per EDT triage, and reassigning to bryner.

does anyone know, if this is happening on the 1.0 branch, as well. if so, pls
remove the "verified1.0.1" keyword.
Assignee: radha → bryner
Status: REOPENED → NEW
Keywords: adt1.0.1-, topembed- → adt1.0.1+, topembed+

Comment 91

15 years ago
I checked attachment 90436 [details] with Mozilla 1.0.2 build 2002111006 under Windows XP
Pro SP1 and every navigational keys (4 arrows, home, end, PgUp, PgDn, Ctrl+Home,
Ctrl+End) were firing the scroll events. The mousewheel also was firing the
scroll event.
Clicking on xul:scroll and xul:slider also fired the scroll event.
(Assignee)

Comment 92

15 years ago
The onscroll event does fire, on a current trunk build (Linux).  However, there
seems to be another problem with the original testcase where after dismissing
the alert, it scrolls again, bringing up the alert again, etc. until it hits the
bottom of the page or the div.  Not good.

I'll go ahead and use this bug for a patch for this problem, since it already
has a testcase attached.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.3beta
(Assignee)

Comment 93

15 years ago
On second thought, that seems to be a more general problem with the scrollbar
repeat timer continuing to fire if the scroll caused an alert (the scrollbar
button never sees the mouseup, so it continues to fire the scroll timer).

Marking this bug FIXED since the onscroll event is working properly.
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago15 years ago
Resolution: --- → FIXED
Ok, that doesn't seem to work for some people, see Bug 189308

Comment 95

11 years ago
If this is working can someone update
http://www.mozilla.org/docs/dom/mozilla/bug-events.html

Comment 96

11 years ago
http://www.mozilla.org/docs/dom/mozilla/bug-events.html

has been updated.
 

Comment 97

11 years ago
Attaching an event to onscroll of document.documentElement prevents
the window onscroll event to fire: 

i.e.

Add the following to the test case (line #157): 

if(window.addEventListener) {
	document.documentElement.addEventListener("onscroll", function() {}, false);
	window.addEventListener("DOMMouseScroll", MouseWheelRollingDetected, false);
	window.addEventListener("scroll", ScrollingDetected, false);
	window.addEventListener("mousemove", MouseMoves, true);
	}
else if(document.addEventListener) // Opera 7+

Comment 98

11 years ago
> Attaching an event to onscroll of document.documentElement prevents
> the window onscroll event to fire: 

> if(window.addEventListener) {
>         document.documentElement.addEventListener("onscroll", function() {},
> false);

1- Your function body is empty, so the function does nothing
2- Your syntax is wrong: the first parameter has to be an event type, so it has to be "scroll" and not "onscroll"

Comment 99

11 years ago
(In reply to comment #98)
> > Attaching an event to onscroll of document.documentElement prevents
> > the window onscroll event to fire: 
> 
> > if(window.addEventListener) {
> >         document.documentElement.addEventListener("onscroll", function() {},
> > false);
> 
> 1- Your function body is empty, so the function does nothing
> 2- Your syntax is wrong: the first parameter has to be an event type, so it has
> to be "scroll" and not "onscroll"
> 


That's right the function does nothing but the point is that: 

document.documentElement.addEventListener("scroll", function() { }, false);
window.addEventListener("scroll", ScrollingDetected, false);

The function ScrollingDetected *does not* get called. This works correctly on IE 6+ and Opera 8, have not tested other browsers.

Of course just: 

window.addEventListener("scroll", ScrollingDetected, false);

works fine. 

Comment 100

11 years ago
Created attachment 248949 [details]
Small modification to test case to show how window onscroll event gets broken
The event targets the document and is supposed to bubble to the window. I'm not sure why that wouldn't be happening here.

Comment 102

11 years ago
> document.documentElement.addEventListener("scroll", function() { }, false);

If you want the documentElement to fire scroll events, then it has to have scrollbars for itself too.

> window.addEventListener("scroll", ScrollingDetected, false);
 
> The function ScrollingDetected *does not* get called. 

When I try attachment 248949 [details] with either Seamonkey 1.5a rv:1.9a1 build 2006121609 or Firefox 2 rv:1.8.1 build 20061010 under XP Pro SP2, ScrollingDetected gets called.

Comment 103

11 years ago
Ok maybe it's been fixed in HEAD?

I encountered the problem using: 

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.8) Gecko/20061025 Firefox/2.0

The problem also reproduces on 1.5.0.9 and 1.5.0.8, I'll wait for the next 2.0 release and see if that fixes it. 

Comment 104

10 years ago
This doesn't seem to work for textarea. Is this by design?

<HTML>
<BODY>
<TEXTAREA Name="comments" rows="4" cols="20" STYLE="overflow: auto;
            width: 200px;
            height: 200px;
            background-color: orange;" ONSCROLL="alert(this.id + ' ' + event.type);"></TEXTAREA>

<textarea 
     
>
</textarea>
      
</BODY>
</HTML>
(In reply to comment #104)
> This doesn't seem to work for textarea. Is this by design?

fixed on trunk.

You need to log in before you can comment on or make changes to this bug.