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

Browser: Fix panel rendered waiting condition #472

Merged
merged 1 commit into from
Oct 6, 2023

Conversation

AgnesToulet
Copy link
Contributor

Fix the following things in the panel rendered waiting condition:

  • panelCount was always 0, now it should be the right count for valid panels and 0 for invalid panels (e.g. panel not found error)
  • panelsRendered is always undefined at first and is set when the panel is rendered so checking if it's undefined make the waiting condition pass on the first check and we actually don't wait for the panel to be rendered

@@ -351,8 +351,8 @@ export class Browser {
return totalPanelsRendered >= panelCount;
}

const panelCount = document.querySelectorAll('.panel').length || document.querySelectorAll('.panel-container').length;
return (window as any).panelsRendered >= panelCount || (window as any).panelsRendered === undefined;
const panelCount = document.querySelectorAll('.panel-solo').length || document.querySelectorAll('[class$=\'panel-container\']').length;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why did it change? Does it work right now?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it changes a while ago in Grafana but we didn't notice because it was 0 and panelsRendered is undefined until the panel is rendered. So for one panel (what we always render because the condition for full page is different), we checked undefined >= 0 for a while (which is false) and when the panel is rendered, we checked 0 >= 0 (which is true) so it returned.

I don't think we actually need this and we could set it to 1 but I would need to think more about it before making this more bigger change (and it would be nice to have a test suite as well for this kind of things).

@AgnesToulet AgnesToulet merged commit 5fd62af into master Oct 6, 2023
2 checks passed
@AgnesToulet AgnesToulet deleted the fix-waiting-condition branch October 6, 2023 12:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants