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

[Widgets Editor] Fix insertion point in widget areas #25727

Merged
merged 3 commits into from Oct 6, 2020

Conversation

@kevin940726
Copy link
Member

@kevin940726 kevin940726 commented Sep 30, 2020

Description

Fix #25708.
Fixes #25764.

Insert blocks at the bottom of the widget area via the inserter.

Also fixes a regression in #25708 where the inserter would insert blocks to the first widget area no matter which widget area is selected.

How has this been tested?

  1. Go to Widgets Editor
  2. Select the second widget area
  3. Insert a block via the inserter
  4. The block should appear at the bottom of the second widget area, and scroll down to it.

Screenshots

Kapture 2020-09-30 at 13 56 38

Types of changes

Bug fix

Checklist:

  • My code is tested.
  • My code follows the WordPress code style.
  • My code follows the accessibility standards.
  • My code has proper inline documentation.
  • I've included developer documentation if appropriate.
  • I've updated all React Native files affected by any refactorings/renamings in this PR.
@github-actions
Copy link

@github-actions github-actions bot commented Sep 30, 2020

Size Change: +121 B (0%)

Total Size: 1.18 MB

Filename Size Change
build/block-directory/index.js 8.55 kB -57 B (0%)
build/block-editor/index.js 129 kB +12 B (0%)
build/block-editor/style-rtl.css 10.9 kB -16 B (0%)
build/block-editor/style.css 10.9 kB -16 B (0%)
build/block-library/index.js 135 kB -94 B (0%)
build/block-library/style-rtl.css 7.66 kB +3 B (0%)
build/block-library/style.css 7.65 kB +3 B (0%)
build/block-serialization-default-parser/index.js 1.78 kB +1 B
build/components/index.js 169 kB +139 B (0%)
build/components/style-rtl.css 15.3 kB -63 B (0%)
build/components/style.css 15.3 kB -64 B (0%)
build/compose/index.js 9.42 kB +2 B (0%)
build/data-controls/index.js 685 B -585 B (85%) 🏆
build/data/index.js 8.6 kB +189 B (2%)
build/edit-navigation/index.js 10.7 kB -2 B (0%)
build/edit-post/index.js 306 kB +249 B (0%)
build/edit-post/style-rtl.css 6.29 kB +37 B (0%)
build/edit-post/style.css 6.27 kB +38 B (0%)
build/edit-site/style-rtl.css 3.84 kB +56 B (1%)
build/edit-site/style.css 3.84 kB +57 B (1%)
build/edit-widgets/index.js 21.3 kB +185 B (0%)
build/editor/index.js 45.5 kB +11 B (0%)
build/editor/style-rtl.css 3.85 kB +17 B (0%)
build/editor/style.css 3.84 kB +20 B (0%)
build/element/index.js 4.44 kB +1 B
build/escape-html/index.js 734 B +1 B
build/format-library/index.js 7.49 kB -3 B (0%)
build/is-shallow-equal/index.js 710 B +1 B
build/media-utils/index.js 5.12 kB -1 B
build/plugins/index.js 2.44 kB -1 B
build/priority-queue/index.js 790 B +1 B
build/server-side-render/index.js 2.6 kB -2 B (0%)
build/shortcode/index.js 1.7 kB +1 B
build/url/index.js 4.06 kB +2 B (0%)
build/warning/index.js 1.13 kB -1 B
ℹ️ View Unchanged
Filename Size Change
build/a11y/index.js 1.14 kB 0 B
build/annotations/index.js 3.52 kB 0 B
build/api-fetch/index.js 3.35 kB 0 B
build/autop/index.js 2.72 kB 0 B
build/blob/index.js 620 B 0 B
build/block-directory/style-rtl.css 943 B 0 B
build/block-directory/style.css 942 B 0 B
build/block-library/editor-rtl.css 8.6 kB 0 B
build/block-library/editor.css 8.6 kB 0 B
build/block-library/theme-rtl.css 741 B 0 B
build/block-library/theme.css 741 B 0 B
build/block-serialization-spec-parser/index.js 3.1 kB 0 B
build/blocks/index.js 47.5 kB 0 B
build/core-data/index.js 12 kB 0 B
build/date/index.js 31.9 kB 0 B
build/deprecated/index.js 772 B 0 B
build/dom-ready/index.js 568 B 0 B
build/dom/index.js 4.42 kB 0 B
build/edit-navigation/style-rtl.css 868 B 0 B
build/edit-navigation/style.css 871 B 0 B
build/edit-site/index.js 20.4 kB 0 B
build/edit-widgets/style-rtl.css 3 kB 0 B
build/edit-widgets/style.css 3 kB 0 B
build/editor/editor-styles-rtl.css 492 B 0 B
build/editor/editor-styles.css 493 B 0 B
build/format-library/style-rtl.css 547 B 0 B
build/format-library/style.css 548 B 0 B
build/hooks/index.js 1.74 kB 0 B
build/html-entities/index.js 621 B 0 B
build/i18n/index.js 3.54 kB 0 B
build/keyboard-shortcuts/index.js 2.39 kB 0 B
build/keycodes/index.js 1.85 kB 0 B
build/list-reusable-blocks/index.js 3.02 kB 0 B
build/list-reusable-blocks/style-rtl.css 476 B 0 B
build/list-reusable-blocks/style.css 476 B 0 B
build/notices/index.js 1.69 kB 0 B
build/nux/index.js 3.27 kB 0 B
build/nux/style-rtl.css 671 B 0 B
build/nux/style.css 668 B 0 B
build/primitives/index.js 1.34 kB 0 B
build/redux-routine/index.js 2.85 kB 0 B
build/rich-text/index.js 13 kB 0 B
build/token-list/index.js 1.24 kB 0 B
build/viewport/index.js 1.74 kB 0 B
build/wordcount/index.js 1.17 kB 0 B

compressed-size-action

@noisysocks
Copy link
Member

@noisysocks noisysocks commented Sep 30, 2020

Looks good! The block is inserted into the right place when I click on it in the inserter.

This isn't addressing the first part of #25708, though. When I hover over the block in the inserter, I should see a blue line appear at the bottom of the widget area where the block will be inserted.

@kevin940726
Copy link
Member Author

@kevin940726 kevin940726 commented Sep 30, 2020

When I hover over the block in the inserter, I should see a blue line appear at the bottom of the widget area where the block will be inserted.

@noisysocks Good point, I missed it! However, there's no blue line when inserting to post editor via the inserter either though. I wonder if we should follow the current behavior in post editor? 🤔

@noisysocks
Copy link
Member

@noisysocks noisysocks commented Oct 1, 2020

When I hover over the block in the inserter, I should see a blue line appear at the bottom of the widget area where the block will be inserted.

@noisysocks Good point, I missed it! However, there's no blue line when inserting to post editor via the inserter either though. I wonder if we should follow the current behavior in post editor? 🤔

Oh, huh. That might be a bug unless it was intentionally removed and @mapk and I have missed it.

@talldan
Copy link
Contributor

@talldan talldan commented Oct 1, 2020

It seems like in both the post editor and widgets editor the blue line doesn't show if you're trying to insert at the end of a block list.

I think it's only implemented to show before a block that exists:
https://github.com/WordPress/gutenberg/blob/master/packages/block-editor/src/components/block-list/insertion-point.js#L110

I made a separate bug report for this - #25785

…nsertionPoint prop (#25763)

* Fix widget insertion from sidebar block library by using a declared insertionPoint prop

* Add comments

* Optimize by avoiding `getEntityRecord` call unless needed
@adamziel
Copy link
Contributor

@adamziel adamziel commented Oct 5, 2020

@kevin940726 this looks great overall! I found two problems:

  1. If I select a block, click on the empty space (grey area), and open the inserter after that - the insertion point resets to the end of the widget area.
  2. There is no margin between the legacy widget and the insertion point. We could fix it in a follow-up PR as it seems to be more related to the way legacy-widget block is styled, but we should keep track of it:

Zrzut ekranu 2020-10-5 o 11 49 42

@mapk
Copy link
Contributor

@mapk mapk commented Oct 5, 2020

I encouraged the same interaction as in the post editor here. If there is an area selected, or a block selected that has no blocks below it, the blue line doesn't appear. I could be convinced that it needs to show all the time.

@kevin940726
Copy link
Member Author

@kevin940726 kevin940726 commented Oct 5, 2020

If I select a block, click on the empty space (grey area), and open the inserter after that - the insertion point resets to the end of the widget area.

@adamziel This seems expected to me? Since the user explicitly "un-focus" the selected block. I think it could be pretty frustrating if the user can't do that. It's just my opinion though, and I would love to be proven wrong!

There is no margin between the legacy widget and the insertion point. We could fix it in a follow-up PR as it seems to be more related to the way legacy-widget block is styled, but we should keep track of it:

Nice catch! Open another issue?

@mapk
Copy link
Contributor

@mapk mapk commented Oct 5, 2020

@kevin940726 yes, can you open another issue for that lack of margin?

@adamziel
Copy link
Contributor

@adamziel adamziel commented Oct 5, 2020

@adamziel This seems expected to me? Since the user explicitly "un-focus" the selected block. I think it could be pretty frustrating if the user can't do that. It's just my opinion though, and I would love to be proven wrong!

@kevin940726 I checked what happens in the post editor. If you click on the top bar, it still remembers the last focused block.

@kevin940726
Copy link
Member Author

@kevin940726 kevin940726 commented Oct 6, 2020

I checked what happens in the post editor. If you click on the top bar, it still remembers the last focused block.

Hmmm, interesting, could you share a gif just to be sure that I understand it correctly?

It's similar in the Widgets Editor, it will remember the last focused block if you click on the top bar. In the post editor, the inserter will append to the end when you click on an empty area in the post too. I think they are behaving similarly? Maybe I'm missing some edge cases though 🤔 .

yes, can you open another issue for that lack of margin?

@mapk Sure! Opened #25848.

@adamziel
Copy link
Contributor

@adamziel adamziel commented Oct 6, 2020

@kevin940726 oh that's right! It seems like it's a mental model thing - in the post editor, the entire page is the editor and so whenever I want to remove the blue focus I feel it's "safe" to click on the blank area of top bar without really affecting the editor area (as if the top bar was outside of the editor). I applied the same mental model to the grey area in the widgets editor, even though if you inspect it with dev tools, it is part of the editor. I somehow instinctively click there every now and then though (as if it was outside of the editor) :-)

Sounds like it's something that we should consider separately (if at all). Let me CC @mapk and approve this PR!

@adamziel adamziel merged commit f60cdb3 into master Oct 6, 2020
15 checks passed
15 checks passed
@github-actions
Cancel Previous Runs
Details
@github-actions
Check Check
Details
@github-actions
build
Details
@github-actions
Admin - 1
Details
@github-actions
Compare performance with master
Details
@github-actions
pull-request-automation
Details
@github-actions
test (gutenberg-editor-gallery)
Details
@github-actions
test (gutenberg-editor-gallery)
Details
@github-actions
JavaScript
Details
@github-actions
Admin - 2
Details
@github-actions
Admin - 3
Details
@github-actions
Mobile
Details
@github-actions
Admin - 4
Details
Block-based Widgets Editor automation moved this from PRs in progress to Done Oct 6, 2020
@adamziel adamziel deleted the update/fix-insertion-point-in-widgets-editor branch Oct 6, 2020
@github-actions github-actions bot added this to the Gutenberg 9.2 milestone Oct 6, 2020
adamziel added a commit that referenced this pull request Oct 7, 2020
* Move hooks inside the newly created Interface component

* Fix insertion at the top of the widget area

* Fix widget insertion from sidebar block library by using a declared insertionPoint prop (#25763)

* Fix widget insertion from sidebar block library by using a declared insertionPoint prop

* Add comments

* Optimize by avoiding `getEntityRecord` call unless needed

Co-authored-by: Daniel Richards <[email protected]>
@adamziel adamziel mentioned this pull request Oct 7, 2020
draganescu pushed a commit that referenced this pull request Oct 7, 2020
* Include edit-widgets php files in build (#25792)

* Fix PHP warining in widget utils controller (#25797)

* Fix PHP warning in WP_REST_Widget_Utils_Controller

The `WP_REST_Widget_Utils_Controller::is_valid_widget` method needs to be public in order to be accessible as a callback (since it's being called from outside the class, via `call_user_func`).

This commit fixes the warning by changing the method's visibility from `private` to `public`.

* Ammend the inline documentation. Add `* @access public`

* [Widgets Editor] Fix insertion point in widget areas (#25727)

* Move hooks inside the newly created Interface component

* Fix insertion at the top of the widget area

* Fix widget insertion from sidebar block library by using a declared insertionPoint prop (#25763)

* Fix widget insertion from sidebar block library by using a declared insertionPoint prop

* Add comments

* Optimize by avoiding `getEntityRecord` call unless needed

Co-authored-by: Daniel Richards <[email protected]>

* Initialize the state before rendering widgets editor (#25736)

* Initialize the state before rendering widgets editor

* Replace empty div with null

* Document persistStubPost

* Document persistStubPost further

* Bump version to 9.1.1

* Update changelog

* Fix spaces in changelog.txt

* Adjust spaces in changelog.txt

* Fix link formatting in the changelog

Co-authored-by: Jon Surrell <[email protected]>
Co-authored-by: David Biňovec <[email protected]>
Co-authored-by: Kai Hao <[email protected]>
Co-authored-by: Daniel Richards <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment