Closed Bug 35011 Opened 25 years ago Closed 22 years ago

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

Categories

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

Product:
Core
Component:
DOM: CSS Object Model
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.3beta

People

(Reporter: martin.honnen, Assigned: bryner)

References

Details

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

Attachments

(5 files, 5 obsolete files)

bug demo (scroll the page or the div and an alert should occur)
(deleted), text/html
Details
Well-behaving patch
(deleted), patch
jst
: review+
kinmoz
: superreview+
jud
: approval+
Details | Diff | Splinter Review
Problems with updating pageX/YOffset values in case xul:scroll and xul:slider are involved.
(deleted), text/html
Details
Another testcase without annoying JS alerts :-)
(deleted), text/html
Details
Small modification to test case to show how window onscroll event gets broken
(deleted), text/html
Details
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) (deleted) — — 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) (deleted) — — 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: topembed → topembed-
Attached patch Patch v1.1 (obsolete) (deleted) — — 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) (deleted) — — 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) (deleted) — — 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: 23 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]
Attached patch Well-behaving patch (deleted) — — Splinter Review
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: 23 years ago → 23 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.1 → adt1.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.
Keywords: mozilla1.0 → mozilla1.0.1+
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.
Keywords: fixed1.0.1 → verified1.0.1
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
Keywords: adt1.0.1-, topembed- → adt1.0.1+, topembed+
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: 23 years ago → 22 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: