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)
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)
(deleted),
text/html
|
Details | |
(deleted),
patch
|
jst
:
review+
kinmoz
:
superreview+
jud
:
approval+
|
Details | Diff | Splinter Review |
(deleted),
text/html
|
Details | |
(deleted),
text/html
|
Details | |
(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.
Reporter | ||
Comment 1•25 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•24 years ago
|
Component: DOM Level 2 → DOM Style
Comment 8•24 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•23 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•23 years ago
|
||
->moz1.1 (dumping ground) per ADT triage
Target Milestone: mozilla0.9.9 → mozilla1.1
Comment 21•23 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•23 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•23 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•23 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•23 years ago
|
||
Taking from joki, per my discussion with him.
Assignee: joki → radha
Status: ASSIGNED → NEW
Comment 26•23 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•23 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•23 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•23 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•23 years ago
|
||
Comment #27 might be related to bug #112294
Comment 31•23 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•23 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•23 years ago
|
||
Attachment #75644 -
Attachment is obsolete: true
Comment 34•23 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•23 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•23 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•23 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•23 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•23 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•23 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•23 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•23 years ago
|
||
Hi, when approximately that fix will be available in build?
Regards.
Comment 43•23 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
|
||
Comment 86•22 years ago
|
||
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•18 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•18 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
•