280955 - Resize events should happen for all elements, not just the page

Status: RESOLVED DUPLICATE of bug 227495

(Core :: Layout, defect)

Description

[Mike Kaply [:mkaply]]

Conversation with roc. See the last line.

> 4.  No DOMAttrModified event fired when an element resizes.  Equally,
> no resize event is fired. 
> 
> IE's implemenation is wrong for DOMAttrModified. The reason is that
> you have the size as a percentage and the actual attribute text does
> not change. Regarding the resized event, which elements are you
> looking for a resize event from? The team will open a bug and look
> into the problem in January. 
> 
> Well IE may be "wrong" but it works just fine and dandy for us.  The
> most common case where we have to deal with is when an element has a
> percentage-based size (or a percentage-based position) and the user
> resizes the window. We need to relayout stuff on the page (e.g., the
> little hinky buttons shown in example #1 above).  In IE, each object
> that resizes gets a resize event.  In Mozilla, only the window gets
> one.  So we have to walk through the entire page and resize each
> object that MIGHT resize (we don't seem to have any way of getting the
> effective/computed style for an object that will tell us that an
> element has a percentage based width so we redo all elements on the
> page). We have Mozilla working, but it's noticeably slower than IE (by
> many many seconds).

Per-element resize events could be implemented, but currently aren't. I
can't think of a good workaround. Most people rely on the browser itself
to do layout.

> There's also a difference (due to the underlying OS, doubt that this
> can work cross-platform) in that IE spits out resize events during the
> resize (if preferences are set up to do this) while Mozilla only spits
> out a resize event once (when the user stops resizing).  As a result
> we can make the page relayouts flow a lot more nicely in IE.

That could be fixed if they filed a bug. bryner could fix it, for
example.

Comment 1

[Hixie (not reading bugmail)]

Wouldn't firing an event on an element every time it's display dimensions change
be somewhat _insanely_ bad for our performance?

Comment 2

[Mike Kaply [:mkaply]]

some info from dbaron on this:

> 4.  No DOMAttrModified event fired when an element resizes.  Equally, no 
> resize event is fired.
> 
> For example, if a field has a width that is a percentage of the window 
> width (directly or indirectly).  Resize the window.  The DOM attribute's 
> value is changed.  But no event is fired.  IE fires the event (because the 
> attribute has been modified).  Equally, IE sends the field an onresize 
> event.
> 
> Why this is a problem -- we need to know when an element's size changes 
> (so we can re-arrange things like a "helper" button that's attached to 
> it).  In IE this is trivial.  In Mozilla, we have to track the window's 
> size changing and force a "relayout" of the page everytime the window 
> changes size (even if we don't need to do this).  It's a big performance 
> issue.

Firing a DOMAttrModified event is incorrect since the textual value of
the attribute has not changed.
http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-eventgroupings-mutationevents

It's not clear to me from the DOM 2 spec on what elements onresize
should fire.  If we're incompatible with other browsers it's worth
filing a bug.  It might be a bit of a pain to implement.
http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-eventgroupings-htmlevents

Comment 3

[Mike Kaply [:mkaply]]

more from dbaron:

Actually, I think the way to implement it would be to have a data
structure that stores all the elements with resize handlers and their
sizes, and to go through it after the reflow queue is emptied (on the
primary pres shell) and fire events on any whose size have changed.  So
it wouldn't be that hard.

Comment 4

[Hixie (not reading bugmail)]

That wouldn't work because you can have capture event listeners (and bubbling 
event listeners, since "resize" bubbles).

Comment 5

[Nickolay_Ponomarev]

dupe of bug 227495?

Comment 6

[Boris Zbarsky [:bzbarsky]]

*** This bug has been marked as a duplicate of 227495 ***