New issue
Advanced search Search tips

Issue 706972 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner:
Closed: Mar 2017
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

ResizeObserver infinite loop on disconnect/observe.

Project Member Reported by atotic@chromium.org, Mar 30 2017

Issue description

Chrome Version: (copy from chrome://version)
OS: (e.g. Win7, OSX 10.9.5, etc...)

From https://github.com/WICG/ResizeObserver/issues/38#issuecomment-290282872

I thought I'd post here first, in case this is intended behavior and not a Chrome bug. Couldn't quite tell from the spec.

Take a look at the following code ([live here](http://jsbin.com/copiyel/6/edit?js,console,output)):

```js
var div = document.querySelector("div");
var resizeObserver = new ResizeObserver(entries => {
	console.log("resizeobserver fired");
	resizeObserver.disconnect();
	
	// [Operation that would cause resize here]
	
	resizeObserver.observe(div);
});

resizeObserver.observe(div);
```

This is a very common pattern with any kind of observer: Often you want to monitor external changes to the DOM and as a response to them, you need to make changes of your own that should not trigger the same observer because that would cause a loop. 

With Mutation observers, this pattern works fine. However, since `ResizeObserver` seems to be firing the callback immediately after `observe()` is called, this causes an infinite loop. 

 

Comment 1 by leave...@gmail.com, Mar 30 2017

Note: This is not a bug about the depth limit not being applied. It should not even get close to the depth limit, because it shouldn't fire immediately on observe, but only once an actual resize has occurred. The bug is NOT that the depth limit is not applied, it's that the callback is firing immediately once observe() is called.

If I want the same code to run both immediately when I attach the observer and in the future on resizes, I can just call it myself before attaching the observer and it would just be an extra line of code. However, if I don't want this behavior, there's no opt-out. Also, running the callback immediately once observe() is called is inconsistent with how mutation observers work.

Comment 2 by atotic@chromium.org, Mar 31 2017

Status: WontFix (was: Unconfirmed)
Turns out this was not about depth limit, it was about Observation intial value. The code performs per spec.

Sign in to add a comment