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

[Bug]: colwidth is not working with editable as false #4044

Open
2 tasks done
ashu12chi opened this issue May 13, 2023 · 1 comment
Open
2 tasks done

[Bug]: colwidth is not working with editable as false #4044

ashu12chi opened this issue May 13, 2023 · 1 comment
Labels
Category: Open Source The issue or pull reuqest is related to the open source packages of Tiptap. Triage: Open A new issue or pullrequest that requires triage (added by default) Type: Bug The issue or pullrequest is related to a bug

Comments

@ashu12chi
Copy link

Which packages did you experience the bug in?

extension-table

What Tiptap version are you using?

2.0.3

What’s the bug you are facing?

When the editor is used with editable: false, the colwidth property on table-header is not working. The below image shows two editors, the first is editable and the second is read-only. In the first editor, the width of first column is respected but in the second editor, the width of first column is minimal to the width of content.

image

What browser are you using?

Chrome

Code example

https://codesandbox.io/s/affectionate-sea-2zln6e?file=/src/App.js

What did you expect to happen?

In both the cases, colwidth should be respected.

Anything to add? (optional)

On my further investigation in the issue, I found when resizable is set to false in the Table extension, the colwidth will not work for editable mode of editor also. As per this, when editor is set to be non-editable, the resizable is always false. As per this, I understand why this done and it is a desired behavior for me too.
The display of column-width is handled here, which will work only when resizable is used, which is not always desired.

The current workaround I am using to solve this issue is to pass handleWidth as zero for making table non-resizable in read-only mode but still make sure colwidth is respected. (For Original code - ref)

addProseMirrorPlugins() {
        const isResizable = this.options.resizable;
        return [
          ...(isResizable
            ? [
              columnResizing({
                handleWidth: this.editor.isEditable ? this.options.handleWidth : 0,
                cellMinWidth: this.options.cellMinWidth,
                // @ts-ignore (incorrect type)
                View: this.options.View,
                // TODO: PR for @types/prosemirror-tables
                // @ts-ignore (incorrect type)
                lastColumnResizable: this.options.lastColumnResizable,
              }),
            ]
            : []),
          tableEditing({
            allowTableNodeSelection: this.options.allowTableNodeSelection,
          }),
        ]
      },

Did you update your dependencies?

  • Yes, I’ve updated my dependencies to use the latest version of all packages.

Are you sponsoring us?

  • Yes, I’m a sponsor. 💖
@ashu12chi ashu12chi added Category: Open Source The issue or pull reuqest is related to the open source packages of Tiptap. Triage: Open A new issue or pullrequest that requires triage (added by default) Type: Bug The issue or pullrequest is related to a bug labels May 13, 2023
@sjdemartini
Copy link
Contributor

@ashu12chi There's an old bug report for this that was closed as "won't fix" here #2041, which has had some further discussion.

One note on the workaround you mention above: I did something similar in my package mui-tiptap (https://github.com/sjdemartini/mui-tiptap) for its TableImproved extension where columnResizing is always registered. However, an important caveat is that this line in your example handleWidth: this.editor.isEditable ? this.options.handleWidth : 0 will prevent the handleWidth from having the right value if the editor changes between editable states. For instance, if you start in read-only mode, the handle width will forever be 0 even if you later switch to editable=true, since the plugin registration doesn't re-run when switching to editable states. Maybe not important for your use-case, but something to keep in mind. This can be worked around via CSS to hide the handle and prevent pointer interactions. I posted more details about the workaround I used here: #2041 (comment)

@bdbch bdbch added this to Tiptap Aug 4, 2023
@github-project-automation github-project-automation bot moved this to Triage open in Tiptap Aug 4, 2023
Zyten added a commit to Zyten/wiki that referenced this issue Sep 20, 2023
BreadGenie added a commit to frappe/wiki that referenced this issue Sep 20, 2023
* feat: add support for tiptap task-item

* fix: save state when task-item is updated in View mode

* fix: disable task-list checkbox in View mode

Issue ueberdosis/tiptap#3676 means changes in View mode will not be saved

* fix: mock tiptap edit mode for task-list

Will be made redundant once ueberdosis/tiptap#4044 is fixed

* style(task-item): minor style changes

* chore: format using prettier

---------

Co-authored-by: Bread Genie <msuhailbh07@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Category: Open Source The issue or pull reuqest is related to the open source packages of Tiptap. Triage: Open A new issue or pullrequest that requires triage (added by default) Type: Bug The issue or pullrequest is related to a bug
Projects
Status: Triage open
Development

No branches or pull requests

4 participants