Mouse event propagation after surface.setSize() doesn't fully work outside initial window size region

[gwygonik]

Description

In our existing app (SquiggleDraw), we start with an app window size of 100x100 and resize after startup as we load an image to process (we also resize on user-triggered image load). We use ControlP5 for GUI, which exists on the left side of the window area (a roughly 200x800px UI area).

In 4.0b7, mouse hover and press events do not get propagated to the ControlP5 UI widgets outside of the initial 100x100px area, but do work in the main app (e.g.: mousePressed). However, mouse drag events do work as you can click a UI widget within the initial 100x100px bounds and it responds to drags outside those bounds (e.g.: a slider control).

Expected Behavior

In 3.5.4, the ControlP5 GUI is responsive outside of the initial 100x100px area after loading the startup image and calling surface.setSize().

Current Behavior

In 4.0b7, the GUI is only fully responsive within the original 100x100px window area, even though the app window is now much larger after calling surface.setSize().

Steps to Reproduce

The following minimal code example demonstrates the issue.

The top slider responds to hover and press events only within the initial window size, represented by the rectangle. Clicking the top slider within the initial window size and dragging beyond the initial bounds does work.

The bottom slider does not respond to any mouse events.

Minimal code example (requires ControlP5 library):

import controlP5.*;

boolean first_time = true;
ControlP5 cp5;

void setup() {
  size(100,100);
  background(255);
  noFill();
  stroke(128);
  rect(0,0,100,100);
  cp5 = new ControlP5(this);

  // top slider - only hover and press events within initial 100x100 window
  // note area of slider outside rect which doesn't respond to hover or press
  cp5.addSlider("sliderA", 0, 100, 50, 10, 10,  100, 20);

  // bottom slider - not responsive to any mouse events
  cp5.addSlider("sliderB", 0, 100, 50, 10, 110, 100, 20);
}

void draw() {
  if (first_time) {
    surface.setSize(200,150);
    first_time = false;
  }
  background(255);
  rect(0,0,100,100);
}

void mousePressed() {
  // app responds to mouse events across entire canvas
  ellipse(mouseX, mouseY, 5, 5);
}

Your Environment

• Processing version: 4.0b7
• Operating System and OS version: MacOS 10.15.7
• Other information:

Possible Causes / Solutions

It's possible this is not related to mouse handling at all, but rather something in surface.setSize() not updating internals fully. It's also entirely possible this is something within ControlP5 that needs updating, though since things work within that initial window area, I'm leaning towards this not being the case.

[benfry]

This sounds like a bug inside controlp5. Also with 4.0 you can/should use windowResize() instead of surface.setSize().

[prototype99]

I couldn't get any region to detect the mousereleased event in beta 7. i didn't test beta 6 because of the file issue, however beta 5 could detect the event without issue. is there an example of beta 7 successfully handling mouse events such as mousereleased?

update: the issue disappeared in a later iteration, so not sure what to make of it

[gwygonik]

This sounds like a bug inside controlp5. Also with 4.0 you can/should use windowResize() instead of surface.setSize().

Thanks Ben. I tried with windowResize() and had the same results (also, good to know about windowResize() 😄 ).

It appears that there is a related ControlP5 issue going back to November 2021 that experiences the same problem, though using setResizable() and reflowing the UI as the window scales ( sojamo/controlp5#175 ). I can repro their issue in 4.0b7 and 3.5.4. Both this issue above and the ControlP5 code (which hasn't been updated in 7-8 years) utilize registerMethod calls to update layout or catch mouse events. Could there be something in this chain that isn't passing the right canvas size?

[benfry]

Sorry, I can't speak to the controlp5 code. It's possible they were relying on an undocumented feature of how PApplet worked before, and in the process of getting the windowXxxx() methods working better for users, that's behaving differently.

[benfry]

Closing this for now since it seems to be a controlp5 issue; please report it with that project so it can get sorted out, or report back here if there's in fact a Processing bug.

[github-actions]

This issue has been automatically locked. To avoid confusion with reports that have already been resolved, closed issues are automatically locked 30 days after the last comment. Please open a new issue for related bugs.