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.

Sign up for GitHub

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

Jump to bottom

Handling "enter" on Heading block #536

Closed
mtias opened this issue Apr 28, 2017 · 7 comments
Closed

Handling "enter" on Heading block #536

mtias opened this issue Apr 28, 2017 · 7 comments
Labels
[Feature] Blocks Overall functionality of blocks [Type] Task Issues or PRs that have been broken down into an individual action to take
Milestone
May Week 3 (Alpha)

Comments

@mtias
Copy link
Member

mtias commented Apr 28, 2017

Pressing enter in a heading should probably create a new text block if at the end of the line, or split a single heading in two headings if in the middle of the line.
@mtias mtias added [Feature] Blocks Overall functionality of blocks [Type] Task Issues or PRs that have been broken down into an individual action to take labels Apr 28, 2017
@mtias mtias added this to the Prototype Parity milestone Apr 28, 2017
@mtias mtias modified the milestones: May Week 1, Prototype Parity May 1, 2017
@ellatrix
Copy link
Member

ellatrix commented May 2, 2017

Looking now.

@mtias mtias mentioned this issue May 8, 2017
Closed
@jasmussen jasmussen modified the milestones: May Week 1, May Week 2 May 10, 2017
@ellatrix
Copy link
Member

I'm not entirely sure how to do this atm, without more controlled selection and content. @youknowriad Do you have any thoughts on this?

@ellatrix
Copy link
Member

Related: #579.

@youknowriad
Copy link
Contributor

Does TinyMCE trigger a onNewBlock event when he creates a <br />?

  • If it's the case, we should just update this handler to split if we have two consecutive '
    (Same as we do we empty

    `).

  • If it's not the case, we should move the onNewBlock logic to the onKeyDown instead (same as the initial implementation) -> this requires adding a setTimeout() to wait for TinyMCE to effectively apply the keydown event.

@ellatrix
Copy link
Member

Does TinyMCE trigger a onNewBlock event when he creates a <br />?

It does not, as it's not a new block.

If it's not the case, we should move the onNewBlock logic to the onKeyDown instead (same as the initial implementation) -> this requires adding a setTimeout() to wait for TinyMCE to effectively apply the keydown event.

So keyup?

@youknowriad
Copy link
Contributor

So keyup?

yes, maybe :)

@ellatrix ellatrix mentioned this issue May 11, 2017
Closed
@ellatrix
Copy link
Member

Closing for now. See #579 (comment).

@ellatrix ellatrix removed their assignment May 19, 2017
ttahmouch pushed a commit to ttahmouch/gutenberg that referenced this issue Oct 23, 2021
[email protected] was compromised yesterday, October 22, 2021, be…
4d1250c 
…cause the author didn't have 2FA enabled. I think that `npm` dependency was targeted because it's one of the more popular dependencies and the attacker was leveraging it for crypto mining and environment stealing. I noticed a few of our transitive dependencies depend on `"ua-parser-js": "^0.7.x"` in `gutenberg/trunk` (and probably other repositories). Luckily, it's currently locked to `0.7.[23|28]` in `package-lock.json`, but it may just be a matter of time before an `npm update` inadvertently updates the lock file.

0. If it is feasible, it looks like we may be able to leverage the `package.json` to only resolve `"resolutions": { "**/ua-parser-js": "0.7.28" }` from all transitive dependencies in the meantime. That is what is done in this commit.
1. It doesn't appear that `@types/ua-parser-js` is resolving to `0.7.28`. I'm unsure at the moment if it is even being used, and what dependency would even need the TypeScript types since presumably all of them should be exporting JavaScript modules that don't need compilation(?). Does someone else possibly know if the types are used, or if they even need to match the version of their counterpart JavaScript module?
2. Presumably, we'd want to remove the `resolutions` field from the `package.json` when `appium` and `fbjs` bump their, or transitive, `package.json`s to `^0.7.30`.

**Having written all of this, it looks like [`npmjs.org` revoked `0.7.29`](https://www.npmjs.com/package/ua-parser-js) from even being available for download and `0.7.30` and `0.8.1` were both published on October 22, 2021. So it likely won't cause future issues because it won't even be possible to download the dependency, but some people may have had `0.7.29` on their machines and may have been compromised.**

---

[Security issue: compromised npm packages of ua-parser-js (0.7.29, 0.8.0, 1.0.0) - Questions about deprecated npm package ua-parser-js WordPress#536](faisalman/ua-parser-js#536)
[Issue Comment](faisalman/ua-parser-js#536 (comment))
[fbjs > [email protected]: this package has been hijacked WordPress#464](facebook/fbjs#464)

```
$ npm ls ua-parser-js
[email protected] /Users/ttahmouch/Desktop/src/gutenberg
├─┬ @wordpress/[email protected] -> /Users/ttahmouch/Desktop/src/gutenberg/packages/react-native-editor
│ ├─┬ UNMET PEER DEPENDENCY [email protected]
│ │ └─┬ [email protected]
│ │   └── [email protected]
│ └─┬ [email protected]
│   └─┬ [email protected]
│     └── [email protected]  deduped
└─┬ [email protected]
  └─┬ [email protected]
    └─┬ [email protected]
      └─┬ [email protected]
        └── [email protected]
```
@InfiniteLove2020 InfiniteLove2020 mentioned this issue Mar 23, 2023
Open
@MaxMood96 MaxMood96 mentioned this issue Jun 22, 2023
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
[Feature] Blocks Overall functionality of blocks [Type] Task Issues or PRs that have been broken down into an individual action to take
Projects
None yet
Milestone
May Week 3 (Alpha)
Development

No branches or pull requests
4 participants
@youknowriad @mtias @jasmussen @ellatrix