Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

windowWidth and windowHeight not being mapped correctly to counterparts #6396

Closed
1 of 17 tasks
bensgilbert opened this issue Sep 6, 2023 · 6 comments
Closed
1 of 17 tasks

Comments

@bensgilbert
Copy link
Contributor

bensgilbert commented Sep 6, 2023

Most appropriate sub-area of p5.js?

  • Accessibility
  • Color
  • Core/Environment/Rendering
  • Data
  • DOM
  • Events
  • Image
  • IO
  • Math
  • Typography
  • Utilities
  • WebGL
  • Build Process
  • Unit Testing
  • Internalization
  • Friendly Errors
  • Other (specify if possible)

p5.js version

1.7.0

Web browser and version

Microsoft Edge 116.0.1938.69; Chromium version 116.0.5845.141

Operating System

Windows 11 Version 22H2 (Build 22621.2134)

Steps to reproduce this

Steps:

  1. Create a new tab in your browser
  2. Enter the url and navigate to a site with a p5js sketch
  3. Check the console for the output of the code below

Snippet:

function setup() {
    console.log(windowWidth, windowHeight);
    console.log(innerWidth, innerHeight);
}

This behaviour occurs on MS edge (running chromium). Discord user: davepagurek (138146691151822848) tested this issue in a chrome browser which resulted in the same bug, they also tested this in a firefox browser which did not result in this oddity happening which suggests that it is an issue with chromium.

I found that after refreshing the tab, the values are the same so this bug occurs only in new tabs.

2023-09-05.23-12-36.mp4

Possible Fix:

Set the values of windowWidth and windowHeight manually before calling the setup() function.

@bensgilbert bensgilbert added the Bug label Sep 6, 2023
@welcome
Copy link

welcome bot commented Sep 6, 2023

Welcome! 👋 Thanks for opening your first issue here! And to ensure the community is able to respond to your issue, please make sure to fill out the inputs in the issue forms. Thank you!

@DarKDevz
Copy link

DarKDevz commented Sep 8, 2023

This isn't a bug afaik, because if you reload the page it works,
it's just an issue with chrome not setting the height correctly when first opening the window
not an issue with p5.js

@limzykenneth
Copy link
Member

@Evorage0 This happens because Chromium incorrectly included the bookmarks bar in the height calculation on page load when the user hides the bookmark bar when not on empty page. Firefox does not include the bar at all when it is set to be hidden except for on empty page so it gets consistent value, while Chromium likely calculate it on the fly, making the two values different between line execution (that's my guess at least).

As noted this is not an issue with p5.js and we can't really resolve this on our side since it is a problem with incorrect value provided by Chromium. I'll close this for now and this problem should be reported to Chromium instead. Thanks!

@davepagurek
Copy link
Contributor

Just want to point out that we might be able to work around this: in the example code, innerWidth/innerHeight seems to be correct in setup, which implies that it's only incorrect right on page load? So we only set the initial value right before we run preload or setup, we could get correct behaviour without degrading the experience anywhere else. Do you think that'd be worth implementing?

@limzykenneth
Copy link
Member

The value of windowWidth, windowHeight already is basically an alias to innerWidth/innerHeight, I don't know why there is discrepancy between two consecutive calls or why two calls to innerHeight don't have this problem, it could be an event firing issue or something else.

Firefox doesn't fire a resize event under these circumstances while Chrome does, another side effect is this is not consistent. I was able to replicate the issue yesterday but not anymore, which sounds like a race condition to me. We can change when the initial value is set (currently set during initialization) but I'm not entirely sure how well it will work considering the value is updated by the window resize event so we may not be getting the initial value anyway.

@bensgilbert
Copy link
Contributor Author

I believe this has now been solved by #7134 which implements the solution dave mentioned above

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants