Apparently we're copying NS4's behaviour here, where the event is only fired when the user stops moving the mouse. IE 6 fires this event continuously while the window is being resized, which is what I expected to happen. I'll attach a simple test case.

This should update a counter in the status bar while the window is being resized.

If we do this, all those pages that do "onresize = reload()" for any browser called "Netscape" will start to really suck... But yes, this seems like a good idea. :)

works as 4.x does.

Netscape 4.72 (build 20000207) and with Mozilla 1.0 RC1 (build 2002041711) fire continuously the onresize event while window is being resized. Things changed with Moz1.0 RC2 IIRC.

Sorry, I got mixed up with other tests I was conducting: the onresize event does not fire continuously on NS 4.72 and Moz1.0 RC1, unless you drag the window resizing border slowly. I agree with P. Annema that the onresize event should be fired continuously, just like IE.

*** Bug 155792 has been marked as a duplicate of this bug. ***

Opera 7 fires this event continuously while the window is being resized.

One solution would be to disable page reload in scripts run from the resize event. Maybe disable reload only while mousebutton is down and call it when released should allow any page relying on reload to continue to work and still not hamper pages that just think is a ns4 browser.

*** Bug 201002 has been marked as a duplicate of this bug. ***

On my Moz 1.3 (Gecko/20030312), the OnResize events fires (fairly) continuously as the browser is resized but **only on the first resize after the page was loaded**. Subsequently, it only fires once, when the resize grippy is dropped. If the page is reloaded, it will fire continuously again (for the first time only). Not nice.

.

This is old wayward behaviour. Is there any current plan for this to be fixed in the near term? It sounds like a state isn't being reinitialised.

Another solution could be to ad an property to window or document that could be set from javascript or css attribute to choose behaviour. That way, any old page depending on current behaviour whould not be broken but developers that want to have countinous resize could easily activate it for their site. I know I would like any solution to this problem.

The resize event is fired off of a 200 ms timer set by the reflow code, but the function that sets the timer (PresShell::CreateResizeEventTimer) clears any existing timer first. Therefore, the resize event isn't fired becuase the timers keep being cleared until the user pauses for 200+ ms or the resize operation ends. http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/base/nsPresShell.cpp&rev=3.926&mark=3124,3135,3137#3123 Rather than create a new timer, this patch means the existing timer is left alone so we get a resize event every 200 ms. I don't have time to pursue this if the patch isn't the "correct" way to fix this bug, but if someone else wants to take this patch further, feel free.

I don't understand why the resize isn't fired continuously like it is in Internet Explorer. That browser is able to handle it very quickly and smoothly; why can't Firefox? Does it really have to limit the resize to 5 times per second?

Guys, it's a TIME to fix it in upcoming Firefox 3. It's evidently easy-to-fix while at the same time very significant at Web 2.0 era with its advanced frames-like web interfaces where such bugs is quite annoying. It's already time to fix it, really. Thanks.

I greatly look forward to this bug being fixed as well - this has been a bug for over 5 years and still remains unfixed.

So to fully fix this we'd need rocs compositor stuff, which isn't going to happen for 1.9. However, we could make this a whole lot better by firing the timer more often, even if the user is still resizing the window. Leaving it up to the layout guys.

It looks like his bug will not be fixed with FF3? It is a shame, since every other browser out there does not behave this way, it makes FF look bad having code around from NN4 days.

I am realy sad to hear that this is not fixed yet. Could you at least consider the option to add an CSS property for body or an javascript property we can set to enable continuous reflow. I know that one reason not to fix it was because older pages that identified FF as NN4 triggered an reload when resizing but is this till a problem, and my suggested solution would keep these pages happy while still letting modern pages behave as expected with one minor fix that has the added benefit that once you change default behavior, modern pages does not have to be changed at all, they would just continue to function.

It seems to me that one has to go out of one's way to defer onresize in this way (such as adding a short timer to fire the event which gets reset each time the window size changes), so I suspect fixing this bug mainly entails removing a bunch of code. It's unfortunate it's not getting a lot of visibility with mozilla devs. Anyway, fixing this is bug is needed for parity with all the other modern browsers.

