Closed Bug 35011 Opened 24 years ago Closed 22 years ago

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

Categories

(Core :: DOM: CSS Object Model, defect, P1)

defect

Tracking

()

RESOLVED FIXED
mozilla1.3beta

People

(Reporter: martin.honnen, Assigned: bryner)

References

Details

(Keywords: dom2, testcase, topembed+, Whiteboard: [adt3 RTM])

Attachments

(5 files, 5 obsolete files)

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.
Tom, wanna have a look at this?
Assignee: jst → joki
I'm really down with this bug getting fixed. onscroll is mighty useful.  Ok 
that's my 2 cents ;)
Adding [DOM] prefix to bugs related to DOM Level 0, 1, or 2 
compatibility/compliance.
Status: NEW → ASSIGNED
Summary: window.onscroll and element.onscroll don't fire → [DOM] window.onscroll and element.onscroll don't fire
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. ***
*** Bug 62332 has been marked as a duplicate of this bug. ***
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
does this bug have any relation to bug 52599 (<xul:srollbar>s should generate
onscroll events)?
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. ***
*** Bug 99919 has been marked as a duplicate of this bug. ***
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?
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.
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
Note this bug is strongly related to 52599 and 62536.
Moving bugs from 0.9.7 for triaging in 0.9.8
Target Milestone: mozilla0.9.7 → mozilla0.9.8
Target Milestone: mozilla0.9.8 → mozilla0.9.9
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
->moz1.1 (dumping ground) per ADT triage
Target Milestone: mozilla0.9.9 → mozilla1.1
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.
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 → ---
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
Keywords: topembed
Taking from joki, per my discussion with him. 
Assignee: joki → radha
Status: ASSIGNED → NEW
Attached patch Initial patch v 1.0 (obsolete) — Splinter Review
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().
Attached patch Initial patch v 1.0 (obsolete) — Splinter Review
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...
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 #27 might be related to bug #112294
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: topembedtopembed-
Attached patch Patch v1.1 (obsolete) — Splinter Review
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
Attached patch Cleaned up patch. (obsolete) — Splinter Review
Attachment #75644 - Attachment is obsolete: true
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|?
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 :-)
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.
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. 
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.
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
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.
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.
Since this is a [DOM] standards bug, shouldn't it be fixed asap?
1.0 is comming up...
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?
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
Attached patch Yet another patch (obsolete) — Splinter Review
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+
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.
Fixed in the trunk. 
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Keywords: adt1.0.1
Resolution: --- → FIXED
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
Depends on: 152810
what benefit would be derived by a user if this was checked in? are any top
sites using this fuction?
Whiteboard: [adt3 RTM]
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 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+
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
Closed: 22 years ago22 years ago
Resolution: --- → FIXED
I have also been offerd money in private email for fixing this bug... Web
developers really want this fix.
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
marking adt1.0.1- per ADT.
Keywords: adt1.0.1adt1.0.1-
please checkin to the 1.0.1 branch. once there, remove the "mozilla1.0.1+"
keyword and add the "fixed1.0.1" keyword.
Attachment #88380 - Flags: approval+
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.
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?
Filed bug 156312 to address comment 69.
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.
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).
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.
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] 
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
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 → ---
Also the Target Milestone has now to be changed...
Keywords: testcase
.
Target Milestone: mozilla1.0.1 → ---
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.
Dean: no, that's because I don't fire a mouse enter event after a mousewheel
scroll finishes.
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
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.
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
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
Closed: 22 years ago22 years ago
Resolution: --- → FIXED
Ok, that doesn't seem to work for some people, see Bug 189308
If this is working can someone update
http://www.mozilla.org/docs/dom/mozilla/bug-events.html
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+
> 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"
(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. 
The event targets the document and is supposed to bubble to the window. I'm not sure why that wouldn't be happening here.
> 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.
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. 
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.

Attachment

General

Creator:
Created:
Updated:
Size: