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

Fix: Draggable component depends on an element with id editor being available. #15472

Closed
wants to merge 1 commit into from
Closed

Fix: Draggable component depends on an element with id editor being available. #15472

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 7 additions & 2 deletions packages/components/src/draggable/index.js
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,7 +1,10 @@
/**
* External dependencies
*/
import { noop } from 'lodash';
import {
invoke,
noop,
} from 'lodash';

/**
* WordPress dependencies
Expand All @@ -15,7 +18,9 @@ const cloneHeightTransformationBreakpoint = 700;
const clonePadding = 20;

const isChromeUA = ( ) => /Chrome/i.test( window.navigator.userAgent );
const documentHasIframes = ( ) => [ ...document.getElementById( 'editor' ).querySelectorAll( 'iframe' ) ].length > 0;
const documentHasIframes = () => {
return !! invoke( document, [ 'body', 'querySelector' ], 'iframe' );
};
Copy link
Contributor

Choose a reason for hiding this comment

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

@nosolosw Any reason this check was editor specific? Is it because WP can use iframe outside of the "content" canvas (maybe in menus, topbars)? What impact could this have?

Copy link
Member

@oandregal oandregal May 7, 2019 •
edited
Loading

Choose a reason for hiding this comment

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

Exactly. My old self did document this as problematic: #9511 (comment)

If we do this, what will happen in chrome browsers that don't have the fix yet (<72 if I'm reading correctly the upstream bugfix?) is that it'll fire the onDrop and then onDragEnd, effectively executing the onDragEnd property twice.

An alternative fix would be to keep track of whether the drag operation was already reseted keeping a isDragging variable similar to isChromeAndHasIframes and reset the drag state & call the onDragEnd prop only if it still wasn't done.

Copy link
Member Author

Choose a reason for hiding this comment

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

@nosolosw, @youknowriad Can we just remove this logic and assume the problem is fixed in chrome? I guess the last two versions that we need to support already have this problem fixed given that the problem was fixed in Wed, Nov 21, 2018, and chrome updates are fairly regular.

Copy link
Contributor

Choose a reason for hiding this comment

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

@jorgefilipecosta That makes sense to me

Copy link
Member

Choose a reason for hiding this comment

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

Agreed to that: #15665 (wanted to test this effectively had been fixed so I had to prepare the revert anyway).


class Draggable extends Component {
constructor() {
Expand Down