Skip to content

TINY-11909: Add support for readonly mode #77

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

Merged
merged 12 commits into from
May 27, 2025
Merged

Conversation

lorenzo-pomili
Copy link
Contributor

Related ticket: TINY-11909

added support for readonly mode and now disabled prop uses the editor disable

@lorenzo-pomili lorenzo-pomili requested a review from a team as a code owner May 7, 2025 06:16
@lorenzo-pomili lorenzo-pomili requested review from spocke, TheSpyder, ltrouton, a team, hamza0867, HAFRMO and ztomaszyk and removed request for a team May 7, 2025 06:16
@lorenzo-pomili lorenzo-pomili marked this pull request as draft May 7, 2025 06:17
@lorenzo-pomili lorenzo-pomili marked this pull request as ready for review May 7, 2025 07:54
@michalnieruchalski-tiugo

(question)
Let's say the customer is using TinyMCE 7.0 with this integration. They set the editor to be disabled disabled=true. (This will cause the editor to initially be in readonly mode) They've decided to bump the version of the integration so that it'll include this change.

Will the editor be in readonly mode?

I think it won't. Because initially editor's init method has

readonly: false,
disabled: true

but the disabled property is ignored by TinyMCE 7.0.


We can't use the isDisabledOptionSupported method without the editor instance, so it'll be tricky to set the init object correctly. (That's why I was forced to compare the versions in my PR :( )

@lorenzo-pomili
Copy link
Contributor Author

(question) Let's say the customer is using TinyMCE 7.0 with this integration. They set the editor to be disabled disabled=true. (This will cause the editor to initially be in readonly mode) They've decided to bump the version of the integration so that it'll include this change.

Will the editor be in readonly mode?

I think it won't. Because initially editor's init method has

readonly: false,
disabled: true

but the disabled property is ignored by TinyMCE 7.0.

We can't use the isDisabledOptionSupported method without the editor instance, so it'll be tricky to set the init object correctly. (That's why I was forced to compare the versions in my PR :( )

don't we would have the same behavior using the version check? if the disabled prop will not be upgraded they will get a different behavior

@michalnieruchalski-tiugo

(question) Let's say the customer is using TinyMCE 7.0 with this integration. They set the editor to be disabled disabled=true. (This will cause the editor to initially be in readonly mode) They've decided to bump the version of the integration so that it'll include this change.
Will the editor be in readonly mode?
I think it won't. Because initially editor's init method has

readonly: false,
disabled: true

but the disabled property is ignored by TinyMCE 7.0.
We can't use the isDisabledOptionSupported method without the editor instance, so it'll be tricky to set the init object correctly. (That's why I was forced to compare the versions in my PR :( )

don't we would have the same behavior using the version check? if the disabled prop will not be upgraded they will get a different behavior

Yes it would. Therefore we should set the init object correctly

{
...(isDisabledOptionSupported() ? { disabled: disabled, readonly: readonly } : { readonly: disabled }  )
}

@lorenzo-pomili
Copy link
Contributor Author

(question) Let's say the customer is using TinyMCE 7.0 with this integration. They set the editor to be disabled disabled=true. (This will cause the editor to initially be in readonly mode) They've decided to bump the version of the integration so that it'll include this change.
Will the editor be in readonly mode?
I think it won't. Because initially editor's init method has

readonly: false,
disabled: true

but the disabled property is ignored by TinyMCE 7.0.
We can't use the isDisabledOptionSupported method without the editor instance, so it'll be tricky to set the init object correctly. (That's why I was forced to compare the versions in my PR :( )

don't we would have the same behavior using the version check? if the disabled prop will not be upgraded they will get a different behavior

Yes it would. Therefore we should set the init object correctly

{
...(isDisabledOptionSupported() ? { disabled: disabled, readonly: readonly } : { readonly: disabled }  )
}

isn't the same? I mean if someone with disable: true will update to a new version they will get a isDisabledOptionSupported() true and { disabled: true, readonly: false } the only difference is that if they use readonly with an old version of the editor, which is a pretty unlike scenario

@@ -12,6 +12,10 @@
return prefix + '_' + Math.floor(Math.random() * 1000000000) + String(Date.now());
};

const isDisabledOptionSupported = (editor: TinyMCEEditor): boolean => {
Copy link
Member

Choose a reason for hiding this comment

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

I think this check needs to be different after talking to @michalnieruchalski-tiugo since we want to feed readonly or disabled in at init time as well and then we don't have the editor instance.

Copy link
Member

Choose a reason for hiding this comment

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

If they use disabled=true on a old editor version then it wouldn't be disabled since that option didn't exist prior to 7.6.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@spocke, @michalnieruchalski-tiugo I fixed it, with a check in the setup, let me know what do you think about it

Copy link
Contributor

@tiny-ben-tran tiny-ben-tran left a comment

Choose a reason for hiding this comment

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

Bumping the minor version should fix the CI failure

@lorenzo-pomili lorenzo-pomili merged commit 7392d3a into main May 27, 2025
4 checks passed
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