[Webkit-unassigned] [Bug 17969] Element onresize does not work

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Mar 30 15:27:06 PDT 2009


https://bugs.webkit.org/show_bug.cgi?id=17969





------- Comment #5 from bedney at technicalpursuit.com  2009-03-30 15:27 PDT -------
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


-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.



More information about the webkit-unassigned mailing list