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.

Sign up for GitHub

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

Jump to bottom

Expanding a component in a PopupView #11187

Closed
HappyLuke opened this issue Sep 14, 2018 · 3 comments · Fixed by #12138
Closed

Expanding a component in a PopupView #11187

HappyLuke opened this issue Sep 14, 2018 · 3 comments · Fixed by #12138
Labels
Stale Stale bot label

Comments

@HappyLuke
Copy link

I believe this issue is a bug in the PopupView Component and therefor I open a GitHub issue for this.
I already ask a question in StackOverflow, describing this issue:
https://stackoverflow.com/q/52296259/9687804

I am using Vaadin 8.5.2, and tested it with Chrome 68.0.3440.106 (64-bit) and Firefox 62.0 (64-bit).

I am using an embedded Tomcat Container (version 8.5.32) with Spring Boot (version 2.0.4).

Here you find a working code example to reproduce the issue: https://github.com/HappyLuke/vaadin-issue-1

I expect the button to be inside the PopupView, however, it is shown outside the PopupView. When expanding a tree component or changing the DateField value, the button will move into the PopupView as expected.

Thanks for any support!
@stale
Copy link

stale bot commented Feb 11, 2019

Hello there!

We are sorry that this issue hasn't progressed lately. We are prioritizing issues by severity and the number of customers we expect are experiencing this and haven't gotten around to fix this issue yet.

There are a couple of things you could help to get things rolling on this issue (this is an automated message, so expect that some of these are already in use):

  • Check if the issue is still valid for the latest version. There are dozens of duplicates in our issue tracker, so it is possible that the issue is already tackled. If it appears to be fixed, close the issue, otherwise report to the issue that it is still valid.
  • Provide more details how to reproduce the issue.
  • Explain why it is important to get this issue fixed and politely draw others attention to it e.g. via the forum or social media.
  • Add a reduced test case about the issue, so it is easier for somebody to start working on a solution.
  • Try fixing the issue yourself and create a pull request that contains the test case and/or a fix for it. Handling the pull requests is the top priority for the core team.
  • If the issue is clearly a bug, use the Warranty in your Vaadin subscription to raise its priority.

Thanks again for your contributions! Even though we haven't been able to get this issue fixed, we hope you to report your findings and enhancement ideas in the future too!

@stale stale bot added the Stale Stale bot label label Feb 11, 2019
@scardanzan
Copy link

The issue is reproducible in 8.10.4. In your sample project you could set the expand ratio of the button to something like 0.2f, that will make the initial render look better, but the button will still move after you take an action just like its does in your sample. It will move a lot less and look better but its not really a solution.

@stale stale bot removed the Stale Stale bot label label May 14, 2020
@stale
Copy link

stale bot commented Oct 11, 2020

Hello there!

We are sorry that this issue hasn't progressed lately. We are prioritizing issues by severity and the number of customers we expect are experiencing this and haven't gotten around to fix this issue yet.

There are a couple of things you could help to get things rolling on this issue (this is an automated message, so expect that some of these are already in use):

  • Check if the issue is still valid for the latest version. There are dozens of duplicates in our issue tracker, so it is possible that the issue is already tackled. If it appears to be fixed, close the issue, otherwise report to the issue that it is still valid.
  • Provide more details how to reproduce the issue.
  • Explain why it is important to get this issue fixed and politely draw others attention to it e.g. via the forum or social media.
  • Add a reduced test case about the issue, so it is easier for somebody to start working on a solution.
  • Try fixing the issue yourself and create a pull request that contains the test case and/or a fix for it. Handling the pull requests is the top priority for the core team.
  • If the issue is clearly a bug, use the Warranty in your Vaadin subscription to raise its priority.

Thanks again for your contributions! Even though we haven't been able to get this issue fixed, we hope you to report your findings and enhancement ideas in the future too!

@stale stale bot added the Stale Stale bot label label Oct 11, 2020
Ansku added a commit to Ansku/framework that referenced this issue Oct 27, 2020
@Ansku
Fix to LayoutManager size calculations during transform.
8df2849 
ComputedStyle is slower but more reliable than using
getBoundingClientRect, which does not work as expected
if a transform has been applied to the element or one of its parents.
This is a problem e.g. with PopupView, where getBoundingClientRect will
return 0 for all the popup content sizes while the opening animation is
active. ComputedStyle ignores the transform and returns the expected
value.

