Last Comment Bug 227495 - [RFE] Elements should fire resize events
: [RFE] Elements should fire resize events
Status: NEW
: testcase
Product: Core
Classification: Components
Component: DOM: Events (show other bugs)
: Trunk
: x86 Windows XP
: P5 enhancement with 12 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
:
Mentors:
: 233500 280955 338530 705064 737040 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2003-12-04 11:06 PST by Erik Arvidsson
Modified: 2016-09-07 02:32 PDT (History)
26 users (show)
dbaron: wanted1.9.2?
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Try resizing the window. The size of the green div should be shown in the window when resized (2.12 KB, text/html)
2003-12-04 11:12 PST, Erik Arvidsson
no flags Details
FF/IE onresize tester for font/window change (916 bytes, text/html)
2006-05-01 03:28 PDT, Csaba Gabor
no flags Details
FF / IE onresize tester for table-size change (1.44 KB, text/html)
2006-05-19 07:04 PDT, Terje Rosenlund
no flags Details

Description Erik Arvidsson 2003-12-04 11:06:57 PST
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.
Comment 1 Erik Arvidsson 2003-12-04 11:12:54 PST
Created attachment 136813 [details]
Try resizing the window. The size of the green div should be shown in the window when resized

Clicking on the outer div changes its size and therefore the inner one also
changes (percentage width)
Comment 2 Boris Zbarsky [:bz] (still a bit busy) 2003-12-04 11:20:30 PST
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?
Comment 3 Erik Arvidsson 2003-12-04 12:09:29 PST
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.
Comment 4 Erik Arvidsson 2003-12-04 12:14:16 PST
> 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?) 
Comment 5 Boris Zbarsky [:bz] (still a bit busy) 2003-12-04 15:02:50 PST
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...
Comment 6 Erik Arvidsson 2003-12-05 01:27:59 PST
> 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
Comment 7 Hixie (not reading bugmail) 2003-12-05 03:26:32 PST
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.)
Comment 8 Johnny Stenback (:jst, jst@mozilla.com) 2003-12-05 10:16:36 PST
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...
Comment 9 Brendan Eich [:brendan] 2003-12-05 10:20:20 PST
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
Comment 10 Johnny Stenback (:jst, jst@mozilla.com) 2003-12-05 11:11:30 PST
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.
Comment 11 Hixie (not reading bugmail) 2003-12-06 09:39:20 PST
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). 
Comment 12 Johnny Stenback (:jst, jst@mozilla.com) 2003-12-06 13:15:08 PST
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...
Comment 13 Erik Arvidsson 2003-12-06 13:28:11 PST
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 :-) )
Comment 14 Hixie (not reading bugmail) 2003-12-06 13:45:26 PST
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. :-)
Comment 15 Erik Arvidsson 2003-12-06 16:35:13 PST
...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).
Comment 16 Boris Zbarsky [:bz] (still a bit busy) 2004-02-09 11:43:13 PST
*** Bug 233500 has been marked as a duplicate of this bug. ***
Comment 17 Matthijs Wensveen 2005-04-20 03:38:56 PDT
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!
Comment 18 Boris Zbarsky [:bz] (still a bit busy) 2005-04-20 08:20:40 PDT
There is no superclass for Window, and David Hyatt isn't going to be fixing any
Mozilla bugs anytime soon.
Comment 19 Boris Zbarsky [:bz] (still a bit busy) 2005-11-29 09:36:31 PST
*** Bug 280955 has been marked as a duplicate of this bug. ***
Comment 20 Csaba Gabor 2006-05-01 03:28:02 PDT
Created attachment 220381 [details]
FF/IE onresize tester for font/window change

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
Comment 21 David Baron :dbaron: ⌚️UTC-7 (busy September 14-25) 2006-05-01 03:34:37 PDT
(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.
Comment 22 Erik Fabert 2006-05-19 05:03:38 PDT
*** Bug 338530 has been marked as a duplicate of this bug. ***
Comment 23 Terje Rosenlund 2006-05-19 07:04:02 PDT
Created attachment 222619 [details]
FF / IE onresize tester for table-size change

>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.
Comment 24 robinpelgrim 2007-12-05 00:21:45 PST
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.

Comment 25 Boris Zbarsky [:bz] (still a bit busy) 2007-12-05 08:40:27 PST
Feature freeze for Fx3 was a few months ago.
Comment 26 robinpelgrim 2007-12-05 10:07:07 PST
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...
Comment 27 William J. Edney 2009-03-30 15:10:12 PDT
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
Comment 28 David Baron :dbaron: ⌚️UTC-7 (busy September 14-25) 2009-03-30 15:17:22 PDT
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.
Comment 29 William J. Edney 2009-03-30 15:30:03 PDT
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
Comment 30 Boris Zbarsky [:bz] (still a bit busy) 2009-03-30 16:20:26 PDT
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.
Comment 31 David Baron :dbaron: ⌚️UTC-7 (busy September 14-25) 2010-02-02 14:10:56 PST
http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#event-type-resize has a spec for this; it's not clear how well it matches IE.
Comment 32 John P Baker 2011-11-24 02:53:13 PST
*** Bug 705064 has been marked as a duplicate of this bug. ***
Comment 33 Chris Lord [:cwiiis] 2012-03-19 11:47:10 PDT
*** Bug 737040 has been marked as a duplicate of this bug. ***
Comment 34 David Baron :dbaron: ⌚️UTC-7 (busy September 14-25) 2013-05-29 08:48:58 PDT
(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).
Comment 35 David Baron :dbaron: ⌚️UTC-7 (busy September 14-25) 2016-05-12 09:46:21 PDT
So apparently IE only did this for elements that hasLayout.

But the new plan for this use case is bug 1272409.

Note You need to log in before you can comment on or make changes to this bug.