Do xdg_surface::configure sequences contain the entire surface state?

(Note: The same issue could be opened for wl_surface::configure but I encountered it in the context of xdg_surface.)

When a compositor sends an xdg_surface::configure event, must the preceding sequence (i.e. all events since the previous xdg_surface::configure for the same surface) contain all state or is it sufficient for the sequence to contain the delta since the previous sequence?

I encountered this issue with chromium. At startup, I would send the following events:

zxdg_toplevel_decoration_v1@38.configure(2)
xdg_surface@36.configure(1)
xdg_toplevel@37.configure(1, 1, array[16])
xdg_surface@36.configure(2)

This would cause chromium to hang. I assume (but I have not checked yet), that chromium expects the toplevel configuration to be contained in the first configuration sequence. After changing my code to emit

zxdg_toplevel_decoration_v1@38.configure(2)
xdg_toplevel@37.configure(1, 1, array[16])
xdg_surface@36.configure(1)

the problem went away.

This issue with chromium seems to only affect the first sequence and I'm not aware of any other applications that have this kind of requirement.

Nevertheless, the question is if applications can expect all configuration sequences to contain the entire surface configuration state. I'm not sure how to define the "surface configuration state" but at least that state that is defined (in any protocol) to be part of such a sequence.

In other words, whenever I emit

xdg_surface@36.configure(1)

should the preceding sequence contain

xdg_toplevel_decoration_v1@38.configure(2)
xdg_toplevel@37.configure(1, 1, array[16])

even if those properties have not changed.