Fixes: vaadin#11187
@Ansku Ansku mentioned this issue Oct 27, 2020
Merged
Ansku added a commit to Ansku/framework that referenced this issue Oct 29, 2020
@Ansku
Fix to LayoutManager size calculations during transform.
b37537c 
ComputedStyle is slower but more reliable than using
getBoundingClientRect, which does not work as expected
if a transform has been applied to the element or one of its parents.
This is a problem e.g. with PopupView, where getBoundingClientRect will
return 0 for all the popup content sizes while the opening animation is
active. ComputedStyle ignores the transform and returns the expected
value.

Fixes: vaadin#11187
Ansku added a commit to Ansku/framework that referenced this issue Oct 30, 2020
@Ansku
Fix to LayoutManager size calculations during transform.
88a9b66 
ComputedStyle is slower but more reliable than using
getBoundingClientRect, which does not work as expected
if a transform has been applied to the element or one of its parents.
This is a problem e.g. with PopupView, where getBoundingClientRect will
return 0 for all the popup content sizes while the opening animation is
active. ComputedStyle ignores the transform and returns the expected
value.

Fixes: vaadin#11187
Ansku added a commit that referenced this issue Dec 8, 2020
@Ansku
Fix to LayoutManager size calculations during transform.
655ee07 
ComputedStyle is slower but more reliable than using
getBoundingClientRect, which does not work as expected
if a transform has been applied to the element or one of its parents.
This is a problem e.g. with PopupView, where getBoundingClientRect will
return 0 for all the popup content sizes while the opening animation is
active. ComputedStyle ignores the transform and returns the expected
value.

Fixes: #11187
Ansku added a commit to Ansku/framework that referenced this issue Dec 9, 2020
@Ansku
Fix to PopupView and LayoutManager size calculations during transform.
29b4f4e 
- ComputedStyle is slower but more reliable than using
getBoundingClientRect, which does not work as expected
if a transform has been applied to the element or one of its parents.
This is a problem e.g. with PopupView, where getBoundingClientRect will
return 0 for all the popup content sizes while the opening animation is
active. ComputedStyle ignores the transform and returns the expected
value.
- On occasion PopupView's popup contents are measured too early and any
calculations that rely on those measurements get erroneous results.
Check at the end of the layout whether the measuring succeeded, and
re-calculate if it did not.
- If layout is still running but actual layout phases are over, leave
elements that need measuring for the next round.
- If there are pending layouts, trigger them immediately after previous
layout round finishes, rather than hoping that the timer will trigger
eventually. Allow for one millisecond delay in case there are other
pending changes waiting for an opportunity to get processed first.
- If the timer is run while layout is still running, do nothing and wait
for the timer to get triggered again when the layout round is finished.

Fixes: vaadin#11187
Ansku added a commit to Ansku/framework that referenced this issue Dec 10, 2020
@Ansku
Fix to PopupView and LayoutManager size calculations during transform.
ce346f0 
- ComputedStyle is slower but more reliable than using
getBoundingClientRect, which does not work as expected
if a transform has been applied to the element or one of its parents.
This is a problem e.g. with PopupView, where getBoundingClientRect will
return 0 for all the popup content sizes while the opening animation is
active. ComputedStyle ignores the transform and returns the expected
value.
- On occasion PopupView's popup contents are measured too early and any
calculations that rely on those measurements get erroneous results.
Check at the end of the layout whether the measuring succeeded, and
re-calculate if it did not.
- If layout is still running but actual layout phases are over, leave
elements that need measuring for the next round.
- If there are pending layouts, trigger them immediately after previous
layout round finishes, rather than hoping that the timer will trigger
eventually. Allow for one millisecond delay in case there are other
pending changes waiting for an opportunity to get processed first.
- If the timer is run while layout is still running, do nothing and wait
for the timer to get triggered again when the layout round is finished.
- Manual test, problem isn't reproducible by TestBench.

