Bug: hoisted stylesheets should not reorder when re-rendered in a transition #27585
Labels
Status: Unconfirmed
A potential issue that we haven't yet confirmed as a bug
Comments
gnoff
added
the
Status: Unconfirmed
gnoff
added a commit
that referenced
this issue
Oct 25, 2023
The loading state tracking for suspensey CSS is too complicated. Prior to this change it had a state it could enter into where a stylesheet was already in the DOM but the loading state did not know it was inserted causing a later transition to try to insert it again. This fix is to add proper tracking of insertions on the codepaths that were missing it. It also modifies the logic of when to suspend based on whether the stylesheet has already been inserted or not. This is not 100% correct semantics however because a prior commit could have inserted a stylesheet and a later transition should ideally be able to wait on that load before committing. I haven't attempted to fix this yet however because the loading state tracking is too complicated as it is and requires a more thorough refactor. Additionally it's not particularly valuable to delay a transition on a loading stylesheet when a previous commit also relied on that stylesheet but didn't wait for it b/c it was sync. I will follow up with an improvement PR later fixes: #27585
github-actions bot
pushed a commit
that referenced
this issue
Oct 25, 2023
The loading state tracking for suspensey CSS is too complicated. Prior to this change it had a state it could enter into where a stylesheet was already in the DOM but the loading state did not know it was inserted causing a later transition to try to insert it again. This fix is to add proper tracking of insertions on the codepaths that were missing it. It also modifies the logic of when to suspend based on whether the stylesheet has already been inserted or not. This is not 100% correct semantics however because a prior commit could have inserted a stylesheet and a later transition should ideally be able to wait on that load before committing. I haven't attempted to fix this yet however because the loading state tracking is too complicated as it is and requires a more thorough refactor. Additionally it's not particularly valuable to delay a transition on a loading stylesheet when a previous commit also relied on that stylesheet but didn't wait for it b/c it was sync. I will follow up with an improvement PR later fixes: #27585 DiffTrain build for [a998552](a998552)
jerrydev0927
added a commit
to jerrydev0927/react
that referenced
this issue
Jan 5, 2024
The loading state tracking for suspensey CSS is too complicated. Prior to this change it had a state it could enter into where a stylesheet was already in the DOM but the loading state did not know it was inserted causing a later transition to try to insert it again. This fix is to add proper tracking of insertions on the codepaths that were missing it. It also modifies the logic of when to suspend based on whether the stylesheet has already been inserted or not. This is not 100% correct semantics however because a prior commit could have inserted a stylesheet and a later transition should ideally be able to wait on that load before committing. I haven't attempted to fix this yet however because the loading state tracking is too complicated as it is and requires a more thorough refactor. Additionally it's not particularly valuable to delay a transition on a loading stylesheet when a previous commit also relied on that stylesheet but didn't wait for it b/c it was sync. I will follow up with an improvement PR later fixes: facebook/react#27585 DiffTrain build for [a9985529f1aa55477f0feafe2398d36707cf6108](facebook/react@a998552)
EdisonVan
pushed a commit
to EdisonVan/react
that referenced
this issue
Apr 15, 2024
The loading state tracking for suspensey CSS is too complicated. Prior to this change it had a state it could enter into where a stylesheet was already in the DOM but the loading state did not know it was inserted causing a later transition to try to insert it again. This fix is to add proper tracking of insertions on the codepaths that were missing it. It also modifies the logic of when to suspend based on whether the stylesheet has already been inserted or not. This is not 100% correct semantics however because a prior commit could have inserted a stylesheet and a later transition should ideally be able to wait on that load before committing. I haven't attempted to fix this yet however because the loading state tracking is too complicated as it is and requires a more thorough refactor. Additionally it's not particularly valuable to delay a transition on a loading stylesheet when a previous commit also relied on that stylesheet but didn't wait for it b/c it was sync. I will follow up with an improvement PR later fixes: facebook#27585
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
vercel.com observed a bug where a stylesheet hoisted using a
precedencewas reordered after an update. This is not correct semantics (once a hoisted stylesheet is inserted it should remain in place until removed)Investigating the React implementation I observed that if you insert a hoisted stylesheet during a synchronous render and later render a new reference to that stylesheet in a transition React incorrectly considers the stylesheet not loaded and tries to coordinate it's loading the the commit. This is erroneous as once a stylesheet is in the DOM it should never be re-inserted (moved).
The text was updated successfully, but these errors were encountered: