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

IBX-8837: Distraction free mode: Text obstruction by toolbar's fixed position #1361

Open
wants to merge 2 commits into
base: 4.6
Choose a base branch
from

Conversation

GrabowskiM
Copy link
Contributor

@GrabowskiM GrabowskiM commented Oct 9, 2024

🎫 Issue IBX-8837

Description:

This bug is caused by CKEditor code itself, I've created issue there ckeditor/ckeditor5#17241 but I doubt it will be resolved soon (if ever), judging from my experience, so here's fix for it.

I'm basically temporarly removing styles that breaks supossed correct behaviour, as distraction free mode takes whole page, it doesn't matter what happens beneath, as it's not visible. When closing DFM I restore remove my inline styles/restore previous inline styles

For QA:

This solves https://issues.ibexa.co/browse/IBX-8965 as well, I think.

Documentation:

Copy link

sonarcloud bot commented Oct 9, 2024

@@ -16,6 +17,43 @@
activeFieldEdit.classList.toggle('ibexa-field-edit--distraction-free-mode-active', active);
editorInstance.set('distractionFreeModeActive', active);

if (active) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Should we safeguard the possibility of calling changeDistractionFreeModeState two times in a row with the same active parameter value by e.g. checking whether clearedPositionNodesData is not empty?

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 have analyzed this part, and I think it's more foolproof is without any extra condition, as it will assure correct placement on each run - so it's immune to changing positions/overflow below when distraction free mode is on.

The only "problem" is that it has to traverse whole DOM tree on rerunning it with true, but I think it's small price to pay.

if (active) {
let parentElement = activeFieldEdit.parentNode;

while (parentElement && parentElement !== doc.body) {
Copy link
Contributor

@tischsoic tischsoic Oct 18, 2024

Choose a reason for hiding this comment

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

I think this new fragment may be more readable if split into two functions e.g. resetAncestorsPositions(), restoreAncestorsPositions()

Copy link
Contributor

@lucasOsti lucasOsti left a comment

Choose a reason for hiding this comment

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

OK, Besides Kuba's comment https://github.com/ibexa/admin-ui/pull/1361/files#r1806371839 which I agree with :)

Copy link

sonarcloud bot commented Nov 25, 2024

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.

5 participants