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)
Core
DOM: CSS Object Model
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)
579 bytes,
text/html
|
Details | |
4.04 KB,
patch
|
jst
:
review+
kinmoz
:
superreview+
jud
:
approval+
|
Details | Diff | Splinter Review |
7.28 KB,
text/html
|
Details | |
1.17 KB,
text/html
|
Details | |
16.70 KB,
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.
Reporter | ||
Comment 1•24 years ago
|
||
Comment 3•24 years ago
|
||
I'm really down with this bug getting fixed. onscroll is mighty useful. Ok that's my 2 cents ;)
Comment 4•24 years ago
|
||
Adding [DOM] prefix to bugs related to DOM Level 0, 1, or 2 compatibility/compliance.
Status: NEW → ASSIGNED
Updated•24 years ago
|
Summary: window.onscroll and element.onscroll don't fire → [DOM] window.onscroll and element.onscroll don't fire
Comment 5•24 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. ***
Updated•23 years ago
|
Component: DOM Level 2 → DOM Style
Comment 8•23 years ago
|
||
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)?
Comment 10•23 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.
Comment 11•23 years ago
|
||
*** Bug 87251 has been marked as a duplicate of this bug. ***
Comment 12•23 years ago
|
||
*** Bug 99919 has been marked as a duplicate of this bug. ***
Comment 13•23 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•23 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
Comment 15•23 years ago
|
||
Looks like this won't make it in for 0.9.6.
Comment 16•23 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•23 years ago
|
||
Note this bug is strongly related to 52599 and 62536.
Comment 18•23 years ago
|
||
Moving bugs from 0.9.7 for triaging in 0.9.8
Target Milestone: mozilla0.9.7 → mozilla0.9.8
Updated•23 years ago
|
Target Milestone: mozilla0.9.8 → mozilla0.9.9
Comment 19•22 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•22 years ago
|
||
->moz1.1 (dumping ground) per ADT triage
Target Milestone: mozilla0.9.9 → mozilla1.1
Comment 21•22 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•22 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?
Comment 23•22 years ago
|
||
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•22 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
Comment 25•22 years ago
|
||
Taking from joki, per my discussion with him.
Assignee: joki → radha
Status: ASSIGNED → NEW
Comment 26•22 years ago
|
||
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().
Comment 27•22 years ago
|
||
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.
Comment 28•22 years ago
|
||
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•22 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•22 years ago
|
||
Comment #27 might be related to bug #112294
Comment 31•22 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?
Comment 32•22 years ago
|
||
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
Comment 33•22 years ago
|
||
Attachment #75644 -
Attachment is obsolete: true
Comment 34•22 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•22 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•22 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•22 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•22 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•22 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.
Comment 40•22 years ago
|
||
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?
Comment 41•22 years ago
|
||
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•22 years ago
|
||
Hi, when approximately that fix will be available in build? Regards.
Comment 43•22 years ago
|
||
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•22 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•22 years ago
|
||
Since this is a [DOM] standards bug, shouldn't it be fixed asap? 1.0 is comming up...
Comment 46•22 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•22 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
Comment 48•22 years ago
|
||
This will unfortunately not make it into Mozilla 1.0 :-( Let's hope it makes it into Mozilla 1.0.1.
Updated•22 years ago
|
Target Milestone: mozilla1.0 → mozilla1.0.1
Comment 49•22 years ago
|
||
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
Comment 50•22 years ago
|
||
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 51•22 years ago
|
||
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•22 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.
Updated•22 years ago
|
Attachment #85505 -
Flags: review+
Comment 53•22 years ago
|
||
Fixed in the trunk.
Comment 54•22 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 → ---
Comment 55•22 years ago
|
||
This is also cause bug 152859
Comment 56•22 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]
Comment 57•22 years ago
|
||
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•22 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•22 years ago
|
Attachment #88380 -
Flags: review+
Comment 59•22 years ago
|
||
Comment on attachment 88380 [details] [diff] [review] Well-behaving patch r=jst
Comment 60•22 years ago
|
||
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 ago → 22 years ago
Resolution: --- → FIXED
Comment 61•22 years ago
|
||
I have also been offerd money in private email for fixing this bug... Web developers really want this fix.
Comment 62•22 years ago
|
||
ian/paw - can we get someone to verify this one on the trunk? thanks!
Comment 63•22 years ago
|
||
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.
Comment 64•22 years ago
|
||
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.
Comment 65•22 years ago
|
||
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).
Comment 66•22 years ago
|
||
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 68•22 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•22 years ago
|
Attachment #88380 -
Flags: approval+
Updated•22 years ago
|
Comment 69•22 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•22 years ago
|
||
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
Comment 71•22 years ago
|
||
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•22 years ago
|
||
Filed bug 156312 to address comment 69.
Comment 73•22 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•22 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•22 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•22 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•22 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•22 years ago
|
||
I don't get any scroll events for scrolls caused by the mouse weel either.
Comment 79•22 years ago
|
||
Is this a regression? I think page-up/down and mouse scroll worked when the fix was checked in.
Comment 80•22 years ago
|
||
*** Bug 175301 has been marked as a duplicate of this bug. ***
Comment 81•22 years ago
|
||
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 → ---
Comment 82•22 years ago
|
||
Comment 85•22 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.
Comment 86•22 years ago
|
||
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.
Comment 87•22 years ago
|
||
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?
Comment 88•22 years ago
|
||
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•22 years ago
|
||
Dean: no, that's because I don't fire a mouse enter event after a mousewheel scroll finishes.
Comment 90•22 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.
Comment 91•22 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•22 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•22 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
Closed: 22 years ago → 22 years ago
Resolution: --- → FIXED
Comment 94•22 years ago
|
||
Ok, that doesn't seem to work for some people, see Bug 189308
Comment 95•18 years ago
|
||
If this is working can someone update http://www.mozilla.org/docs/dom/mozilla/bug-events.html
Comment 96•18 years ago
|
||
http://www.mozilla.org/docs/dom/mozilla/bug-events.html has been updated.
Comment 97•18 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•18 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•18 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•18 years ago
|
||
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•18 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•18 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•17 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>
Comment 105•17 years ago
|
||
(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.
Description
•