Okay, we have no passed the launch of FF3, and are barreling straight towards 3.1. Let's get this show on the road shall we? I'm a web dev, not a moz dev, and I have need for a fluidly resizing window. Badly. From reading the comments, this seems like a very easy problem to fix, despite the fact that the problem is very big for web devs, especially those looking to add some animation to their pages. So... how about it?

Why do you need this exactly? To adjust a website for when a window is resized? Perhaps you could use the new MozAfterPaint event for that? Although that is trunk only (not in Firefox 3.0).

Well, I write rich webapplications where I have a lot of script generated content. Some of it is positioned on top of the rest of the page but relative to existing elements. When the page is resized those items gets out of sync until the resize is finished and it looks broken. As far as I know, FF is the only browser where this happens all other fire onresize events while changing the size. I know the historical reason for this and have suggested an easy solution by using a custom css extension. Even if you add an extra event, MozAfterPaint, it is still a worse solution as every code piece that want to react to onresize would have to be rewritten. A css tag on the body would be very easy to add to a page in response to this even after the page is live and it would not break any existing page at all. Is there any good reason not to use css to do this, any technical problem or is it a philosophical decision? Please consider this.

(In reply to comment #24) > Why do you need this exactly? To adjust a website for when a window is resized? > Perhaps you could use the new MozAfterPaint event for that? Although that is > trunk only (not in Firefox 3.0). Correct. Here's the thing. I have 5 inline-block <div>s placed next to each other. The first, third and fifth <div>s are a set width (15px, 120px, 15px, respectively). The second and fourth <div>s scale to fill space between the other three. The size of second and fourth can't be determined by using percentage in CSS because some of the <div>s are a set length, and therefore change the percentage required in different window sizes. I can't just say width: 50% - 75px; either, since you can't use expressions in CSS (yet). So I fall back to jQuery, which provides the perfect answer for every browser but Firefox. Since Firefox only triggers the window resize event every so often, the entire page layout is unacceptably disfigured for short periods of time. If you Google for 'firefox resize event slow' you'll find quite a few people wish this problem would be fixed. There's really no reason not to; it won't break any pages like it would've several years ago, it increases cross-browser compatibility and it's easy to fix. (In reply to comment #25) I myself would prefer the problem be actually fixed rather than simply patching it with a custom CSS extension. If this bug is fixed, than that means that all browsers (even IE!) treat window resizing the same. I'd call that a big win considering the very little effort needed to solve the problem.

Yeah, it would be quite *opportune* to fix the bug in the upcoming Firefox 3.1. And I agree with Comment #26 that it's preferable to apply a real fix, not just a workaround patch. Thanks.

Comment on attachment 229482 [details] [diff] [review] simple patch jwatt's patch sounds reasonable to me, for until we have a main compositor timer to follow. What do you think, roc?

I have this queued up, ready to land, with a test too.

http://hg.mozilla.org/mozilla-central/rev/8110e3bae4bf http://hg.mozilla.org/mozilla-central/rev/8f53fcb8bde5 Based on the original description of this bug, that makes this fixed, although I'm not sure if the fix satisfies everyone.

I've uploaded a test case based on the page I was working that led me to discover the bug for myself. As you can see, I was developing a header, and I wanted to try implementing 3 slice scaling. In Safari and any other Webkit based browser, this works fine. The whole thing is dependent on inline-blocks, but thanks to WebKit's speedy event firing, the whole shebang doesn't fly apart into multiple lines like it currently does in Firefox. Ideally, the bug fix we implement would provide identical behavior to WebKit. As I said before, Firefox is the last browser that doesn't fluidly fire resize events, and therefore prevents developers from taking advantage of it.

Should a new bug be filed to have onresize fire like IE/Chrome/Safari/Opera?

(In reply to comment #32) > Should a new bug be filed to have onresize fire like IE/Chrome/Safari/Opera? I think so. This bug has been fixed according to it's original description.

Filed bug 341107.

Sorry. I meant bug 457862.

If the window is resized horizontally, then onresize events are fired while the window is being resized. If the window is resized vertically, then onresize events are fired while the window is being resized. But if the window is resized both horizontally and vertically, then onresize events are NOT fired while the window is being resized. Seamonkey 2.0a2pre rv:1.9.1b1pre build 20081004 under XP Pro SP3 here.

Comments in closed bugs aren't going to get tracked -- please either reopen or file a new bug, but either way, add sufficient steps to reproduce.

For the record, this was briefly backed out: http://hg.mozilla.org/mozilla-central/rev/6f3797124c84 and then relanded: http://hg.mozilla.org/mozilla-central/rev/115934f340f0 http://hg.mozilla.org/mozilla-central/rev/a1c4e010b83f during the investigation of bug 458065.

What the hell is wrong with Mozilla. First there's the madness of closing the app when the last tab is closed, then this! Since when was "what I expect" justification for breaking something that is not broken? Since when is copying IE6 behaviiour a good idea? That browser is a joke and the sooner the world is rid of it the better! What about IE7? Surely IE7 and IE8 are more relevant? Firing this event continuously is a recipe for madness. It means that any handler written for resize will be run tens or hundreds of times per resize. It's completely unnecessary to do so. I am utterly sick to death of these types of changes that seem completely ad-hoc. Unless people regularly data mine bigzilla, nobody has a chance to comment before these bugs are acted upon and then this madness hits us via Burning Edge once the bird has flown. Why don't developers focus on innovating in Firefox instead of breaking minor behaviour that just causes heartache for us developers? Instead you let extension authors do all the innovation in a manner much less accessible and that compromises performance. Firefox is going to the dogs. Market share has peaked and Chrome is a big threat. Time for a new approach.

(In reply to comment #39) > Since when is copying IE6 behaviiour a good idea? That browser is a joke and > the sooner the world is rid of it the better! > > What about IE7? Surely IE7 and IE8 are more relevant? Are you saying IE7 and IE8 behave differently? comment 32, etc., imply otherwise. Please note that comment 0 was written in 2001.

(In reply to comment #39) > What the hell is wrong with Mozilla. First there's the madness of closing the > app when the last tab is closed, then this! > > Since when was "what I expect" justification for breaking something that is not > broken? You are joking, right? > > Since when is copying IE6 behaviiour a good idea? That browser is a joke and > the sooner the world is rid of it the better! What about the behavior of every other browser out there beside Moz? > > What about IE7? Surely IE7 and IE8 are more relevant? > > Firing this event continuously is a recipe for madness. It means that any > handler written for resize will be run tens or hundreds of times per resize. > It's completely unnecessary to do so. > Some how, the above "irrelevant" browsers have figure out how to fire the resize event yet not degrade performance. Surely Moz can do the same. > I am utterly sick to death of these types of changes that seem completely > ad-hoc. Unless people regularly data mine bigzilla, nobody has a chance to > comment before these bugs are acted upon and then this madness hits us via > Burning Edge once the bird has flown. This bug has been open since 2002, there was PLENTY of time to comment. > > Why don't developers focus on innovating in Firefox instead of breaking minor > behaviour that just causes heartache for us developers? Instead you let > extension authors do all the innovation in a manner much less accessible and > that compromises performance. Firefox is going to the dogs. Market share has > peaked and Chrome is a big threat. Time for a new approach. You proved your complete ignorance with that last statement, please don't waste any more time posting to this bug.

Was there a bug filed for comment 36?

According to PPK @ Quirksmode, the behaviour of the resize event on Windows is dependent on a Windows desktop effect setting called "Show contents of windows while dragging": http://quirksmode.org/dom/events/resize.html I don't see any reference to this setting in this bug. How does Firefox now behave when this setting is in on and when this setting is off? Was this setting taken into account when this bug was addressed? > You proved your complete ignorance with that last statement, please don't > waste any more time posting to this bug. Hi Jimmy. When I wrote my comment it was in an emotive state. Never a good idea of course but we all make mistakes. How were you feeling when you flamed me? Since you made it personal, I think I deserve a right of reply and that is to say that it's your ignorance that is shining through if you think that disagreeing with your own beliefs is ignorant. Everyone has a right to an opinion. Has Firefox growth stalled overall? Prove me wrong with facts, not flame.

(In reply to comment #43) > According to PPK @ Quirksmode, the behaviour of the resize event on Windows is > dependent on a Windows desktop effect setting called "Show contents of windows > while dragging": > > http://quirksmode.org/dom/events/resize.html > > I don't see any reference to this setting in this bug. This is true. Someone should look into this. If it works how I think it does, it still won't work as badly as it would in Firefox. Here's the problem I ran into with Firefox's resize event. I have, say, three inline-block divs. When the window resizes, I want only two of them to scale, but the third to stay a constant size. I can't use percentage in CSS, since the percentage required changes depending on the size of the window. I have to resort to JavaScript, which listens for Firefox's resize event. Now, at present, the nightly build fire's the resize event every fifth of a second. But since the window is still resizing between those fifths, stuff can still happen. If the window is getting smaller, the inline-blocks will wrap to a new line, and if they're used as part of the layout, this will very bad. The solution I'm using is to put all three divs inside another wrapper div, but I shouldn't have to. WebKit fires resize every time the dimensions of the window change by at least one pixel, either horizontally or vertically. They've also capped the frequency, though I haven't looked up exactly what the cap it at.

(In reply to comment #43) > According to PPK @ Quirksmode, the behaviour of the resize event on Windows is > dependent on a Windows desktop effect setting called "Show contents of windows > while dragging": > > http://quirksmode.org/dom/events/resize.html > > I don't see any reference to this setting in this bug. It seems like this setting should change the events that Windows sends to us, rather than what we do. That said, I don't normally develop on Windows, and I haven't tested this.

Steps: load attachment 245856 [details] If the window is resized both horizontally and vertically, then onresize events are NOT fired while the window is being resized while using Seamonkey 2.0a2pre rv:1.9.1b2pre build 20081009 under XP Pro SP3. I get expected results (resize events fired continuously when window resized horizontally and vertically) with Opera 9.60 and Internet Explorer 7. Adding testcase keyword REOPENING

Safari 3.1.2 build 525.21 and Konqueror 4.1.1 will also fire resize events continuously while the window is being resized both horizontally and vertically when trying testcase of attachment 245856 [details].

Google Chrome also fires the resize event continuously even when "corner resizing" (resizing both horizontally and vertically). The fact is that every single modern browser fires the resize event continuously and consistently except for Firefox.

(In reply to comment #43) > the behaviour of the resize event on Windows is > dependent on a Windows desktop effect setting called "Show contents of windows > while dragging": > > http://quirksmode.org/dom/events/resize.html > > I don't see any reference to this setting in this bug. In XP, try Start/Settings/Control Panel/Category: Appearance and Themes/Display/Appearance tab/Effects... button/Show window contents while dragging checkbox

I should note that the corner-resize thing works just fine over here on Mac. Which means that anyone who cares about this being fixed (which doesn't include me) should probably re-resolve this bug and file a separate, Windows-specific bug, since it's pretty clear that in this case something Windows-specific (almost certainly in the widget layer) is broken. There should similarly be a separate Windows-specific bug filed for following the Windows system setting mentioned in comment 43, if that setting is not being followed. One bug per problem, folks. Unless you seriously think that a widget developer should have to read through all the irrelevant advocacy, discussion of the layout part of this, flaming back and forth, and so on in this bug before even figuring out that there's a problem for him to look into?

> anyone who cares about this being fixed (which doesn't include > me) should probably re-resolve this bug and file a separate, Windows-specific > bug, since it's pretty clear that in this case something Windows-specific > (almost certainly in the widget layer) is broken. Resolving this bug 114649 as Resolved and FIXED Bug 460620 has been filed

(comment #45) >>According to PPK @ Quirksmode, the behaviour of the resize event on Windows is >>dependent on a Windows desktop effect setting called "Show contents of windows >>while dragging": >> http://quirksmode.org/dom/events/resize.html > > It seems like this setting should change the events that Windows sends to us, > rather than what we do. That said, I don't normally develop on Windows, and I > haven't tested this. bug 185533