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
[FIX] website, *: restore 'animation' system to the way it worked #30478
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
qsm-odoo
added
RD
research & development, internal work
Website
Web editor
website editor
labels
Jan 23, 2019
qsm-odoo
force-pushed
the
master-wysiwyg-fix-animations-qsm
branch
from
January 23, 2019 13:50
81788e7
to
1cfa3b3
Compare
@robodoo r+ |
robodoo
pushed a commit
that referenced
this pull request
Jan 23, 2019
* website_forum Following the new editor's merge at #29775, the website 'animation' system was 'extended' to vaguely use a 'Registry' instance instead of an object. This was however left undocumented, with a require in the middle of a file, restarting all animations when used, only used by website_forum... with more code for no reason at all, ... This commit restores the system to the way it was before and re-adapts website_forum: - No need to check if website_forum is in the DOM as it is already checked by the animation system (on top of that... the new code was checking the DOM before it was ready...). - No need of a dynamic add on a registry, this is always done before the DOM is ready, so before the animations are started. - No need to know the root instance in website forum, just use the animation as the Wysiwyg instance's parent. The goal of this commit is also to avoid useless conflicts with #29442 (that should not have had any conflict at all as totally independent of the editor task...) closes #30478
Staging failed: timed out (>120 minutes) |
@robodoo retry ? |
Staging failed: timed out (>120 minutes) |
* website_forum Following the new editor's merge at odoo#29775, the website 'animation' system was 'extended' to vaguely use a 'Registry' instance instead of an object. This was however left undocumented, with a require in the middle of a file, restarting all animations when used, only used by website_forum... with more code for no reason at all, ... This commit restores the system to the way it was before and re-adapts website_forum: - No need to check if website_forum is in the DOM as it is already checked by the animation system (on top of that... the new code was checking the DOM before it was ready...). - No need of a dynamic add on a registry, this is always done before the DOM is ready, so before the animations are started. - No need to know the root instance in website forum, just use the animation as the Wysiwyg instance's parent. The goal of this commit is also to avoid useless conflicts with odoo#29442 (that should not have had any conflict at all as totally independent of the editor task...)
qsm-odoo
force-pushed
the
master-wysiwyg-fix-animations-qsm
branch
from
January 24, 2019 09:49
1cfa3b3
to
f5d17ec
Compare
@robodoo retry |
robodoo
added
merging 👷
and removed
CI 🤖
Robodoo has seen passing statuses
merging 👷
labels
Jan 24, 2019
Staging failed: ci/runbot (view more at http://runbot.odoo.com/runbot/build/434876) |
@robodoo retry |
robodoo
pushed a commit
that referenced
this pull request
Jan 24, 2019
* website_forum Following the new editor's merge at #29775, the website 'animation' system was 'extended' to vaguely use a 'Registry' instance instead of an object. This was however left undocumented, with a require in the middle of a file, restarting all animations when used, only used by website_forum... with more code for no reason at all, ... This commit restores the system to the way it was before and re-adapts website_forum: - No need to check if website_forum is in the DOM as it is already checked by the animation system (on top of that... the new code was checking the DOM before it was ready...). - No need of a dynamic add on a registry, this is always done before the DOM is ready, so before the animations are started. - No need to know the root instance in website forum, just use the animation as the Wysiwyg instance's parent. The goal of this commit is also to avoid useless conflicts with #29442 (that should not have had any conflict at all as totally independent of the editor task...) closes #30478
Merged, thanks! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
CI 🤖
Robodoo has seen passing statuses
RD
research & development, internal work
Web editor
website editor
Website
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Following the new editor's merge at #29775,
the website 'animation' system was 'extended' to vaguely use a
'Registry' instance instead of an object. This was however left
undocumented, with a require in the middle of a file, restarting all
animations when used, only used by website_forum... with more code for
no reason at all, ...
This commit restores the system to the way it was before and re-adapts
website_forum:
checked by the animation system (on top of that... the new code was
checking the DOM before it was ready...).
DOM is ready, so before the animations are started.
animation as the Wysiwyg instance's parent.
The goal of this commit is also to avoid useless conflicts with
#29442 (that should not have had any
conflict at all as totally independent of the editor task...)