Open Bug 227495 Opened 21 years ago Updated 3 months ago

[RFE] Elements should fire resize events

Categories

(Core :: DOM: Events, enhancement, P5)

Product:
Core
Component:
DOM: Events
Platform:
x86
Windows XP
Type:
enhancement

Tracking

()

People

(Reporter: erik, Unassigned)

References

Details

(Keywords: testcase)

Attachments

(3 files)

Try resizing the window. The size of the green div should be shown in the window when resized
2.12 KB, text/html
Details
FF/IE onresize tester for font/window change
916 bytes, text/html
Details
FF / IE onresize tester for table-size change
1.44 KB, text/html
Details 
When an element is resized it should fire a resize event.

There is a similar bug targetting XUL elements (bug 115664)

Internet Explorer has this event and it is crucial for creating components where
script is needed to do the layout.
Clicking on the outer div changes its size and therefore the inner one also
changes (percentage width)
This will make pageload ridiculously slow... (the event will fire thousands if
not millions of times during pageload).  Does IE fire the event then?  If not,
why not?  Does this event bubble?  Does it capture?
The event does not bubble in IE. The DOM level 2 says that the resize event for
the document should bubble (like it could bubble anywhere).
http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-eventgroupings-htmlevents

IE does not support capturing.

The resize events are not fired until the entire document is loaded (including
images). In IE terms the resize events are not fired until document.readyState
reaches complete.
> The DOM level 2 says that the resize event for
> the document should bubble (like it could bubble anywhere).

That was a bit missleading. The DOM specs says that the resize event is fired
when the document view is resized. It does not specify on what Node this should
be dispatched.

As for the reasoning why IE does not fire the resize events during load I don't
know. Maybe they did it in this way just to improve performance. Just like DOM
mutation events are not fired all the time when the document is constructed.
(When do you start firing these?) 
Mozilla _does_ fire mutation events as the document is being constructed, if
there is a listener for such events attached...

The resize event is not targeted at a Node at all -- it's targeted at an
EventListener.  That happens to be the Window object at the moment.

I suppose we could use a setup similar to mutation events to avoid firing these
in sane documents, though adding these all over the place in layout will be a
royal pain...
> The resize event is not targeted at a Node at all -- it's targeted at an
> EventListener.  That happens to be the Window object at the moment.

I know about the Window resize event. My point about that was the the DOM spec
specifies a resize event, and since Window is not part of the DOM spec, it is
not clear where this should be dispatched from.

> I suppose we could use a setup similar to mutation events to avoid firing
> these in sane documents, though adding these all over the place in layout
> will be a royal pain...

This would be really nice. Since this seems to be a bit of a hustle and
considering that the related XUL bug has not attracted too much attention I'll
set this to P5
Priority: -- → P5
Window _is_ part of the DOM spec, it's the defaultView member of the document 
object. (You have to just "know" this, there's no spec that says so explicitly 
yet as far as I know.)
No, not true. That's just how mozilla happens to implement it, there's nothing
in the DOM specs that says that's how it has to be...
jst: does any browser do otherwise?  De-facto standard better mean something
here, or else defaultView is not useful XP.  At least DOM level 0 is ;-).

/be
Not sure what Opera or Safari does, but IE has no defaultView property on its
events, so it's pretty much not XP due to that.

The intent of the DOM WG was not for defaultView to be a browser window object,
it was supposed to be a view from the "DOM Views and Formatting" spec (or
whatever it was supposed to be called) that never happened, an spec with
interfaces that described the display characterstics of DOM elements, down to
the character-to-pixel level etc.
Opera assumes document.defaultView == window. I've always figured it was the
only logical thing to do -- the window is the viewport, AbstractViews seem to
represent the viewport... seems to make sense to me to assume that windows are
views.

IE doesn't know anything about views, so of course IE doesn't assume that
defaultView is the window. :-) I tried testing Safari but it wouldn't execute my
script for some reason, so either probably doesn't know one of appendChild(),
createTextNode(), or defaultView (my guess would be the last one). 
I'm glad to see that Opera made the same decision here, even if it's not what
the DOM WG initially intended. Given that what the DOM WG had planned for views
& formatting stuff fell on the floor I don't see a better alternative than to
make defaultView be the window object, and maybe that should be formally stated,
or at least formally documented somewhere since I don't see anything better
coming out of the W3C for defaultView. And few (if any) non-browser DOM
implementations have any answer for defaultView, so...
Opera made document.defaultView map to Window just to be compatible with
Mozilla. Initially it only only had document.parentWindow (the IE property).

(Ian, you can probably see who reported that to your bug db :-) )
It's not really a question of document.defaultView being window in itself, it's
document.defaultView _being a view_, and the _view_ being window. Which is
indeed the case in Opera; you can tell because the window has getComputedStyle()
on the window object. From a standards perspective, document.defaultView being
the window means nothing if the window doesn't implement one of the View
interfaces. :-)
...anyway, whether defaultView should map to window is not what this bug is about.

