17969 2008-03-20 11:35:04 -0700 Element onresize does not work 2022-07-21 17:01:57 -0700 1 1 1 Unclassified WebKit DOM 528+ (Nightly build) PC OS X 10.5 RESOLVED WONTFIX HasReduction P2 Normal --- 1 erik.arvidsson webkit-unassigned ahmad.saleem792 ap arv bedney bfulgham lea rniwa webkit oldest_to_newest 74537 0 erik.arvidsson 2008-03-20 11:35:04 -0700 When an element is resize (for whatever reason) it should fire a resize event. This event is very important for creating reusable UI components that need to do js layout logic. IE has had this event since version 4. Test case coming up 74538 1 19900 erik.arvidsson 2008-03-20 11:36:19 -0700 Created attachment 19900 Resize the window to trigger the resize event 74545 2 eric 2008-03-20 12:04:37 -0700 FF3 fails the attached test case. Which means unless someone is going through the painful process of trying to right a "next gen" web application in IE7, I don't think they'll be using this event. :) 115905 3 bedney 2009-03-30 15:06:47 -0700 Yes and Erik, to his credit, filed this bug there too... back in 2003... https://bugzilla.mozilla.org/show_bug.cgi?id=227495 My mom taught me that two wrongs don't make a right :-). Seriously, this capability (the ability to observe size changes at an element level - i.e. as various CSS rules come into and go out of effect), is crucial to doing web-based UI components without resorting to 'JS monitors'. At minimum, this bug shouldn't be left as 'unconfirmed' when it clearly has been confirmed. Cheers, - Bill 115907 4 eric 2009-03-30 15:12:50 -0700 We don't follow bugzilla's arbitrary conventions very closely here in WebKit land. :) In order to fix this, we need to know *what* onresize is supposed to do? When should it fire? Synchronously with the resize? After all resizes have happened? Does it bubble? I assume that addEventListener("resize") is supposed to work too. Someone effectively needs to write a little mini spec, and associated test cases, if we're going to be able to fix this. Until we know what exact behavior we're supposed to add, it's hard to write the code. :) 115913 5 bedney 2009-03-30 15:27:06 -0700 Eric - Thanks for the quick reply! A comment from the Mozilla bug report states that the 'resize' event is documented in the DOM Level 3 events spec. And so it is: http://www.w3.org/TR/DOM-Level-3-Events/events.html#event-resize Looks like its not cancelable, it bubbles and can be targeted at a Document or Element. Since its a DOM event, I would assume that the 'addEventListener("resize", ..., ...)' syntax should work. In so far as how it actually gets fired, that's not specified. As a JS programmer who's not a C/Webkit guy ;-), I guess it would depend on how the Webkit engine is structured. I know that sitting on my side of the fence, my expectation would be that all 'resize' events get queued until the reflow is complete. But then my handlers would be invoked before painting/blitting such that I can resize other elements thereby recursing back into the engine . That is a totally WAG (wide a**ed guess and others with *much* more experience than I may want to chime in here... hint hint :-) ). Of course, the potential exists here for folks in my world (JS) to write handlers that then try to resize the target element that just got resized, thereby setting up an infinite loop... but then again, that's their problem. If you feel like you need more detail, I'd be willing to write some tests here to 'document' IE's current behavior and let that drive a mini-spec of some sort. Maybe Arv has some more to add here. Cheers, - Bill 115917 6 eric 2009-03-30 15:37:21 -0700 Interesting, I did not realize there was any spec-work around a resize event. The spec sure doesn't have much to say about it. :) But it does look like something that we could consider supporting. Every RenderObject::layout() implementation would have to notify the document that a resize of the corresponding node had occurred. A list would be kept by the Document, and then from that list, events would be dispatched after the layout() had occurred. One question would be what the behavior of the list should be if a resize is triggered during a resize js handler (set some size property and then trigger a layout). I assume it should be a FIFO queue and that the remaining resize events from the previous resize should be fired before the new ones are. But maybe the queue should just be cleared on any new layout? Either way, it looks like even though there is some minor specwork, there is no testing, or exploration of the various edge conditions. ;) Something any implementor would have to explore. 116134 7 erik.arvidsson 2009-03-31 20:45:50 -0700 I'm pretty sure that resize events do not bubble in IE. I'm willing to write a mini design doc for this that covers how IE works. I think it is important to make sure that we can minimize the work needed to do this. For example, it might make more sense to fire the event when we know that the element will change size but before we complete the reflow so that we do not do unnecessary reflows if the size changes due to the event handler. 524435 8 lea 2011-12-19 21:55:12 -0800 What's the progress of this bug? If I'm interpreting the DOM3 Events spec correctly, it should also fire on every element, when resized by the user due to the CSS resize property. It doesn't. Testcase: http://dabblet.com/result/gist/1498895 1885861 9 ahmad.saleem792 2022-07-21 16:02:33 -0700 I think it was only present in the IE and all other browser now moved to - Resize Observer API - https://github.com/WICG/resize-observer & https://www.w3.org/TR/resize-observer/ Attached test case and test case from Comment 08 does not work in Safari 15.6, Chrome Canary 105 and Firefox Nightly 104. I think this can be closed, if I am not mistaken. Please ignore my comment, if I am wrong. Thanks! 1885874 10 rniwa 2022-07-21 17:01:57 -0700 Yeah, this is won't fix. Use ResizeObserver instead. 19900 2008-03-20 11:36:19 -0700 2008-03-20 11:36:19 -0700 Resize the window to trigger the resize event onresize.html text/html 428 erik.arvidsson PCFET0NUWVBFIGh0bWw+CjxodG1sPgo8aGVhZD4KPHRpdGxlPk9ucmVzaXplIHRlc3Q8L3RpdGxl Pgo8c3R5bGU+CgojdGVzdCB7CiAgcG9zaXRpb246IGFic29sdXRlOwogIHdpZHRoOiA1MCU7CiAg aGVpZ2h0OiA1MCU7CiAgYmFja2dyb3VuZC1jb2xvcjogI2RkZDsKfQoKPC9zdHlsZT4KPHNjcmlw dD4KCndpbmRvdy5vbmxvYWQgPSBmdW5jdGlvbigpIHsKICB2YXIgZWwgPSBkb2N1bWVudC5nZXRF bGVtZW50QnlJZCgndGVzdCcpOwogIGVsLm9ucmVzaXplID0gZnVuY3Rpb24oKSB7CiAgICBlbC5p bm5lckhUTUwgPSBlbC5vZmZzZXRXaWR0aCArICd4JyArIGVsLm9mZnNldEhlaWdodDsKICB9Owp9 Cgo8L3NjcmlwdD4KPC9oZWFkPgo8Ym9keT4KCjxkaXYgaWQ9dGVzdD5ObyByZXNpemUgZXZlbnRz IHlldC48L2Rpdj4KCjwvYm9keT4KPC9odG1sPgo=