[UEPR-553] Front-end blocking in scratch-www by kbangelov · Pull Request #10189 · scratchfoundation/scratch-www

kbangelov · 2026-04-29T10:28:14Z

Resolves:

Part of https://scratchfoundation.atlassian.net/browse/UEPR-553

Changes:

Disable frontend operations for PDP and Studios

…ature-freeze-read-only-mode

Copilot

Pull request overview

Introduces a READ_ONLY_MODE feature flag to disable interactive/editing operations across Studio pages and the Project Detail Page (preview), to support front-end blocking for UEPR-553.

Changes:

Add READ_ONLY_MODE flag (env-driven) and thread it through Studio + Preview views to disable/hide interactive controls.
Add “disabled” styling helpers and new disabled color tokens used by Studio UI elements.
Prevent certain PDP interactions (love/favorite/share/add-to-studio) and gate editor capabilities when in read-only mode.

Reviewed changes

Copilot reviewed 14 out of 14 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
src/views/studio/studio.scss	Adds shared “disabled” styles and thumbnail-edit disabled styles for studios.
src/views/studio/studio-title.jsx	Disables title textarea and applies disabled styling in read-only mode.
src/views/studio/studio-project-tile.jsx	Hides project tile overflow actions in read-only mode.
src/views/studio/studio-project-adder.jsx	Disables project add/browse controls in read-only mode.
src/views/studio/studio-member-tile.jsx	Hides member management overflow actions in read-only mode.
src/views/studio/studio-image.jsx	Disables studio thumbnail upload and applies disabled styling in read-only mode.
src/views/studio/studio-follow.jsx	Disables follow/unfollow in read-only mode.
src/views/studio/studio-description.jsx	Disables description textarea and applies disabled styling in read-only mode.
src/views/studio/studio-curator-inviter.jsx	Disables curator invite form in read-only mode.
src/views/studio/studio-curator-invite.jsx	Adds disabled styling for invite acceptance button (but currently doesn’t fully disable behavior).
src/views/preview/project-view.jsx	Blocks love/favorite toggles and gates editor capabilities based on read-only/shared state.
src/views/preview/presentation.jsx	Suppresses “share” banner in read-only mode and passes readOnlyMode to child components.
src/lib/feature-flags.js	Adds `READ_ONLY_MODE` flag sourced from `process.env.READ_ONLY_MODE`.
src/_colors.scss	Adds disabled UI color tokens used by new styling.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copilot · 2026-04-29T10:53:41Z

                disabled={submitting}
                onClick={() => {


The accept-invite button is still clickable in read-only mode: you add the studio-disabled class when READ_ONLY_MODE is true, but disabled is only driven by submitting. This still allows accepting curator invites while the UI looks disabled. Include READ_ONLY_MODE in the disabled condition (and/or early-return in the click handler) so the action cannot fire in read-only mode.

Suggested change

disabled={submitting}

onClick={() => {

disabled={submitting || READ_ONLY_MODE}

onClick={() => {

if (READ_ONLY_MODE || submitting) return;

Yep, that's a valid point, also pointer-events: none would resolve that even if the button is not disabled, but I agree that we should add {submitting || READ_ONLY_MODE} as we do for the other buttons.

Copilot · 2026-04-29T10:53:41Z

+.studio-disabled {
+    background: colors.$ui-background-disabled;
+    color: colors.$ui-text-disabled;
+    cursor: not-allowed;
+


.studio-disabled sets a disabled background, but for studio title/description textareas it looks like the existing textarea.studio-title/textarea.studio-description &:not(:focus) { background: transparent; } rule later in this file will override it (higher specificity), so READ_ONLY_MODE may not visually show the disabled background there. Consider adding a more specific override for disabled textareas (e.g., .studio-disabled.studio-title:disabled / .studio-disabled.studio-description:disabled) or adjusting the :not(:focus) rule to not override when disabled.

Copilot · 2026-04-29T10:53:42Z

+                                    canSave={this.props.canSave &&
+                                        (!READ_ONLY_MODE || !this.props.isShared)}
+                                    canShare={this.props.canShare && !READ_ONLY_MODE}
+                                    canUpdateThumbnail={!READ_ONLY_MODE}


canUpdateThumbnail is disabled whenever READ_ONLY_MODE is true, even for unshared projects. That’s inconsistent with the nearby gating for canEditTitle/canSave (which still allow edits when !isShared) and with the existing canManuallySaveThumbnails logic earlier in this file (which explicitly allows thumbnails when READ_ONLY_MODE and !isShared). If the intent is “block shared/public operations only”, gate canUpdateThumbnail the same way (or align/remove the conflicting thumbnail logic so behavior is consistent).

Suggested change

canUpdateThumbnail={!READ_ONLY_MODE}

canUpdateThumbnail={!READ_ONLY_MODE || !this.props.isShared}

adzhindzhi

I haven't reviewed everything yet, but I'm sharing my comments so far.

adzhindzhi · 2026-04-30T14:10:23Z

                />);
            }
-        } else if (!isShared) {
+        } else if (!isShared && !READ_ONLY_MODE) {


I think by design the banner is displayed but the Share button is disabled

@adzhindzhi Doesn't the share button hide once someone shares a project?

adzhindzhi · 2026-04-30T14:19:04Z

    }
    handleFavoriteToggle () {
-        if (!this.props.favedLoaded) return;
+        if (!this.props.favedLoaded || READ_ONLY_MODE) return;


You probably wouldn't need these if you apply the disabled styles to the love/favorite buttons + pointer-events: none.

I think it doesn't hurt to add that check.

adzhindzhi · 2026-04-30T14:25:24Z

+                                    canSave={this.props.canSave &&
+                                        (!READ_ONLY_MODE || !this.props.isShared)}


This doesn't handle pressing CTRL + 'S' in the editor, right? I wonder if we should try to disable that, or let the backend handle it and just display an error... 🤔

Doesn't CTRL+S in Chrome (maybe some Chromium browsers too) activate a system keybind to save a page in a .mhtml?

It is handled in the sense that the frontend fails by displaying "Project could not save.", because of this very prop. So I think that's enough?

adzhindzhi · 2026-04-30T14:28:27Z

        authorUsername: authorUsername,
        authorAvatarBadge: authorAvatarBadge,
-        canAddToStudio: isLoggedIn && isShared,
+        canAddToStudio: isLoggedIn && isShared && !READ_ONLY_MODE,


Hmm, this would remove the whole button, right? It's disabled by design, I don't mind it, but let's confirm with Tereza if that's okay.

adzhindzhi

One additional general comment: We should also disable the "Anyone can add projects" toggle? It shouldn't make a difference, but it would be more consistent.

adzhindzhi · 2026-05-04T08:33:13Z

                disabled={submitting}
                onClick={() => {


Yep, that's a valid point, also pointer-events: none would resolve that even if the button is not disabled, but I agree that we should add {submitting || READ_ONLY_MODE} as we do for the other buttons.

adzhindzhi · 2026-05-04T08:40:08Z

                }
            </div>
-            {(canRemove || canPromote || canTransferHost) &&
+            {(canRemove || canPromote || canTransferHost) && !READ_ONLY_MODE &&


I think by design the menu is disabled in readonly mode, not hidden.

adzhindzhi

Looks good! I left two small comments, but otherwise I think it's pretty clean! One additional general comment is that a few of the disabled buttons still have cursor: pointer, which may be a bit confusing from UX perspective. I think I've only seen this for the love, favorite on PDP and Edit Thumbnail on Studios, but there may be other buttons also affected.

adzhindzhi · 2026-05-08T08:03:14Z

+                {canRemove && process.env.READ_ONLY_MODE !== 'true' &&
+                    <OverflowMenu disabled={process.env.READ_ONLY_MODE === 'true'}>


Will the disabled attribute ever be true? Wouldn't we just not show the menu with the process.env.READ_ONLY_MODE !== 'true' check?

kbangelov added 5 commits April 8, 2026 11:35

chore: restricted share and more

ef9fbfd

feat: froze features

2ce7db3

Merge branch 'release/read-only-mode' into task/uepr-553-front-end-fe…

8e337d9

…ature-freeze-read-only-mode

chore: update feature flag

bc78d88

chore: revert no change

1266a08

kbangelov changed the base branch from develop to release/read-only-mode April 29, 2026 10:43

kbangelov requested review from KManolov3, adzhindzhi and Copilot April 29, 2026 10:47

Copilot started reviewing on behalf of kbangelov April 29, 2026 10:48 View session

Copilot AI reviewed Apr 29, 2026

View reviewed changes

chore: removed unnecessary prop

b180645

adzhindzhi reviewed Apr 30, 2026

View reviewed changes

adzhindzhi reviewed May 4, 2026

View reviewed changes

kbangelov added 2 commits May 4, 2026 18:11

chore: fixing according to design and refactoring code

a14fe1b

chore: addressing small comments

6c043df

kbangelov requested a review from adzhindzhi May 5, 2026 08:11

adzhindzhi reviewed May 7, 2026

View reviewed changes

kbangelov added 2 commits May 7, 2026 19:41

chore: removed redundant code

d52a69c

chore: lower differences

9788937

kbangelov requested a review from adzhindzhi May 7, 2026 16:47

adzhindzhi approved these changes May 8, 2026

View reviewed changes

chore: overflow menu disabled considerations and pointer events none

3774460

	canUpdateThumbnail={!READ_ONLY_MODE}
	canUpdateThumbnail={!READ_ONLY_MODE \|\| !this.props.isShared}

		canSave={this.props.canSave &&
		(!READ_ONLY_MODE \|\| !this.props.isShared)}

		{canRemove && process.env.READ_ONLY_MODE !== 'true' &&
		<OverflowMenu disabled={process.env.READ_ONLY_MODE === 'true'}>

Uh oh!

Conversation

kbangelov commented Apr 29, 2026

Resolves:

Changes:

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Copilot AI Apr 29, 2026

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 29, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 29, 2026

Choose a reason for hiding this comment

Uh oh!

adzhindzhi left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

adzhindzhi left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

adzhindzhi left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants