detect window resize due to download bar (chrome, latest edge, firefox) vs general window resize

Question

I have a legacy webapp which has super complicated resize event bound. It supports desktop-like windows within the page (I know...) and they all scale on resize.

This actually performs fine except in one case: when you click on a PDF link on this app and it downloads to the browser, then opens the PDF in a new tab instead of system viewer (if that is the user's browser setting). Then when closing the tab and going back to the app's tab, it spends an inordinate amount of time on resize logic (normal resize logic timing from click dragging window corner is ~1-3s, this is like ~15-20s)

I think multiple resizes may be triggered simultaneously when the downloads bar pops into the page and the new tab opens. There is already a very large (1500ms) debouncer in place but maybe something about opening a new tab / the download bar resizing instead of click-drag resizing makes the debouncer not apply in this case) and causes this huge slowdown when closing the PDF and going back to the app tab.

we cannot just tell users to have their PDFs open in system viewer, and I need some guidance on how to even start trying to fix this issue. (or help on the path I'm trying).

The path I'm trying is: i want to detect a resize that is from the downloads bar as opposed to for other reasons (maybe the y delta being exactly the same as downloads bar height?? is there a way to do that?) and just return false, we dont care much if that 50-100px is not adjusted for and when they close it, it will resize normally anyway.

Answer 1

This is the code I've used to deal with being flooded with events in the past

import raf from 'raf'

let rafId = null

function onResize() {
  if(!rafId) {
    rafId = raf(() => {
      your_resize_function()
      rafId = null
    })
  }
}

window.addEventListener('resize', onResize)

Its using requestAnimationFrame to delay the kickoff and a simple flag to stop it being called more than once. I find this much better than using debounce() as it adapts to how busy the call stack is.