Fixes: vaadin#11187
Ansku added a commit to Ansku/framework that referenced this issue Dec 10, 2020
@Ansku
Fix to PopupView and LayoutManager size calculations during transform.
18e138d 
- ComputedStyle is slower but more reliable than using
getBoundingClientRect, which does not work as expected
if a transform has been applied to the element or one of its parents.
This is a problem e.g. with PopupView, where getBoundingClientRect will
return 0 for all the popup content sizes while the opening animation is
active. ComputedStyle ignores the transform and returns the expected
value.
- On occasion PopupView's popup contents are measured too early and any
calculations that rely on those measurements get erroneous results.
Check at the end of the layout whether the measuring succeeded, and
re-calculate if it did not.
- If layout is still running but actual layout phases are over, leave
elements that need measuring for the next round.
- If there are pending layouts, trigger them immediately after previous
layout round finishes, rather than hoping that the timer will trigger
eventually. Allow for one millisecond delay in case there are other
pending changes waiting for an opportunity to get processed first.
- If the timer is run while layout is still running, do nothing and wait
for the timer to get triggered again when the layout round is finished.
- Manual test, problem isn't reproducible by TestBench.

Fixes: vaadin#11187
Ansku added a commit to Ansku/framework that referenced this issue Dec 10, 2020
@Ansku
Fix to LayoutManager size calculations during transform.
7fa5820 
- ComputedStyle is slower but more reliable than using
getBoundingClientRect, which does not work as expected
if a transform has been applied to the element or one of its parents.
This is a problem e.g. with PopupView, where getBoundingClientRect will
return 0 for all the popup content sizes while the opening animation is
active. ComputedStyle ignores the transform and returns the expected
value.
- The presence of the element in DOM must be checked before the size is
requested from ComputedStyle, if the element has disappeared from DOM
without a warning and calculation is attempted anyway, the browser gets
stuck.
- Manual test, problem isn't reproducible by TestBench.

Fixes: vaadin#11187
Ansku added a commit to Ansku/framework that referenced this issue Dec 16, 2020
@Ansku
Fix to LayoutManager size calculations during transform.
3c6e974 
- ComputedStyle is slower but more reliable than using
getBoundingClientRect, which does not work as expected if a transform
has been applied to the element or one of its parents. This is a problem
e.g. with PopupView, where getBoundingClientRect will return too small
size (or even zero size) for all the popup contents while the opening
animation is active. ComputedStyle ignores the transform and returns the
expected value.
- The presence of the element in DOM must be checked before the size is
requested from ComputedStyle, if the element has disappeared from DOM
without a warning and calculation is attempted anyway, the browser gets
stuck.
- Possibility to configure LayoutManager to use the less reliable
calculations for applications where the slight performance difference is
more important than layout issues within elements that have transform
animations.
- Manual test, problem isn't reproducible by TestBench.

Fixes: vaadin#11187
Ansku added a commit to Ansku/framework that referenced this issue Dec 17, 2020
@Ansku
Fix to LayoutManager size calculations during transform.
004d004 
- ComputedStyle is slower but more reliable than using
getBoundingClientRect, which does not work as expected if a transform
has been applied to the element or one of its parents. This is a problem
e.g. with PopupView, where getBoundingClientRect will return too small
size (or even zero size) for all the popup contents while the opening
animation is active. ComputedStyle ignores the transform and returns the
expected value.
- The presence of the element in DOM must be checked before the size is
requested from ComputedStyle, if the element has disappeared from DOM
without a warning and calculation is attempted anyway, the browser gets
stuck.
- Possibility to configure LayoutManager to use the less reliable
calculations for applications where the slight performance difference is
more important than layout issues within elements that have transform
animations.
- Manual test, problem isn't reproducible by TestBench.

Fixes: vaadin#11187
OlliTietavainenVaadin pushed a commit that referenced this issue Dec 18, 2020
@Ansku
Fix to LayoutManager size calculations during transform. (#12138)
c8e04dc 
* Fix to LayoutManager size calculations during transform.

- ComputedStyle is slower but more reliable than using
getBoundingClientRect, which does not work as expected if a transform
has been applied to the element or one of its parents. This is a problem
e.g. with PopupView, where getBoundingClientRect will return too small
size (or even zero size) for all the popup contents while the opening
animation is active. ComputedStyle ignores the transform and returns the
expected value.
- The presence of the element in DOM must be checked before the size is
requested from ComputedStyle, if the element has disappeared from DOM
without a warning and calculation is attempted anyway, the browser gets
stuck.
- Possibility to configure LayoutManager to use the less reliable
calculations for applications where the slight performance difference is
more important than layout issues within elements that have transform
animations.
- Manual test, problem isn't reproducible by TestBench.

Fixes: #11187
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Stale Stale bot label
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Fix to LayoutManager size calculations during transform. Ansku/framework
2 participants
@scardanzan @HappyLuke