Sorry for more spamming but I felt that the discussion has gotten out of hand
(and I know I'm partially to blame).
*** Bug 233500 has been marked as a duplicate of this bug. ***
Is there any progress on this? It would be really usefull to have, especially
when the user resizes its font with CTRL++ or CTRL+- and there are complex
layout scripts.

Wouldn't this be a matter of placing the onresize code that works for 'window'
in a superclass of window (node/element?), or am I thinking too OO here :)

BTW, the XUL bug 115664 is assigned to David Hyatt, maybe he can fix this in one
swoop!
There is no superclass for Window, and David Hyatt isn't going to be fixing any
Mozilla bugs anytime soon.
*** Bug 280955 has been marked as a duplicate of this bug. ***
IE 6 does not fire onresize when a font size change causes an element to resize.  This attachment is an FF/IE event listener for changes to the size of window, document, body, and the span containing some text.  The window size changing does fire a listener.

Also, I didn't understand Hixie's rebuttal in Bug 280955 Comment 4 as to why Machael Kaply's suggestion in the prior comment wouldn't work.

Csaba Gabor from Vienna
(In reply to comment #20)
> Also, I didn't understand Hixie's rebuttal in Bug 280955 Comment 4 as to why
> Machael Kaply's suggestion in the prior comment wouldn't work.

I think the counter-rebuttal is simply that resize events shouldn't bubble; the DOM spec says they do, but doesn't define any case in which they have anything to bubble to.
*** Bug 338530 has been marked as a duplicate of this bug. ***
>IE 6 does not fire onresize when a font size change causes an element to
>resize. 

IE does fire onresize when a window size change causes a table-element to resize: 

http://msdn.microsoft.com/library/default.asp?url=/workshop/author/dhtml/reference/events.asp

The onresize event fires for block and inline objects with layout, even if document or CSS (cascading style sheets) property values are changed. Objects have layout when measurements such as the height and width attributes are set, or when the position of the object is set.
Is something going to happen on this subject.

The latest (draft) specification (http://www.w3.org/TR/DOM-Level-3-Events/events.html) also defines an element as target for the resize event.

When building custom widgets that 'auto stretch' with the available content this event is needed!



Supporting this event on an element makes FireFox a better platform for building web applications! (At this point IE is more usefull)

In my opinion it should be there in FF3.


Feature freeze for Fx3 was a few months ago.
Hmmm, yes, thats true.

But still I think it should be there in FF3.

FF3 misses only a few key functionalities for building custom widgets for web applications. And this is one of them.
(I am afraid that 'onbeforedeactivate' (or equivalent) will not be there in FF3 since it's the only reliable way for control validation.)

Sometimes adding a feature causes less trouble than fixing a bug...

I guess I'll have to wait then...

Folks -

Firefox 3.0 has come and gone and Firefox 3.5 is almost upon us. Too late for that version as well, I would assume.

Being able to monitor element size via an event handler as the DOM changes is a critical part of building robust reusable GUI, as Erik pointed out 5 years ago.

Is there anything I can help with (testcases, etc.) that would help get a fix for this in the next release of Firefox?

Cheers,

- Bill
Is there a spec somewhere that says when elements must get resize events (and when they must not)?  (Does that spec match the behavior of other browsers that fire resize events targeted at elements?)

Testcases are useful as well, especially if they're in the format that we use in our regression tests (mochitests, in particular).  (Tests that aren't yet passing could be checked in to the tree if there's agreement that the tests are correct... perhaps because they pass in other browsers... since we can mark tests as 'todo', i.e., known to fail.)


I agree this is important and something we ought to be working on.
David -

I just got through making a comment over on the Webkit bug tracker, because they have the same problem :-).

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

The Webkit folks were asking basically the same question here: what's the spec?

Here was my reply (substitute the word "Gecko" for the word "Webkit") :-)

"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
I should note that in the compositor world the only times we'll reflow are preparatory to painting (without it being reasonable to fire an event between the reflow and the paint, imo) and when the page explicitly flushes layout.

But I think David's real question was in fact about IE's behavior; reverse-engineering that would be a good start on this.
Assignee: events → nobody
QA Contact: ian → events
No longer blocks: 696593
(In reply to Boris Zbarsky (:bz) from comment #5)
> I suppose we could use a setup similar to mutation events to avoid firing
> these
> in sane documents, though adding these all over the place in layout will be a
> royal pain...

I think we want a similar setup to mutation events for recording which frames have resize event handlers, but then the rest should be quite simple:

 * before any reflow, we just record all the sizes of the primary frames of the content nodes that have resize event listeners (perhaps even in the structures where we keep the list of which elements have such listeners), and then after that reflow we queue up the necessary resize events.

We probably also want to ensure that the dispatching is integrated nicely in the refresh driver tick handling so that code that runs during resize event handlers has its effects handled within the same refresh tick -- but we want to repeat things once but not more for the resize handling (so if resize handlers run the second time and change things, we just keep going).
So apparently IE only did this for elements that hasLayout.

But the new plan for this use case is bug 1272409.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: